Typosquatting.ai
FIELD GUIDE

How to Investigate a Suspicious Domain Without Visiting It

The instinct is to open it and look. That is the one action worth avoiding.

by Typosquatting.ai Research16 September 2026updated 23 September 202610 min read

Investigating a suspicious domain without visiting it means establishing what it is from public registration, DNS, certificate and passive records, without sending a request to the site itself.

This guide covers why not to open the link, how to find the real domain in an address, the public sources to check and the order to check them in, the age thresholds people use, how to interpret each result, what to preserve as evidence, and who to report to.

Why not just visit it?

Opening a suspect page tells the operator that their message reached a live person, and it tells them your address, your browser and your organisation's network. For a targeted campaign that is useful intelligence handed over for nothing.

It also risks the visit itself. A page can attempt a download, exploit a browser weakness, or simply present a convincing login form at the exact moment you are least prepared to be sceptical.

Everything you need in the first pass is available from records that describe the name rather than from the name itself: the registry, the DNS system, the certificate logs, and scans other people have already made. None of those touches the site.

Most suspicious links resolve on inspection alone, and the first job is to tell which domain a link actually goes to. The text you can see is not the destination. In an email or a document, the underlying address is what counts: hover over the link on a desktop, or press and hold it on a phone, and read the address that appears. Never tap it.

Then read that address from the right. The part that identifies the registration is the label immediately to the left of the public suffix, together with that suffix. The Public Suffix List, which browsers use, defines a public suffix as one under which users can directly register names, and co.uk is on it as much as com is. Everything to the left of the registrable domain was chosen by whoever holds it, and everything after the first single slash is a path on their server.

  • In https://accounts.example.com/login the registrable domain is example.com.
  • In https://example.com.signin.test/ the registrable domain is signin.test. The familiar brand is a subdomain of somebody else's name.
  • In https://example.com-login.test/ the registrable domain is again not example.com, because a hyphen is an ordinary character and only the dot separates ownership.
  • In https://example.co.uk/ the registrable domain is the whole thing, because co.uk is a public suffix.
  • In https://example.com@203.0.113.10/ the host is 203.0.113.10. Anything before an @ sign in the authority part is user information, not the destination, and browsers will take you to the address after it.
  • In https://link.example.org/r?u=https://example.com.signin.test/ the destination is inside the query string. Tracking and redirect links wrap the real address, so unwrap it and read the inner one.
  • If a name displays as xn-- followed by a string, the browser has declined to show it in Unicode. Chrome's published policy does that when, among other things, a label mixes characters from multiple scripts. Treat it as deliberate until shown otherwise.

The order to check public sources in

Once you have the registrable domain, five sources answer almost every question, and each can be used without any product. Check them in this order, because each one is cheaper than the next and each narrows what the next has to explain.

  1. Registration record. Query RDAP at lookup.icann.org, or at client.rdap.org, which also handles country endings and IP addresses. When was this name created, and through which registrar? A name created days ago is the strongest single signal available.
  2. DNS. Ask a public resolver over DNS over HTTPS, which never contacts the domain. A GET to https://cloudflare-dns.com/dns-query?name=example.com&type=MX with an Accept header of application/dns-json returns the mail routing as JSON; change the type to A or NS for the address and nameservers. Mail records on a young lookalike are a considered act.
  3. Certificate transparency. Search crt.sh with https://crt.sh/?q=<domain>. Has a certificate been issued, and when relative to the registration? Issuance within days of registration is the shape of preparation.
  4. Passive web observation. Search urlscan.io for existing scans with domain:<domain>; the search finds scans other people have already run, so nothing is submitted. Has anyone recorded this host before, and what did it look like?
  5. Reputation. Look the domain up on VirusTotal, which checks it against more than 70 scanners and blocklists. A hit is useful. No hit is the normal state of a new name and proves nothing.
  6. Relationships. Do the address, nameservers or mail provider match other names you have seen? A group is one decision instead of many.

How young is young: the age thresholds people use

Registration age does more work than any other single fact, so it helps to know the numbers the industry actually uses rather than a vague sense of recent.

Unit 42's study of newly registered domains defined them as any domain registered or changed hands within the last 32 days, and found that over 70 percent of them were marked malicious, suspicious or not safe for work by its URL filtering. Cloudflare's gateway categories draw the line at 30 days for a new domain and, separately, 30 days since a domain was first resolved. A name inside that window is not proven hostile, but a message arriving from one deserves to be read as if it were.

Under a year is a different and looser threshold, used for names that carry an impersonation keyword such as login or secure alongside a brand: old enough to have been parked, young enough that the keyword was probably chosen with a purpose. Beyond a year, age stops being evidence in either direction.

Interpreting what comes back

Three results are commonly over-read, so it is worth being explicit.

No registration record does not mean the name is unregistered or available. It means this registry returned no object, and that also happens for reserved and premium names, and for endings whose service the lookup could not reach.

An old registration date does not clear a name. Domains are bought and sold, and an aged name is a valuable thing to acquire precisely because age looks reassuring. A name that has nameservers but no address is not empty either; it is registered and waiting.

A clean passive record proves nothing either way. It means nobody has publicly scanned the host, which is the normal state for a name that is new.

What does justify acting quickly is a combination: recent registration, a certificate issued close to it, mail records configured, and a name that closely imitates a brand in a message somebody actually received. The checker on this site orders findings by that combination, reaches its highest review priority for an impersonation keyword only when the registration is under a year old, and never loads the suspect site.

Preserve the evidence while it exists

Everything about a hostile name can change in minutes, and the record you did not keep is the one you will want. Before you report anything, capture the following with the date and time you retrieved it, in UTC.

  1. The full address, exactly as it appeared, including the path and any query string, and the text it was displayed as.
  2. The message that delivered it, with its full headers if it was an email.
  3. The registration record, the DNS answers, and the certificate entries, as the raw responses rather than a summary.
  4. Any passive observation of the host, with the scan's own date.
  5. Who received it, how many people, and whether anyone interacted with it.

Who to tell, and in what order

If anybody entered credentials, that is an incident and it takes priority over any investigation: reset first, investigate second. The UK National Cyber Security Centre's guidance makes the same point from the other side, that an organisation should already know how it will force a password reset when a password is compromised.

Otherwise the useful reports are to the hosting provider and registrar, whose abuse contacts are in the RDAP records you already retrieved and who can act under their own terms of service, and to the blocklist operators, who reduce reach quickly. Google Safe Browsing accepts reports of phishing pages and shows warnings across the browsers and devices that use it. The Anti-Phishing Working Group asks for suspicious emails to be forwarded to reportphishing@apwg.org for analysis and archiving. In the UK, the NCSC's Suspicious Email Reporting Service takes forwarded emails and had removed 454.8 thousand scam URLs as of July 2026.

All of these act on evidence of what the name is doing, not on trademark rights, so the records you preserved are exactly what they need. If the name is imitating your own brand and you want to own it rather than only stop it, that is a separate and slower route, and it argues about the registrant's rights rather than about the current page.

What none of this establishes

A lookalike that resolves, holds a certificate and accepts mail is a name to review urgently. It is still not, on this evidence, a proven phishing site or a malicious registrant. Similar domains belong to unrelated businesses, to brands defending themselves, and to people with no interest in anyone.

The value of the public record is that it turns a guess into an ordered set of facts with dates attached. The decision it supports is where to spend the next hour, not who to accuse.

Common questions

how do i tell which domain a link actually goes to
Read the underlying address, not the visible text: hover on a desktop or press and hold on a phone. Then find the registrable domain by reading from the right: the label before the public suffix plus the suffix itself. Ignore subdomains to the left, anything before an @ sign, and any address wrapped inside a redirect link's query string.
how can i check a suspicious link without clicking it
Extract the domain, then query public records that describe it rather than the site: the RDAP registration record at lookup.icann.org, DNS through a DoH resolver, certificate history on crt.sh, existing scans on urlscan.io and reputation on VirusTotal. None of those sends a request to the suspect site.
how old should a domain be before it is trusted
There is no age that proves trust, but the common industry line for a newly registered domain is about 30 days: Cloudflare's category uses 30 days and Unit 42's study used 32. A name inside that window that arrives in an unexpected message deserves suspicion. An older name can still be bought and reused, so age is one signal, not a verdict.
what should i do if someone entered their password on a phishing site
Treat it as an incident before an investigation. Reset the password, revoke sessions and check for mail forwarding rules or other changes on the account, then investigate the domain and report it. Preserve the message and its headers first, because the site may be gone within hours.
where do i report a phishing domain
To the hosting provider and registrar named in the RDAP record, who can act on their own terms; to Google Safe Browsing, whose warnings reach the browsers that use it; to the Anti-Phishing Working Group by forwarding the email to reportphishing@apwg.org; and, in the UK, to the NCSC's Suspicious Email Reporting Service.

Sources and further reading

  1. Public Suffix List
  2. Chromium: IDN display policy
  3. ICANN Lookup
  4. client.rdap.org: browser RDAP client
  5. Cloudflare: DNS over HTTPS JSON API
  6. crt.sh: certificate transparency log search
  7. urlscan.io: search documentation
  8. urlscan.io: API documentation
  9. VirusTotal: how it works
  10. Unit 42: newly registered domains and malicious abuse
  11. Cloudflare: Gateway domain categories
  12. Google Safe Browsing
  13. Google Safe Browsing: report a phishing page
  14. Anti-Phishing Working Group: report phishing
  15. UK NCSC: report a scam email
  16. UK NCSC: Phishing attacks: defending your organisation
  17. Typosquatting.ai: methodology and data sources

Keep reading in Domain intelligence