A phishing email landed in my corporate inbox this morning. Nothing unusual about that — the subject line was the usual fiscal-subsidy bait, and our mail gateway had already stamped it with an external-sender banner. What caught my attention was the sender address:
財政補貼部 <group_all_quality2@govv.cnn>
.cnn. Not .cn. I went looking for what that top-level domain was, assuming I'd just never heard of it.There is no .cnn
IANA's Root Zone Database is the authoritative list of every delegated TLD. It's alphabetical, and in the relevant stretch it reads:
.cm country-code .cn country-code .co country-code
Nothing between
.cn and .co. .cnn is not delegated, has no registry, has no nameservers, and cannot be registered by anyone. No mail server on the public internet can deliver to it, and no resolver can look it up.So the attacker used an address that provably does not work. That seemed like a mistake at first. It isn't.
The visual trick
Read
govv.cnn quickly and it looks like gov.cn — a Chinese government domain. The construction is deliberate: double the final character of each label.gov.cn → govv.cnn
Same length family, same silhouette, same rhythm. It belongs to the same class of attack as rendering
rn where the reader expects m, except it needs no special characters and survives being displayed in any font. The target isn't a parser. It's the two hundred milliseconds a human spends on a From line.Why an unregisterable domain is useful
This is the part I found genuinely interesting. SMTP carries two separate sender identities, and nothing in the protocol requires them to agree.
MAIL FROM: <bounce@attacker.example> ← envelope sender, RFC 5321 ... From: 財政補貼部 <group_all_quality2@govv.cnn> ← header, RFC 5322
The envelope sender is what the receiving server negotiates with. The
From: header is just text inside the message — it's what your mail client renders, and it can say anything. Same as writing whatever return address you like on a paper envelope.Three mechanisms were bolted on later to constrain this:
- SPF (RFC 7208) — is the sending IP authorised to use the envelope domain?
- DKIM (RFC 6376) — a cryptographic signature over selected headers and the body, verified against a public key published in the signing domain's DNS.
- DMARC (RFC 7489) — the one that matters here. It requires the visible
From:domain to align with an SPF- or DKIM-authenticated domain, and lets a domain owner publishp=reject.
Now consider what happens when the
From: domain doesn't exist in DNS at all. There is no SPF record to fail against. There is no DKIM public key to check a signature that was never made. There is no DMARC record, so no policy applies.Every check that could reject the message needs a DNS lookup to produce a verdict, and a domain outside the root zone produces no verdict at all. Absence isn't failure — it's silence. The message falls through to heuristics and lands in the inbox with a warning banner, which is exactly where mine ended up.
There's a second benefit for the attacker: an unregisterable domain cannot be seized, sinkholed, or reported to a registrar. There's no registrar. And they never wanted a reply anyway — the payload is the link.
What actually authenticates a sender
In Gmail, open the message and click ⋮ → Show original. The summary block at the top gives you the verdicts directly:
SPF: PASS with domain nvidia.com DKIM: PASS with domain nvidia.com DMARC: PASS
The faster version is the ▾ next to "to me", which shows mailed-by (SPF) and signed-by (DKIM). If signed-by matches the domain in the
From: address, DKIM verified it and DMARC alignment holds.Two things on that screen that are not trust signals:
- "Standard encryption (TLS)" — transport encryption between servers. Says nothing about who sent the message.
- Absence of a brand logo — the blue check plus logo is BIMI, which requires DMARC enforcement and a Verified Mark Certificate proving trademark ownership. Its presence is a strong positive signal; its absence means nothing at all.
While you're in the raw headers, check
Reply-To:. Legitimate mail usually omits it or keeps it on the same domain. Gmail's compose view honours it silently, so a mismatch only surfaces when you've already started typing a reply.The limit of all this
Here's the trap I had to think through, because I use the "send me an email from your company address" test on recruiters.
Authentication proves the message came from the domain in the
From: header. It says nothing about whether that is the right domain.bigcorp-careers.com will pass SPF, DKIM, and DMARC flawlessly — the attacker registered it and configured it properly. This is the cousin-domain attack, and it's now more common than raw spoofing precisely because DMARC works. Blocking the easy path pushed everyone onto the slightly harder one.So the email test is necessary but not sufficient. What closes the loop:
- Read the domain string character by character against the one on the company's official site. Not the shape of it — the characters.
- Confirm through a channel you looked up yourself. The switchboard number from the company website, not a number in the email.
- Remember that a compromised real mailbox passes every check that exists.
Takeaway
The interesting thing about
govv.cnn isn't that it's fake. It's that being impossible is strictly better for the attacker than being merely fake — a registered lookalike domain has a registrar that can suspend it and DNS records that can fail a check. A domain outside the root zone has neither. It gets to be unverifiable rather than invalid.Email authentication answers "did this domain send this?" It has never answered "should I trust this domain?" That second question is still on us.