Every domain on the public internet answers an implicit question: do you accept email? As of the 2026-07-05 snapshot of our daily email infrastructure report, 664,715 of the Tranco top-1M domains say yes by publishing at least one MX record. The interesting cases are the domains that want to say no. Parked domains, brand-protection registrations, API-only subdomain apexes, redirect shells — none of them want inbound mail, and each of them has to encode that refusal in DNS somehow.
Since 2015 there has been a standard for this: RFC 7505, the Null MX record. Our scan shows that a meaningful slice of the top million still improvises instead, and every improvisation degrades into a different failure mode on the sending side. This article catalogues what we found and explains why deliverability engineers should treat the distinction as operationally significant, not pedantic.
What RFC 7505 actually specifies
A Null MX record is a single MX record with preference 0 and a target of . — the DNS root, an intentionally impossible mail host:
example.com. 3600 IN MX 0 .The semantics are unambiguous. A compliant sending MTA that resolves this record must not attempt delivery at all. It generates an immediate permanent failure — "domain does not accept mail" — and the message never enters a retry queue. The domain owner also avoids the fallback trap: without any MX record, SMTP falls back to the domain's A/AAAA record, which means a parked domain with a web server can silently become a mail target. Null MX closes that door explicitly.
The improvised alternatives in the top million
Our scanner parses every MX record in the Tranco top-1M daily. Alongside the clean Null MX deployments, four broken "refusal" patterns recur, all figures as of the 2026-07-05 snapshot:
| Pattern | Domains | What a sender experiences |
|---|---|---|
MX 10 (empty target) | 4,925 | Empty MX target — resolvers and MTAs disagree on interpretation; typically a temporary error and days of retries |
MX 10 localhost | 502 | The sending MTA connects to itself (127.0.0.1) or refuses the loop; bounces are confusing and often delayed |
MX 10 ~ | 157 | A syntactically hostile target that fails resolution — treated as a transient DNS error, so the queue keeps retrying |
MX 10 mail | 253 | A bare, dot-less "mail" label that resolves nowhere (or somewhere unintended) — ambiguous NXDOMAIN retry behaviour |
MX 0 . | correct | Immediate permanent failure; message never queues, bounce is instant and machine-classifiable |
The common thread: every hack except Null MX produces an error that looks transient to the sending MTA. Transient errors trigger the retry schedule — typically escalating intervals over four to five days — before the message finally bounces with a timeout-flavoured diagnostic that says nothing about intent. The empty-target and tilde variants are the worst offenders, because they fail at the DNS layer rather than the SMTP layer, and DNS failures are almost universally retried.
Why the difference matters to senders
If you operate outbound email at any scale, these domains are in your lists whether you like it or not. The way they refuse mail determines what your infrastructure pays:
- Queue occupancy. A message stuck in retry against a localhost MX occupies queue slots and delivery workers for days. A few thousand such addresses in a large send is real capacity.
- Bounce classification. A Null MX rejection is a crisp permanent failure your suppression logic can act on after one attempt. A timeout after five days arrives late, with a diagnostic string that generic bounce parsers frequently misclassify as a soft bounce — so the address survives to be retried next campaign.
- List-hygiene signal. Verification tools that only check "does an MX exist" will happily validate a domain whose MX points at
~. Checking what the MX resolves to is the difference between a real validation and a checkbox.
Treat an MX target of ., an empty target, localhost, or an unresolvable single label as a permanent failure at validation time — before SMTP is ever attempted. All four patterns are visible in a single DNS lookup, and none of them ever converts into a delivered message.
Publishing Null MX correctly
For domain owners — and for deliverability teams advising clients with parked or send-only domains — the correct no-mail configuration takes three records:
- Remove every existing MX record. Null MX must be the only MX present; a Null MX alongside real MX records is undefined behaviour.
- Publish
MX 0 .at the apex (and at any subdomain that should refuse mail — Null MX does not inherit downwards). - Pair it with
"v=spf1 -all"in SPF and a DMARC record with a reject policy, so the domain can neither receive nor be spoofed as a sender. Refusing inbound mail says nothing about outbound abuse until you close that half too.
The zone file for a fully mail-inert domain looks like this:
example.com. IN MX 0 .
example.com. IN TXT "v=spf1 -all"
_dmarc.example.com. IN TXT "v=DMARC1; p=reject"We track the broken-refusal population daily as part of our top-1M scan. The counts above — 4,925 empty targets, 502 localhost, 157 tilde, 253 dot-less mail — move slowly, which itself is telling: these are not transient misconfigurations being noticed and fixed, they are permanent fixtures nobody is monitoring. The raw numbers refresh every night in api/latest.json if you want to watch them yourself.