Homograph and IDN spoofing domains

5 April 2026 · 11 min read

There is a category of email fraud that DMARC was never designed to stop, and homograph attacks sit right at the centre of it. An attacker does not forge your domain. They register a different domain that looks identical to yours in a recipient's mail client, publish perfectly valid email authentication on it, and send mail that passes every check. The message arrives looking trustworthy because, to a human eye, the sender address is your address. To the machine, it never was.

This article is specifically about the Unicode and internationalised-domain-name (IDN) flavour of look-alike attacks: domains built from confusable characters drawn from non-Latin scripts. It explains how the trick works at the Punycode and DNS level, exactly why DMARC, SPF and DKIM give you no protection against it, how to detect and prioritise the variants that actually matter, and what a realistic defence looks like when DNS policy is not the lever.

If you want the broader family of confusable-but-different domains (character swaps, alternative top-level domains, added letters), the glossary entry on lookalike and cousin domains covers that. Here we go deep on the homograph and IDN case, because it is the one most likely to defeat a trained, careful recipient.

What a homograph attack actually is

A homograph (or homoglyph) attack exploits the fact that different Unicode code points can render as the same or near-identical glyph. The Latin letter a (U+0061) and the Cyrillic letter а (U+0430) are visually indistinguishable in almost every typeface, yet they are entirely separate characters with different byte values. To DNS, paypal.com spelled with a Latin a and pаypal.com spelled with a Cyrillic а are two completely unrelated domains.

The same applies to dozens of other pairs:

• Cyrillic о (U+043E) versus Latin o (U+006F)
• Cyrillic е (U+0435) versus Latin e (U+0065)
• Greek ο (U+03BF) versus Latin o
• Latin small letter l versus the digit 1 versus capital I in certain fonts
• The Turkish dotless ı (U+0131) versus Latin i
• Mathematical and full-width variants of ASCII letters

An internationalised domain name (IDN) is what makes any of this reach DNS at all. DNS itself only speaks ASCII. To support non-ASCII scripts (so that people can register domains in Arabic, Cyrillic, Han, Devanagari and so on), Unicode domains are encoded into an ASCII-compatible form called Punycode using an algorithm defined in RFC 3492, prefixed with xn--. The IDNA standards (RFC 5890 onwards) tie this together.

So the homograph domain that a victim sees as apple.com might actually be registered, and live in DNS, as something like:

аpple.com   (display form, first letter is Cyrillic U+0430)
xn--pple-43d.com   (actual DNS / Punycode form)

The attacker controls xn--pple-43d.com. They own it outright. That distinction is the whole problem.

Why DMARC, SPF and DKIM cannot stop it

This is the part that surprises people who have just finished moving their domain to p=reject and assume they are now protected against impersonation. They are protected against forgery of their own domain. A homograph domain is not their domain.

Walk through what each mechanism checks:

• SPF verifies that the sending IP is authorised to send for the domain in the SMTP envelope (the Return-Path / MAIL FROM). The attacker's domain is xn--pple-43d.com, and they publish their own SPF record listing their own sending infrastructure. SPF passes for their domain.
• DKIM verifies a cryptographic signature against a public key published in the signing domain's DNS. The attacker generates their own key pair, publishes the public key under xn--pple-43d.com, and signs with it. DKIM passes for their domain.
• DMARC checks that the domain in the visible Header-From is aligned with an authenticated SPF or DKIM domain, and then applies the policy published by that Header-From domain. The Header-From is service@аpple.com, which DNS resolves as xn--pple-43d.com. That is aligned with the attacker's own SPF and DKIM. DMARC evaluates the policy of xn--pple-43d.com, which the attacker sets to whatever they like (commonly p=reject, to look legitimate and avoid clutter in their own reporting). DMARC passes.

Every authentication check returns a green tick. None of them is checking the thing that matters here, which is whether the domain is the one the recipient thinks it is. DMARC's job is integrity and alignment of a single domain, not semantic similarity between two different domains. There is no field in the SPF, DKIM or DMARC specifications that compares xn--pple-43d.com to apple.com and notices they look alike. That comparison is a human visual judgement, and the attack is engineered precisely to defeat it.

This is a fundamentally different failure mode from the ones that show up when DMARC fails but SPF and DKIM individually pass, or when your DMARC reports show unknown sources sending as your real domain. In both of those cases the abused domain is yours, so DMARC at enforcement does something useful. With a homograph domain, your DMARC record is simply never consulted. The mail never claims to be from your domain in the first place. It claims to be from a different domain that resembles it.

Where the spoof becomes invisible

The reason homograph IDN attacks are more dangerous than a crude misspelling like paypa1.com is the rendering layer. Several things conspire:

Mail clients display the Unicode form, not the Punycode. When a message arrives with a Header-From of xn--pple-43d.com, the receiving client decodes it back to аpple.com for display. The user sees the pretty version. The xn-- form, which would instantly give the game away, is hidden. So the sender column reads Apple Support <service@аpple.com> and looks exactly right.

The address may pass a careful read. Security-aware users are taught to check the domain, not just the display name. With display-name spoofing the real domain is visible and wrong if you look. With a homograph domain the real domain is the lure, and looking harder does not help, because the glyphs are identical.

Links inside the body reinforce it. The attacker controls the look-alike domain, so they can stand up a TLS certificate for it, host a convincing login page on https://аpple.com/account, and the browser shows a valid padlock. Certificate authorities issue certs for IDN domains. The padlock confirms the connection is encrypted to a domain the user cannot distinguish from the real one.

Mixed-script confusables widen the keyboard. Attackers do not need a single perfect substitution. They can mix scripts across the label to find a combination that renders cleanly in popular fonts, then test it against the rendering used by Gmail, Outlook, Apple Mail and the major mobile clients until they have one that holds up everywhere they care about.

The net effect is a sender address that is visually your address, cryptographically authenticated, served over HTTPS with a valid certificate. The only thing wrong with it is the byte values, which nobody sees.

What the defenders have done, and its limits

This attack class has been known for over twenty years, so there are partial mitigations baked into the ecosystem. They help, but none of them closes the gap for email, and you should not rely on them.

Browser IDN display policies. Modern browsers refuse to show the Unicode form and instead display raw Punycode (xn--pple-43d.com) when a label mixes scripts in suspicious ways, or when the whole label is in a script that does not match the user's locale or the TLD's expected script. This is genuinely effective in the address bar. It does almost nothing for email, because mail clients do not consistently apply the same logic, and the dangerous moment (reading the sender) happens before any click.

Registry and registrar script rules. Many TLD registries restrict which scripts can be mixed within a single registration, or bundle confusable variants so an attacker cannot register the look-alike of an existing name. Coverage is patchy and varies enormously by TLD. The newer and more permissive TLDs are where the gaps live, and there are a great many TLDs.

Unicode's confusables data. The Unicode Consortium publishes a confusables mapping (the data behind UTS #39) that lists which code points are visually confusable with which. This is the raw material defenders use to generate the list of variants to watch for, and it is exactly what a good look-alike detector runs against. It is a detection input, not a protection.

The honest summary: there is no DNS record you can publish on your own domain that prevents someone registering a homograph of it and authenticating mail from it. Defence is detection, monitoring and takedown.

How to defend in practice

Because the lever is not DNS policy, the work splits into three jobs: lock down your real domain so attackers are forced onto look-alikes, hunt the look-alikes, and shorten the time between registration and takedown.

1. Enforce DMARC on your real domain anyway

This sounds contradictory given everything above, but it is the foundation. If your real domain sits at p=none, an attacker has the easy option: forge your exact domain, which costs nothing and needs no registration. Only when your real domain is at p=reject with aligned SPF and DKIM does direct forgery stop working, which is what pushes criminals towards the harder, more expensive homograph route in the first place. Confirm your enforcement posture with the DMARC checker, and verify your SPF and DKIM with the SPF checker and DKIM checker. The requirements overview explains what enforcement involves end to end.

Enforcing also keeps your aggregate reports clean, which matters for the next step: when your own domain is no longer a noisy source of failures, genuinely anomalous activity stands out.

2. Enumerate and monitor the variants

You cannot defend against look-alikes you have never listed. Generate the realistic homograph and confusable permutations of your brand domains and check which already exist in DNS or hold a certificate. Useful inputs to enumerate:

• Single-character Cyrillic, Greek and Latin-extended substitutions for each letter in your domain
• Digit-for-letter swaps (0/o, 1/l/i, 5/s)
• The rn for m and vv for w glyph-pair tricks
• The same base name under other TLDs, especially recently launched ones

A look-alike domain checker automates the permutation and registration lookup so you are working from a real list rather than guessing. The point is not to register every variant (there are too many) but to know which ones an attacker has already taken or could plausibly take next, and to watch for new registrations.

3. Defensively register the highest-risk variants

For the small number of permutations that are both highly convincing and cheap, defensive registration is rational. You will never register them all, and trying is a money pit, so prioritise:

• Exact homographs in widely supported scripts that render perfectly in Gmail and Outlook
• Variants on the same TLD as your primary domain
• Names that map to your highest-value workflows (billing, password reset, invoice/payment)

Registering a variant and pointing it nowhere (no MX, no web) denies it to attackers cheaply. It does not stop a determined adversary finding the next-closest glyph, which is why registration supports monitoring rather than replacing it.

4. Read your DMARC reports for what they can tell you

Your aggregate reports will not contain the homograph domain itself, because that mail is never sent as your domain. What they can surface is reconnaissance and adjacent abuse: spikes in failures from unfamiliar infrastructure, or attempts to forge your exact domain that immediately precede a pivot to look-alikes. Feeding your RUA data into the DMARC report analyzer turns the raw XML into source-by-source detail, so an unusual sending pattern becomes visible. Continuous monitoring with change alerts means a new failure source or a sudden change in your own authentication does not wait for a quarterly review to be noticed.

5. Make your real mail visually distinctive

If recipients have a reliable visual cue for genuine mail from you, a look-alike that lacks that cue becomes easier to question. BIMI displays your verified logo beside authenticated, DMARC-passing mail from your real domain. A homograph domain cannot show your verified logo, because the logo is tied to your domain's DMARC and, for the strict tiers, to a verified mark certificate. It is not a complete defence (logo display support varies by mailbox provider, and absence of a logo is a weaker signal than presence of one), but it raises the bar and gives trained users something concrete to look for. The BIMI product page and the BIMI checker cover setup and verification.

A worked example

Suppose your domain is northwind.example and you run customer billing from billing@northwind.example, fully authenticated at p=reject.

An attacker cannot forge northwind.example directly; your enforcement blocks it. So they register:

nоrthwind.example   (display form, the first "o" is Cyrillic U+043E)
xn--nrthwind-...   (the Punycode DNS form they actually control)

On that domain they publish:

v=spf1 include:_spf.attacker-sender.example -all
selector._domainkey.<punycode>   IN  TXT  "v=DKIM1; k=rsa; p=MIID..."
_dmarc.<punycode>   IN  TXT  "v=DMARC1; p=reject; rua=mailto:..."

They send an invoice from billing@nоrthwind.example. SPF passes (their IP, their record). DKIM passes (their key, their signature). DMARC passes (Header-From aligned with their own authenticated domain, policy is theirs). The recipient's client decodes the address for display and shows billing@northwind.example. The invoice links to a payment page on the same look-alike domain, served over HTTPS with a valid certificate. This is the mechanics of a phishing and business email compromise lure that no amount of authentication on northwind.example can touch.

What does touch it: you had already enumerated the Cyrillic-o variant, defensively registered the two most convincing permutations, were monitoring new registrations of the rest, and your finance team had been told that genuine billing mail always carries your BIMI logo. The fraudulent message had no logo and came from a variant on your watch-list, so it was reported instead of paid, and you filed a registrar abuse complaint the same day.

The practical takeaway

Homograph and IDN spoofing is the clearest reminder that email authentication and impersonation defence are two different problems. DMARC, SPF and DKIM prove that a message genuinely came from a given domain and was not tampered with. They say nothing about whether that domain is the one a human meant to trust. A homograph domain is authentically itself, and itself is a forgery of you that lives in the rendering layer, not in DNS policy.

So the strategy is layered: get your real domain to p=reject so direct forgery is off the table and attackers are pushed onto look-alikes you can hunt; enumerate the confusable variants that actually render convincingly; defensively register the few that are cheap and dangerous; monitor continuously for new registrations and for anomalies in your reports; and give recipients a visual trust signal that a look-alike cannot copy.

Start by confirming where your real domain stands today with the DMARC checker, then build the watch-list of confusable variants with the look-alike domain checker. If you would rather not run the enforcement, monitoring and look-alike hunting yourself, our done-for-you service takes your real domain to enforcement without breaking legitimate mail and keeps an eye on the rest, so the homograph that gets registered next week is something you hear about, not something your customers find out about the hard way.