Email Spoofing via IDN Homograph Domains

// TL;DR

---

Why this isn’t “normal” spoofing

Classic email spoofing forges the sender — you claim to be security@bank.com from a domain you don’t control, and the defence against it is SPF/DKIM/DMARC: the receiving server checks whether the sending server is authorised for that domain, and rejects it if not.

This technique sidesteps that entire model. I never forge anyone’s domain. I register a brand-new domain that I fully control and authenticate correctly — it just happens to look identical to a trusted one when the mail client displays it. There’s nothing for SPF/DMARC to catch, because from the protocol’s point of view the email is completely legitimate. The attack lives in how the address is rendered to the human, not in the mail authentication layer.

IDN and Punycode, briefly

Domain names were originally ASCII-only. Internationalised Domain Names (IDN) let domains contain Unicode characters (for non-Latin scripts and accents). Since DNS still works in ASCII under the hood, Unicode domains are encoded into an ASCII form called Punycode, which always starts with the xn-- prefix.

So a Unicode domain and its Punycode form are the same domain, written two ways:

• Punycode (what DNS and the raw headers use): xn--eby-7cd.com
• Unicode (what a client may choose to display): a string that looks like ebay.com

The security problem is the homograph attack: many Unicode characters look identical or near-identical to Latin letters. An attacker registers a Punycode domain whose Unicode rendering is visually indistinguishable from a trusted brand — and if software displays the Unicode form without safeguards, the user can’t tell the difference.

The finding

I registered an IDN/Punycode domain and sent an email from it to accounts on the target mail services. In the raw form the sender was something like:

From: ... @ xn--eby-7cd.com

But Hey.com rendered it as ebay.com in the interface — it decoded the Punycode to its Unicode form and displayed that look-alike directly, with no indication that the real domain was an internationalised one. To the recipient, the email simply appeared to come from eBay.

The same behaviour was present in Yandex Mail: it rendered the homograph domain as the trusted-looking name rather than flagging it or showing the raw Punycode.

So with a cheap domain registration and no forgery at all, I could make mail appear to come from essentially any brand whose name can be reproduced with look-alike Unicode characters.

Why it defeats SPF/DMARC/DKIM

This is the part worth dwelling on, because it’s what makes the issue serious rather than cosmetic.

• SPF checks that the sending server is authorised for the sending domain. My domain is the sending domain, and I authorise my own server → pass.
• DKIM verifies a signature from the sending domain. I sign with my own domain’s key → pass.
• DMARC checks alignment between the authenticated domain and the visible From: — and here they align, because the From: genuinely is my xn--… domain → pass.

Every anti-spoofing control is satisfied, because nothing is being spoofed at the protocol level. The deception happens one layer up, when the client converts xn--eby-7cd.com into a friendly Unicode string and shows the user a brand they trust. That’s why “turn on DMARC” — the usual answer to spoofing — does nothing here.

Impact

• Highly convincing phishing. The sender displays as a legitimate domain, so the single check users are taught to rely on (“is this really from who it says?”) passes visually. Victims have no obvious tell.
• Works against any brand. Any name reproducible with look-alike characters can be impersonated, with only a domain registration.
• Authentication offers no protection. Because SPF/DKIM/DMARC all pass, security tooling that trusts those signals may treat the mail as fully legitimate.

Put together: an attacker can land brand-impersonating email in inboxes, passing every authentication gate, with the recipient seeing a trusted sender.

The fix

The defence belongs in the mail client’s rendering, since the protocol layer can’t catch it:

• Display Punycode (xn--…) for suspicious IDNs rather than silently decoding to Unicode — or show both forms so the user can see the real domain.
• Apply IDN display policy like browsers do: modern browsers show the raw Punycode when a domain mixes scripts (e.g. Latin + Cyrillic) or otherwise looks like a homograph, instead of rendering the look-alike. Mail clients should do the same.
• Flag or quarantine look-alike / mixed-script sender domains, especially when they resemble well-known brands.

Disclosure

I reported this to Basecamp (for Hey.com) — it was triaged as a duplicate, so no bounty. I also reported it to Yandex, who didn’t respond. Both services were vulnerable at the time and have since fixed the rendering. I’m documenting it here now that it’s resolved.

Takeaways

• Spoofing isn’t only forgery. You don’t have to forge a domain to impersonate a brand — a look-alike domain you legitimately own does it, and sails through SPF/DMARC/DKIM because nothing is actually being forged.
• Authentication ≠ authenticity. “The email passed SPF/DKIM/DMARC” means it came from the domain it claims — not that the domain is who the user thinks it is. Homograph domains exploit exactly that gap.
• Rendering is a security decision. The moment software decodes xn--… into a friendly Unicode string, it’s making a trust call. Browsers learned this years ago and show Punycode for risky IDNs; mail clients need the same discipline.
• When testing a mail service, test the display layer. Send yourself an IDN/Punycode sender and see what the client shows. If it renders a look-alike instead of the raw domain, that’s the bug.

Thanks for reading — hope it was useful. Happy hacking!