Look-alike domains

A look-alike domain is a separately registered domain chosen to be mistaken for a real one: pay1ink.example for paylink.example, paylink-secure.example, the same name under a different ending, or a name spelled with Cyrillic letters that are pixel-identical to Latin ones. The attacker owns it outright, so they can publish SPF, sign with DKIM and even pass DMARC for the fake domain. Authentication results are honest; they just answer "which domain sent this?", and the answer is the wrong domain. The only defense is to read the domain carefully, and to let software compare it with the real one for you.

Note: The examples on this page use an invented company, Paylink, at the reserved name paylink.example. Real attacks use real endings such as .com; the tricks are the same.

Typosquats: letters that look alike

These rely on how text renders in small sizes and common fonts:

Capital letters make some worse: in many sans-serif fonts an uppercase I and lowercase l are identical, so PayIink.example is hard to spot. Domain names are case-insensitive, so the attacker's real domain is just payiink.example, but the display can use whatever case they like.

Extra words and hyphens

No misspelling at all, just a plausible addition: paylink-secure.example, paylink-billing.example, paylinksupport.example, or paylink.example-verify.test. The last one is a subdomain trick: the registered domain is example-verify.test, and paylink is just a label on the left. Always read a domain from the right: the part before the last dot and the ending decide who owns it.

Other endings

The same name under .net, .org, .co, a country code or one of the many newer generic endings. Many organizations register their name under the endings they care about, but nobody can register all of them.

Homographs: Unicode letters that look Latin

Domain names can contain non-ASCII letters, under the IDNA rules (RFC 5890). Many scripts have characters that look identical to Latin ones: Cyrillic а, е, о, р, с and Greek ο are the usual suspects. A domain like pаylink.example with a Cyrillic а looks exactly like the real thing, but it is a different name in DNS.

To fit into the ASCII-only DNS, each non-ASCII label is converted with Punycode (RFC 3492 §1) and given the prefix xn-- (RFC 5890 §2.3.2.5). The Unicode form is called a U-label and the encoded form an A-label (RFC 5890 §2.3.2.1). So the Cyrillic-а name above travels as xn--pylink-3nf.example in the DNS: the Latin letters are kept as they are, and the code after the last hyphen says which character to insert and where. RFC 5890 §4.4 acknowledges that visually similar characters are a problem IDNA cannot solve by itself and points to the Unicode Consortium's work on it.

In email this shows up in two places:

• Classic headers carry the A-label, so you may literally see xn-- in the From address or in Authentication-Results. DMARC also works on the A-label form (RFC 9989 §5.3.1).
• Internationalized email (EAI) allows UTF-8 directly in headers (RFC 6532 §3.2), so the Unicode form can appear as-is.

Tip: xn-- in a sender's domain is not proof of fraud. Plenty of legitimate businesses use their own language in their domain. It is a reason to decode it and look closely, especially when the decoded name resembles a brand you know.

How browsers and mail apps display them

Browsers apply rules to decide whether to show the Unicode form or fall back to the xn-- form, typically falling back when a label mixes scripts or resembles a well-known domain. The details differ between browsers and change over time. Mail clients are less consistent: some show the Unicode form, some the A-label, some whatever the header contains. Do not rely on the app to warn you.

Why authentication passes

SPF, DKIM and DMARC check that a domain authorized the message. The attacker owns pay1ink.example, so:

Authentication-Results: mx.example.net;
 spf=pass smtp.mailfrom=pay1ink.example;
 dkim=pass header.d=pay1ink.example;
 dmarc=pass header.from=pay1ink.example

Every result is correct. Nothing in the protocols knows which domain you meant. That comparison has to be made by a person or by look-alike detection software. A DMARC pass is only reassuring when the domain it passed for is one you recognize exactly. See DMARC explained.

How the analyser checks

When you paste headers into the analyser, it checks the From domain in your browser and compares it with every other domain in the message (Reply-To, Return-Path, Sender, DKIM signers, Received hosts, recipients and any address in the display name):

1. Punycode decoding. Any xn-- label is decoded and shown in both forms.
2. Mixed scripts. A single label mixing Latin with Cyrillic or Greek letters is flagged, following the mixed-script detection approach in Unicode Technical Standard #39, Unicode Security Mechanisms.
3. Confusable skeletons. Each name is reduced to a "skeleton" using Unicode's confusables data from the same standard, which maps characters that look alike (Cyrillic а to Latin a, and so on) to a common form. Two domains with the same skeleton look the same on screen, so if the From domain's skeleton matches another domain in the message that belongs to a different organization, it is flagged. The analyser has no list of famous brands to compare against, so a look-alike of a domain that appears nowhere in the headers is caught only by the mixed-script and punycode checks.
4. Digit-for-letter substitutions. 0 for o, 1 for l, rn for m and similar ASCII tricks the Unicode data does not cover.

These checks catch the common patterns but not everything: a convincing extra-word domain like paylink-billing.example is a new, valid name with no visual trick to detect. Your judgment still matters. For the rest of the process, see spotting phishing from headers and display name spoofing.