What is an IDN homograph attack, and how do you spot a lookalike domain?

Key takeaways

• Internationalized domain names (IDNs) let a label use any script. In DNS, each such label travels as an ASCII xn-- form produced by Punycode (RFC 3492); browsers decode it back to Unicode for display.
• A homograph attack exploits characters that look the same across scripts. exаmple.com with a Cyrillic “а” is a different domain from example.com, and its real name is xn--exmple-4nf.com.
• Single-script non-ASCII names are normal. Mixed-script labels, and all-Cyrillic or all-Greek labels that spell a Latin word, are the warning signs.
• Browsers show Punycode instead of Unicode when a label fails their spoofing checks. Chrome’s published policy is built on Unicode UTS #39.
• AdminKit’s IDN homograph check shows both forms and flags risky characters in your browser. It never queries DNS or WHOIS, so pair it with lookups before deciding anything.

How does a Unicode domain become xn—?

DNS was built for a small set of characters: letters, digits and the hyphen. Internationalized Domain Names in Applications (IDNA) adds Unicode without changing DNS itself. RFC 5891 defines the process: an application converts each non-ASCII label to an ASCII form before lookup, and converts it back for display.

RFC 5890 names the two forms. The Unicode form a person reads is a U-label. The ASCII form that goes into DNS is an A-label: the prefix xn-- followed by the Punycode encoding of the U-label. RFC 5890 says “a valid A-label is the result of Punycode encoding of a U-label”, and that A-labels “should be produced only in lowercase”.

U-label (what you read)	A-label (what DNS sees)	Scripts in the label
münchen	xn--mnchen-3ya	Latin only
öbb	xn--bb-eka	Latin only
exаmple (Cyrillic “а”)	xn--exmple-4nf	Latin + Cyrillic
еxample (Cyrillic “е”)	xn--xample-2of	Latin + Cyrillic
example	example	ASCII only, no conversion

The first two rows are ordinary German and Austrian names. The öbb.at example comes from Chrome’s own IDN documentation. The middle two rows show why A-labels matter for security: the two lookalikes render almost exactly like example in many fonts, but their A-labels are completely different strings. Software, DNS and certificates all work with the A-label, so to a machine there is no resemblance at all.

What makes two domains look the same?

Unicode contains many characters that look alike in common fonts. Latin “a” (U+0061) and Cyrillic “а” (U+0430) are the classic pair, and Chrome’s IDN document uses exactly that example: someone “could register http://ebаy.com (using Cyrillic “а”), which could be confused for http://ebay.com”.

Unicode Technical Standard #39 catalogues these characters and defines how to compare strings. Each string is mapped to a skeleton by replacing every character with a representative lookalike; two strings are confusable “if and only if skeleton(X) = skeleton(Y)”. UTS #39 then separates the attacks into types:

UTS #39 term	What it means	Example
Mixed-script confusable	A label that combines scripts and is confusable with a single-script label	exаmple: Latin letters plus one Cyrillic “а”
Whole-script confusable	A label written entirely in one script that is confusable with a label in another script	UTS #39’s example: “ѕсоре” spelled in Cyrillic, which “would pass the single-script test”
Single-script confusable	Characters within one script that look alike	Digit 1 and lowercase l in plain ASCII

Whole-script confusables are the hard case. A label made only of Cyrillic letters is a valid, single-script name, and UTS #39 notes that such labels are legitimate under a Cyrillic top-level domain. The same label under .com, spelling a Latin brand name, is the attack. RFC 5890 §4.4 makes the same point: “there are many strings that are entirely in Greek or Cyrillic scripts that can be confused with each other or with Latin script strings”.

RFC 5890 is also clear about the limits: “there are no comprehensive technical solutions to the problems of confusable characters. One can reduce the extent of the problems in various ways, but probably never eliminate it.”

How do browsers decide what to show in the address bar?

Because DNS accepts the lookalike, the last line of defence is how the browser displays it. RFC 5890 §4.4 suggests that “implementations provide visual indications where a domain name contains multiple scripts”. In practice, browsers display a suspicious label as its xn-- A-label instead of the Unicode form.

Chrome publishes its IDN display policy. It decides “for each domain label (component) of a hostname separately”, and shows Punycode when a label fails any of a series of checks. The main ones, paraphrased from the Chromium document:

1. The label contains characters not allowed in identifiers under UTS #39, or characters on Chrome’s own disallowed list.
2. The label mixes scripts in a way UTS #39’s “Highly Restrictive” profile does not allow, with an extra rule that “Latin, Cyrillic or Greek characters cannot be mixed with each other”.
3. The label mixes numbering systems, contains invisible characters, or uses characters in an unusual way.
4. The label is a mixed-script confusable, or a whole-script confusable under a top-level domain not associated with that script. The document’s example is аррӏе.com in Cyrillic, shown as xn--80ak6aa92e.com.
5. The registrable part of the hostname, after removing diacritics and mapping lookalikes, has the same skeleton as one of a list of top domains.

Two consequences follow. First, if you see xn-- in the address bar for a name you expected to read normally, the browser is telling you it does not trust the Unicode rendering. Second, these policies differ between browsers and change over time, and they do not cover places where a domain is shown as plain text: email bodies, chat messages, PDF documents and printed material. A user reading a link in a message relies on their own eyes, which is exactly what the attack targets.

How do you check a suspicious domain?

When a link or sender domain looks slightly off, work through it in this order:

1. Paste it into the IDN homograph check. It extracts the hostname, splits it into labels, and shows each label’s A-label and U-label. It flags non-ASCII characters, labels that mix scripts, and characters from a curated confusables list. The tool page is explicit that its list is “a small, hand-picked subset” of UTS #39, not the full table, so a clean result is not a guarantee.
2. Compare the A-label with the real domain. If the domain you expected is ASCII, any xn-- label in the suspicious one means it is a different name.
3. Look up who holds it. Use the WHOIS tool to see the registration date and registrar; how to read a WHOIS/RDAP lookup result explains the fields. A lookalike registered days ago is a strong signal.
4. See what it points to. A DNS lookup shows whether the domain has A, MX or TXT records. MX records on a lookalike suggest it is set up to send or receive email; see how to read a DNS lookup result.

A flag from the homograph check is a reason to look closer, not a verdict. The tool page says so directly: plenty of flagged domains “are entirely legitimate, non-English registrations”.

Where do lookalike domains show up in email?

Email is where lookalikes do the most damage, because mail clients often display the sender’s domain as text without any browser-style protection. A message from a lookalike domain can pass authentication: RFC 8601, which defines the Authentication-Results header, warns that an attacker “could register examp1e.com” and send signed mail, and a verifier “would detect that the signature was valid and report a ‘pass’”. SPF, DKIM and DMARC prove which domain sent a message, not that it is the domain the reader thinks it is.

So when a message is suspicious, read the domain in its headers, not only the display name. How to read email headers to trace a message shows where the authenticated domain appears, and the email header analyzer lists every Authentication-Results verdict so you can paste the domain into the homograph check.

How do you watch for lookalikes of your own domain?

No single tool finds every lookalike, but a few habits cover most of the ground:

Practice	What it catches	Notes
List the confusable variants of your main label	Mixed-script and whole-script lookalikes	Start from UTS #39’s confusables data; run each candidate through the homograph check to get its A-label
Check those A-labels with WHOIS and DNS lookup	Variants already registered	Repeat periodically; a newly registered variant is worth investigating
Watch Certificate Transparency logs for your brand	Lookalikes that obtain TLS certificates	Certificates are logged by the A-label; see certificate transparency logs explained
Read your DMARC aggregate reports	Mail claiming to be your exact domain	Lookalikes use their own domain, so DMARC protects only the exact name
Consider registering the most convincing variants	Takes them off the market	Subject to each registry’s IDN rules

Registries also play a part. RFC 5891 §4.3 says registries “are expected to establish policies about label registrations”, including rejecting a label “based on other labels already registered”. Many publish which characters they accept per script; IANA collects these in its Repository of IDN Practices. Rules vary widely between top-level domains, so check the specific registry’s table before assuming a variant can or cannot be registered.

Report a lookalike that is actively used for phishing to the registrar or hosting provider shown in its WHOIS record; how to file an abuse report from a WHOIS result covers what to include.

This guide is part of AdminKit’s DNS cluster.

This guide is general information, not a security audit of your specific network — see our disclaimer for what AdminKit's guidance does and does not commit to.