Phishing links: How to read and check a link before clicking

A phishing link is a web address in a message that looks like it leads somewhere you trust but actually takes you to a page built to steal your password, card details or one-time code, or to download malware. Most people are told "do not click suspicious links" without ever being shown how to read a link, so they judge by the logo and the tone of the message, which are the easiest parts to fake. This guide teaches the anatomy of a web address, a short checking routine anyone can use on a phone or a laptop, which link-checking tools are worth using and what they cannot tell you, and what to do in the first hour after a click. The second half is for the people who protect staff: link rewriting, browser reputation services, DNS filtering, click telemetry and the metrics that show whether the controls work. It goes deeper on links than the How to Spot a Phishing Email Guide and the broader Phishing Guide.

Key takeaways

• Read the domain, not the message. The only part of a link that tells you who owns the page is the registered domain just before the first single slash; everything else, including words like "secure", "login" or a brand name, can be chosen freely by an attacker.
• Do not use the link to check the link. NCSC, CISA and the FTC all give the same advice: if a message might be genuine, go to the organisation by typing its address yourself or using its app, not by clicking.
• Checking tools catch known bad links, not new ones. Reputation services work from lists of reported sites, so a page created an hour ago can show as clean; a clean result is not proof of safety.
• A click is recoverable if you act fast. Closing the page costs nothing; typing a password, approving a sign-in or running a download is what turns a click into an incident, and each has a specific fix.
• For organisations, measure reporting, not only clicking. Time-of-click protection, browser reputation and DNS filtering reduce exposure, but the fastest signal is a staff member who reports the link within minutes.

How to read a web address

RFC 3986, the standard that defines web addresses, splits a URL into a scheme, an authority (optional user information, then the host, then an optional port), a path, a query and a fragment. For phishing, the host is what matters, and within the host, the registered domain: the name an organisation actually bought, plus its top-level domain. Read the host from right to left, starting at the end of the host and stopping at the first single slash.

Three worked examples. In https://accounts.example.com/signin the registered domain is example.com, so the page belongs to example.com. In https://example.com.account-verify.net/signin the registered domain is account-verify.net, and example.com is just a subdomain label. In https://[email protected]/signin the real host is the IP address after the @. The Twilio employees targeted in 2022 received texts pointing at hosts such as twilio-sso.com and twilio-okta.com, which contain the right brand words but belong to the attacker; see the Twilio breach 2022.

Lookalike characters

International domain names can contain non-Latin characters, and some Cyrillic or Greek letters look identical to Latin ones. Browsers defend against this by showing the raw "punycode" form, which starts with xn--, when a name looks risky. Chromium's published policy, for example, shows punycode when a label mixes Latin with Cyrillic or Greek, when an all-Cyrillic label could pass for Latin text under a top-level domain not associated with that script, or when the name's "skeleton" matches a popular domain once lookalike characters are mapped. If you see xn-- in an address bar for a site you thought you knew, stop. Character swaps that need no special alphabet (rn for m, 0 for o, l for I) are not caught by these rules, which is why reading slowly matters. The Typosquatting and Lookalike Domains Guide covers registration monitoring and takedown.

A 30-second check before you click

This routine is for everyone, at work or at home. It follows the official advice from the UK NCSC, the US CISA and FTC, and Apple.

1. Pause on the pressure. NCSC lists five tricks: authority (it claims to be your bank, a government department or your boss), urgency (a deadline or a fine), emotion (fear, hope or curiosity), scarcity (tickets, refunds, limited offers) and current events (tax season, a big news story). Any of these is a reason to slow down.
2. Ask whether you expected it. The FTC's first question is whether you have an account with the company or know the person. A delivery notice for a parcel you did not order is a lure.
3. See the real destination. On a computer, hover over the link and read the address that appears at the bottom of the window or in a tooltip. On an iPhone or iPad, Apple's advice is to touch and hold the link to preview it; Android offers a similar long-press preview. The visible text of a link can say anything.
4. Read the host right to left. Find the registered domain just before the first single slash. Is it exactly the organisation's real domain, the one printed on your card, statement or bill?
5. Treat shortened and QR links as unread. CISA flags shortened links from sources you do not trust, and NCSC warns about QR codes in emails. Both hide the destination until you follow them. See the QR Code Phishing (Quishing) Guide.
6. Go round the link. If the message might be real, open the organisation's app or type its address yourself. Do not call a number from the message either; NCSC advises using contact details from the organisation's official website or the back of your card.
7. Do not click "unsubscribe" in a suspicious message. CISA includes unsubscribe links in its warning: they are links like any other.

Polished writing is no longer a sign of a real message. CISA notes that AI tools produce convincing text, so spelling mistakes cannot be the main test. See the AI-Generated Phishing Defence Guide.

Link-checking tools: what they can and cannot tell you

Link checkers are useful as a second opinion, never as permission. Nearly all of them compare the address against lists of sites already reported as phishing or malware, sometimes adding analysis of the page itself.

Two cautions for staff. First, a link in a password reset or sign-in email often contains a one-time token: pasting it into a public scanner can hand that token to anyone who reads the scan results. Second, developers building link checks into their own products should note that Google's Safe Browsing APIs are documented as non-commercial only, with the Web Risk API offered for commercial use, and that the v4 Safe Browsing APIs are marked deprecated. The Update API model, where the client keeps hashed prefixes locally and only asks the server about matches, is the privacy-preserving pattern because the server never learns the full addresses checked.

If you clicked: what to do in the first hour

What you do depends on what happened after the click. Opening a page and closing it is low risk on an up-to-date device; the following steps scale with what you gave away.

Where to report a phishing link

• UK email: forward to [email protected]. NCSC says it analyses the message and linked sites and works with hosting companies to remove malicious ones. Suspicious websites can be reported through the NCSC report scam website page.
• Texts (UK and US): forward to 7726. NCSC publishes the iPhone steps (press and hold the message, More, forward, enter 7726) and the Android steps (press and hold, three dots, Forward).
• US: forward phishing emails to the Anti-Phishing Working Group at [email protected] and report the attempt at ReportFraud.ftc.gov.
• Lost money or hacked (UK): NCSC points to Report Fraud (reportfraud.police.uk, 0300 123 2040) for England, Wales and Northern Ireland, and Police Scotland on 101.
• Apple-themed messages: forward to [email protected], or use Report Junk in Messages.
• At work: use the report button in your mail client so the security team can pull the same message from every mailbox. See the Phishing Report Button and User Reported Message Triage Guide.

Controls for organisations

Staff training reduces clicks; technical controls reduce what a click can do. Layer them so that no single failure leads to a stolen session.

• Time-of-click URL protection: in Microsoft Defender for Office 365, Safe Links rewrites email links to the safelinks.protection.outlook.com prefix and checks them at click; Teams and Office apps are checked at click without rewriting. Microsoft's recommended settings include turning on real-time URL scanning for suspicious links and links to files, waiting for scanning to complete before delivery, applying Safe Links to internal email, tracking clicks, and turning off "Let users click through to the original URL". Note that automatically forwarded mail is not rewritten for an unprotected final recipient.
• Browser reputation enforced by policy: enable Microsoft Defender SmartScreen or Safe Browsing through Group Policy, Intune or your browser management console, and remove the user's ability to bypass warnings on managed devices. See the Browser Security Hardening Guide.
• Protective DNS: block known malicious and newly registered domains at the resolver, and control encrypted DNS so devices cannot route around it. See the Protective DNS Guide.
• Phishing-resistant sign-in: passkeys and FIDO2 security keys will not authenticate to a lookalike domain because the credential is bound to the real one. This is the single control that makes a credential-harvesting link fail even after a click. See the Phishing-Resistant MFA Guide.
• Password managers: a manager that autofills only on the saved domain is a practical lookalike detector; when it offers nothing, the domain is wrong. See the Password Managers Explained for Everyone Guide.
• Sender authentication: enforce DMARC on your own domains so attackers cannot send links from your exact address. See the DMARC, SPF and DKIM Guide.

Rolling it out

1. Baseline: measure current click and report rates from a phishing simulation and from real reported messages for one month before changing anything.
2. Pilot: apply time-of-click protection and browser reputation enforcement to the IT team and one business unit; collect false positives (blocked legitimate partner links) for two weeks.
3. Tune: handle false positives through the vendor's allow or block list rather than turning protection off for whole domains; in Safe Links the "Do not rewrite the following URLs" list does not apply to Teams and Office apps, so Microsoft points to the Tenant Allow/Block List for a universal entry.
4. Expand: roll out to all users in rings, then remove warning bypass on managed browsers.
5. Rollback: keep the previous policy as a lower-priority copy; disabling the new policy reverts users without rebuilding settings.

Detection and measurement

Click telemetry turns a reported link into a scoped incident: who else received it, who clicked, and from which device.

• Click events: in Microsoft Defender XDR advanced hunting, clicks on Safe Links-wrapped URLs appear in the UrlClickEvents table with AppName set to Mail; join to sign-in logs to see whether a click was followed by a sign-in from a new location.
• DNS and proxy logs: look for first-seen domains, newly registered domains and lookalikes of your own brand. See the DNS Logging and Detection Guide.
• Identity signals: an MFA prompt approved minutes after a click, a new session token from an unfamiliar network, or a new inbox forwarding rule are the signs that a link worked. See the AiTM Phishing Guide.

Where identity fits

Phishing links are an identity attack first: the page wants a credential, a one-time code or a session. Links in OAuth consent prompts ask for something more durable, a token granted to an attacker's application that survives a password change. If a link led to a "grant permissions" screen rather than a sign-in page, revoke the app grant as well as resetting the password. See the Consent Phishing and Illicit OAuth Grants Guide and the Device Code Phishing Guide, which covers links to genuine Microsoft pages that are used to authorise an attacker's device.

Common failure patterns

• Trusting the padlock: HTTPS proves encryption, not identity. Most phishing pages have valid certificates.
• Reading the brand, not the domain: employees at Twilio were sent hosts such as twilio-sso.com and sendgrid-okta.org that contained the right words but belonged to the attacker; see the Twilio breach 2022.
• Treating a clean scan as permission: reputation lists lag behind newly created sites; the check should be the domain, then the scanner.
• Pasting sensitive links into public scanners: reset links and document-share links carry tokens that the scan result can expose.
• Allow-listing whole domains to fix false positives: attackers host pages on popular file-sharing and form services, so allowing the whole service removes the check exactly where it is needed.
• Punishing clickers: staff who fear consequences delay reporting, which is the metric that limits damage.

Framework mapping

Practitioner checklist

• Teach the right-to-left domain reading method with your own organisation's real domains as examples.
• Publish a list of the domains your organisation genuinely sends links from, so staff have something to compare against.
• Enable time-of-click URL protection for email, chat and office documents, and turn off click-through to blocked URLs.
• Enforce browser reputation services by policy and remove warning bypass on managed devices.
• Route managed devices through protective DNS and control encrypted DNS settings.
• Deploy a one-click report button and acknowledge every report.
• Join click telemetry to sign-in logs so a click followed by a new session raises an alert.
• Move administrators and finance staff to phishing-resistant MFA first.
• Tell staff never to paste reset or share links into public scanners.
• Track report rate and time to first report alongside click rate.

Standards and references

• NCSC: How to spot a scam email, text message or call
• NCSC: Report a scam email
• CISA: Recognize and Report Phishing
• FTC: How to Recognize and Avoid Phishing Scams
• Apple: Recognize and avoid phishing messages
• IETF: RFC 3986 Uniform Resource Identifier (URI): Generic Syntax
• Microsoft Learn: Safe Links in Microsoft Defender for Office 365
• Chromium: IDN in Google Chrome

Related NHI Mgmt Group resources: Phishing Guide · How to Spot a Phishing Email Guide · Typosquatting and Lookalike Domains Guide · Vishing and Smishing Guide · Phishing-Resistant MFA Guide