Phishing often works by making a request feel urgent, familiar or routine. A useful defence is to separate the message from the action it asks you to take. This guide explains how to inspect sender and link information without opening a suspicious destination, then confirm the underlying issue through a channel you choose independently. It is intended for everyday account and message safety.
Read the requested action before judging the design
CISA phishing guidance advises independent verification rather than using the contact details embedded in a suspicious message. Begin by identifying the demand: sign in, disclose a code, download a file, pay an invoice or change account details. A message can have polished language and a convincing logo while asking for an unsafe action. Conversely, an awkwardly written legitimate message is possible. Treat style as a clue, not a verdict. The requested action and the independently verified context are more useful than trying to grade the sender’s spelling.
A message-inspection table
| Item | Evidence or distinction | Review question |
|---|---|---|
| Sender display name | Visible label in the inbox | Does the actual address match an established contact? |
| Reply route | Address or number supplied for a response | Can the request be checked through a separate known channel? |
| Link destination | Full address shown by a safe preview | Does the hostname correspond to the intended service? |
| Attachment | File type and business purpose | Was this file expected from this sender? |
| Requested urgency | Threat, reward or artificial deadline | Is pressure preventing an ordinary verification step? |
The Google phishing-help page also recommends going directly to the service when a message asks for credentials. No single field in this table establishes trust. Use the combination to decide whether to stop and verify, not to justify opening an uncertain file.
Inspect a destination without navigating to it
Where the application safely reveals a link target, inspect the full address rather than only the displayed text. Pay attention to the hostname, unexpected spelling and additional labels that can make a name look familiar. On a small screen, a truncated address can hide relevant information. Do not open the destination simply to get a better look. If the preview is unclear, use the service’s known application or type its established address yourself. A shortened link or QR code should not receive special trust merely because the underlying destination is initially hidden.
Do not use encryption indicators as identity shortcuts
An encrypted connection protects communication with the destination reached; it does not by itself establish that the destination is the organisation you intended. A fraudulent page can present a professional interface and use modern transport security. The useful question remains whether you reached the correct service through a trusted route. If a browser displays a certificate or security warning, do not disable the warning to follow the message’s instructions. Return to an independently opened account page and check whether the claimed notification appears there. This avoids turning a technical symbol into a blanket judgement about the sender.
Confirm unusual changes through a separate relationship
A request to change a supplier’s bank details, transfer ownership of a shared account or urgently approve a sign-in deserves a deliberate callback or verification step. Use contact information already held in your records, not a new number included in the request. Explain the specific change you are confirming. For a sports association, a volunteer should be able to ask another authorised officer before changing collection details. The process should be normal and predictable, so a genuine urgent request can still be handled without bypassing the check that protects the group.
Report the message and preserve useful evidence
Apple’s social-engineering guidance provides official reporting routes for its services. Other providers have their own report-phishing controls. Use the relevant built-in option where available and preserve the original message if an incident needs investigation. A screenshot can help explain what you saw, but the original may contain additional routing information. Do not forward the suspicious attachment widely to warn colleagues. Send a short description through your established internal channel, with the details needed to identify the message and without repeating live links that invite another person to open it.
A pause-and-verify checklist
- Identify the action being requested before reacting to urgency.
- Inspect the real sender and destination when the application safely allows it.
- Open the account independently instead of following a sign-in link.
- Confirm financial or ownership changes through an existing contact route.
- Report the message using the provider or organisation’s established process.
If you already entered information, shift from message inspection to account protection. Record what was disclosed and follow the relevant provider’s recovery process promptly. Simply deleting the message does not undo an exposed password or an approved action. A clear record of the event helps the next responder focus on the access or transaction that needs attention.
Frequently asked questions
Does correct spelling prove a message is genuine?
No. Language and design can be copied or generated convincingly. Verify the requested action and the sender through an independent route.
Does an HTTPS address prove I reached the intended organisation?
No. It concerns the protected connection to the destination reached. You still need to identify the correct service and hostname.
Should I open an attachment to discover whether it is suspicious?
No. Confirm that it was expected and use the provider or organisation’s safe reporting process. Do not open an uncertain file merely to inspect it.
Sources and verification
- Recognize and report phishing — CISA — 2026-10-23
- Avoid and report phishing emails — Google — 2026-10-23
- Recognize and avoid social engineering schemes — Apple — 2026-10-23