By most measures, the IPv6 transition is a slow-motion success. Major browsers, CDNs, and mobile networks moved years ago, and a large share of consumer web traffic now rides v6 end to end. Then there is email. When we resolve the MX hosts behind the Tranco top-1M domains in our daily email infrastructure report, the picture looks like a protocol frozen in a different decade. As of the 2026-07-05 snapshot, just 4.96% of self-hosted MX hosts — 1,570 of the 31,666 we checked — publish an AAAA record at all.
For comparison, Google's own MX hosts are 90% IPv6-enabled. That is not a rounding-error difference; it is a structural split between a handful of hyperscalers who can afford to solve v6 mail properly and a long tail of operators for whom the incentives simply do not exist yet. This article looks at what the numbers say and why the economics of email, uniquely among major protocols, still favour IPv4.
The numbers: a protocol split in two
Our scanner classifies each domain's mail hosting from its primary MX record, then resolves the MX hostnames for address records. Within the self-hosted population — domains running their own mail infrastructure rather than pointing at Google, Microsoft, or another managed provider — IPv6 presence is rare and unevenly distributed:
- 4.96% overall. 1,570 of 31,666 checked self-hosted MX hosts publish AAAA. More than nineteen in twenty self-hosted mail servers are reachable over IPv4 only.
- .org leads the TLDs at 8.28%. The nonprofit and open-source-adjacent operators behind .org run ahead of the pack — consistent with a population that deploys v6 on principle rather than on ROI.
- Hyperscalers sit near saturation. With Google's MX fleet at 90% AAAA coverage, a large fraction of actual mail volume can already flow over IPv6 — but only between the big providers. The moment a message needs to reach a self-hosted server, it almost certainly falls back to v4.
Note what this means in combination with market structure: as we showed in our decade retrospective, self-hosted mail still covers 22.53% of MX-publishing domains. So the part of the ecosystem that is least IPv6-ready is also the part with the most independent operators — exactly where a protocol transition is hardest to coordinate.
Why email lags the web by a decade
The usual explanation for slow IPv6 adoption — "nobody needs it because NAT works" — does not fully apply to servers, which have static public addresses either way. Email's v6 problem is more specific: the entire anti-abuse machinery of SMTP was built around IPv4 semantics.
- IP reputation assumes scarce, stable addresses. Sender reputation systems and DNS blocklists work because IPv4 addresses are expensive and long-lived: a spammer who burns a /24 has lost something. In IPv6, a single allocation hands an operator more addresses than the entire v4 internet, making naive per-address reputation useless and per-prefix reputation a design problem the industry has only partially solved.
- Receivers are stricter on v6 by design. Large mailbox providers compensate for the weaker reputation signal by requiring more from IPv6 senders — valid forward-confirmed reverse DNS and authenticated mail are effectively table stakes on v6 connections. For a small operator, that means enabling AAAA on an MX can make delivery less reliable overnight if any of those pieces is imperfect.
- Blocklist coverage is asymmetric. Decades of curated IPv4 blocklist data have no v6 equivalent of comparable depth. Some operators conclude that accepting v6 connections means accepting traffic their filters understand less well — so they simply do not publish AAAA on the inbound path either.
- There is no user-visible payoff. A website on v6 serves mobile users marginally faster. A mail server on v6 delivers the same messages at the same speed. With zero perceptible benefit and nonzero deliverability risk, "later" is the rational default.
On the web, enabling IPv6 is a performance optimisation with no downside; in email, it is a reputation gamble with no upside — so the web moved and email did not.
What this means for mail operators
If you run your own mail infrastructure, the data suggests a pragmatic rather than ideological posture. Publishing AAAA on your MX today puts you in the 4.96% — commendable, but only safe if the rest of your stack is ready for the stricter treatment v6 mail receives:
- Matching forward and reverse DNS (
PTR) for every IPv6 address that sends or receives mail, without exception. - SPF records that include your v6 ranges via
ip6:mechanisms before any AAAA goes live on a sending host. - DKIM signing on all outbound streams — on IPv6 paths, authentication effectively replaces IP reputation as your identity.
- Separate monitoring for v6-path delivery failures, because a broken v6 setup fails silently: receivers fall back to v4 (masking the issue) or defer (creating latency you will not see in aggregate stats).
For everyone else — deliverability engineers auditing a client, or researchers tracking the transition — MX AAAA coverage is a useful single-lookup maturity probe. An operator who has done v6 mail properly has, almost by construction, also done rDNS, SPF, and DKIM properly. The 8.28% .org figure is a nice illustration: the communities most likely to care about open standards lead adoption even when the economics are indifferent.
We publish the underlying counts nightly. The self-hosted population, its IPv6 share, and the per-TLD breakdown are all part of the infrastructure section of the report, with machine-readable data in api/latest.json. If the fortress ever starts to fall, it will show up there first — our methodology for the self-hosted classification itself is documented in how we classify a million domains nightly.