How to Tell If a Domain Is Fake: Read It From the Right
How to tell if a domain is fake in thirty seconds: five checks, reading an address from the right, six documented lookalikes, and what public records prove.
Five checks in thirty seconds
Most people meet a fake domain inside a message, not by mistyping it. The checks below are in the order that catches the most with the least effort, and the first one has nothing to do with the address.
Illustrative lookalikes in this article use the reserved .test ending, so that no real registration is named.
- Stop at the request. An unexpected instruction to sign in, pay, reset a password or act before something lapses is the signal, whatever the address looks like.
- Find the registrable domain by reading from the right. Skip the ending, take the label immediately before it, and ignore everything to the left of that. That label and the ending are the only part somebody had to buy.
- Compare that label with the one you know, character by character. A missing or doubled letter, rn where you expect m, a 1 or an l where you expect i, or a hyphen that joins the brand to a word such as login.
- Copy the address into a plain text field and look for xn--. A label that begins xn-- was displayed to you as Unicode and is held by the registry as something else; treat it as deliberately confusable until proven otherwise.
- Do not use the link to decide. Reach the service by a bookmark, a typed address or its app, and see whether the request exists there. If you are investigating rather than browsing, look up the registration record instead of opening the page.
Only one part of an address names the owner
A familiar brand inside a link tells you nothing about who controls the destination. One part of an address identifies the holder of a registration: the label immediately to the left of the public suffix, together with that suffix. Everything to the left of it was chosen by whoever holds the registration, and everything after the first single slash is a path on their server.
So read from the right. The rightmost labels are the public suffix, the label before them is the registration, and that boundary is the only part of the address somebody had to buy.
| What you see | Registrable domain | Who controls the page |
|---|---|---|
| accounts.example.com/login | example.com | The holder of example.com |
| example.com.signin.test | signin.test | The holder of signin.test |
| example-support.test | example-support.test | A separate registration, unrelated by default |
| shop.example.co.uk | example.co.uk | The holder of example.co.uk |
| example.pages.dev | example.pages.dev | Whoever claimed that name on the platform |
The ending is not always one label
A rule of thumb that says to take the last two labels is wrong for a large part of the internet. In example.co.uk the registration is example.co.uk, because co.uk is the public suffix and nobody registers co.uk itself. In example.com the registration is example.com. Which of the two applies is not guessable from the string.
The Public Suffix List is the maintained record of which endings are registry controlled: a public suffix is one under which the public can, or historically could, register names directly. Browsers use it to decide how far a cookie may travel, and the same list is what a checker uses to reduce a name to its registrable form before generating anything.
The list changes as registries add and retire endings. It is data to look up, not a rule to memorise.
Six documented lookalikes, read the same way
The method is easier to trust once it has been applied to names that were actually registered. Each row below is a documented case from a browser vendor’s report, a security researcher’s write-up or a published investigation, listed in the sources. Read each from the right and the trick shows itself.
| What was seen | Registrable domain | What it was |
|---|---|---|
| apple.com, all Cyrillic | xn--80ak6aa92e.com | 2017 homograph demonstration; fixed in Chrome 58 |
| ca.com in Cyrillic | xn--80a7a.com | Lookalike reported by Krebs, 2018 |
| krebsonsecurity with a dotted n | a different name | Single-character homograph, 2018 |
| secure-wellsfargo.org | secure-wellsfargo.org | Credential phishing, Unit 42, 2020 |
| amazon-india.online | amazon-india.online | Credential theft aimed at mobile users, 2020 |
| netflix-payments.com | netflix-payments.com | Phishing and scam sites, 2020 |
The first three fail check four: their registry form begins xn-- or contains a character that is not the one it resembles. The last three fail check three: the brand is spelled correctly and a hyphenated word or a different ending does the work.
The families of change worth recognising
Most lookalikes are one of a small number of transformations applied to the registrable label. Knowing the families is what turns a vague sense that something looks wrong into a specific statement about what changed.
Omission- A letter is dropped. exmple.test.
Repetition- A letter is doubled. exampple.test.
Transposition- Two neighbouring letters swap places. exmaple.test.
Substitution- A letter becomes a keyboard neighbour or a similar shape. exsmple.test, examp1e.test.
Insertion- A character is added, most often a hyphen. exam-ple.test.
Compound- An official sounding word is attached. secure-example.test, example-login.test. This is the family of secure-wellsfargo.org and netflix-payments.com.
Alternative ending- The same label under a different suffix. example.net, example.org, or, as with amazon-india.online, a keyword and a new ending together.
Characters that are not the characters they look like
Some lookalikes are not misspellings at all. Inside the Latin alphabet, r and n set close together read as m, a lowercase l reads as a capital I in many sans-serif faces, and 0 reads as o. Across scripts the effect is stronger, because Cyrillic a and Latin a are different code points that render almost identically: Latin a is Unicode 0061 and Cyrillic a is 0430, and to a person the two are the same shape.
The best known demonstration was a name spelled entirely in Cyrillic that displayed as apple.com in Chrome and Firefox in 2017; visually the two were indistinguishable because of the font the browsers used. Chrome 58 changed its display rules in response, and browsers now show a name in Punycode when the script mix looks deceptive. The defence stops at the address bar: a link in an email, a chat or a PDF is rendered by that application, not by the browser.
Internationalised names are held by the registry in an ASCII form beginning with xn--. Paste an address into a plain text editor: if a label starts with xn--, the form you were shown was Unicode and the form the registry holds is not. That is the moment to look the name up rather than judge it by eye.
International characters in a domain are ordinary and prove nothing by themselves. A very large number of legitimate names use them.
The message around the link decides how much the link matters
Most people meet a lookalike inside a message rather than by mistyping. The request is the signal before the address is: an unexpected prompt to sign in, to pay an invoice, to reset a password, or to move quickly because something is about to lapse.
The one move that does not work is using the link to decide whether the message that carried it can be trusted.
- Stop at the request, not at the address. An unexpected instruction deserves scrutiny whatever the domain looks like.
- Reach the service by a route you already trust: a saved bookmark, an address you type yourself, or the app.
- Let a password manager judge the domain. It fills a saved login only on the exact domain it was saved for, so an empty login form on a page that should know you is itself a warning.
- If you do need to examine the address, copy it as text rather than following it.
- Report it through your own channel, so one person's caution becomes everybody's.
Signals that help you prioritise, and what each one is worth
Once you have a candidate name, public records tell you how urgently to look at it. RDAP gives the creation date and registrar, DNS shows whether a host answers and whether mail is configured, and certificate transparency logs show whether a certificate has been issued. Each signal narrows the question. None answers it.
| Signal | What it suggests | What it does not establish |
|---|---|---|
| Registered recently | Infrastructure prepared for something current | Intent. New and entirely ordinary businesses register names every day. |
| Resolves to an address | Something is being served | What is being served. A record check never loads the site. |
| Mail records configured | The name is able to send or receive mail | That any message was ever sent from it. |
| A certificate was issued | Someone proved control of the name to a certificate authority | Anything about the content behind it. Certificates are routine and cheap. |
| A padlock in the browser | The connection is encrypted | Who is on the other end. Lookalikes get certificates too. |
| No registry record returned | Nothing was found at the moment of the lookup | That the name is available, or that it was never registered. |
What none of this proves
Similarity is not proof of intent. A registered lookalike may be a defensive registration your own company bought and forgot, a partner's regional site, a dictionary word that collides by accident, or an unrelated business that has held the name for a decade.
This is why a review priority is a position in a queue and not a verdict. Elevated means look at this one first. It does not mean phishing, and a report written to a registrar as though it did is a report that loses its credibility, along with the next one you send.
If you own the brand being imitated
Everything above is written for the person holding the message. If you are the brand, the question changes from is this address fake to which addresses like mine exist, and the learn guide on lookalike domains covers that side: the kinds of lookalike, what browsers do and do not catch, and how to check a name against public records.
The checker on this site does that check for a domain you own, without an account. It generates candidates from about twenty pattern families across roughly 180 endings, resolves them over DNS over HTTPS, and takes its evidence from registry RDAP, certificate transparency logs and passive urlscan.io search. It never connects to a suspect site. The rules behind every label it applies are on the methodology page.
A safe next step
Whether you are a reader with a suspicious message or an owner with a suspicious finding, the safe moves are the same, and none of them involves the suspect page.
- Check the domain you control, not the suspicious one.
- Compare what comes back against your own domain inventory before treating anything as hostile.
- Keep what you already have: the address as text, the date and time you saw it, and the records the check returned.
- Do not sign in, download anything, or submit a form on a domain you are investigating.
Common questions
- How can I tell if a website domain is fake?
- Read the address from the right: the label immediately before the ending is the registration, and everything to its left was chosen by whoever holds it. Compare that label with the one you know character by character, paste the address as text to see whether any label begins xn--, and reach the service by a bookmark rather than the link.
- Does https mean a site is legitimate?
- No. The padlock means the connection is encrypted and that someone proved control of that name to a certificate authority. Lookalike names get certificates as easily as anyone else, so a padlock on secure-example.test tells you nothing about whether it belongs to example.com.
- How do I check who owns a domain?
- Look up the registration record through RDAP, the successor to WHOIS, which returns the creation date and the registrar in a standard format. Many registries withhold the registrant’s name, but the creation date alone tells you whether a name claiming to be an established company was registered last month.
- What does xn-- at the start of a domain mean?
- It is the Punycode form of an internationalised label: the ASCII encoding the registry holds for a name written in non-ASCII characters. It is ordinary for legitimate names in many languages. It matters when the name you were shown looked like a familiar Latin brand, because the xn-- form then reveals that the characters were not the ones they resembled.
- Is a domain with a hyphen fake?
- Not by itself; hyphens are ordinary. What matters is that a hyphen does not separate ownership the way a dot does. example-login.test is a separate registration from example.com, unrelated by default, so a hyphenated name should be judged as a different domain that happens to contain the brand.
Sources and further reading
- Public Suffix List
- Unicode Technical Standard #39: Unicode Security Mechanisms (confusables)
- RFC 5890: Internationalized Domain Names for Applications (IDNA): definitions
- RFC 3492: Punycode
- Chromium: IDN display policy
- Xudong Zheng: Phishing with Unicode domains (2017)
- Krebs on Security: Look-alike domains and visual confusion (2018)
- Unit 42: Cybersquatting: attackers mimicking domains of major brands
- UK National Cyber Security Centre: Phishing attacks: defending your organisation
- ICANN: Registration Data Access Protocol (RDAP)
- Typosquatting.ai: methodology and data sources