What 10,000 domains actually publish for email authentication in 2026

Vadim Ivanov — Sat, 27 Jun 2026 09:51:27 +0000

Email authentication has been "solved" on paper for years. SPF, DKIM, and DMARC are old standards, every deliverability guide repeats them, and Google and Yahoo made DMARC effectively mandatory for bulk senders in 2024. So I expected the top of the web to be in good shape.

In June 2026 I ran SPF, DKIM, DMARC, and MTA-STS checks across the Tranco top 10,000 domains, using public resolvers (1.1.1.1 and 8.8.8.8) and the same checks my own tool runs. The records are public DNS, so anyone can reproduce this. The picture is worse than the "solved problem" framing suggests, and the interesting part is not adoption, it is where people stop.

A third of the top 10k still have no DMARC

3,318 of the 9,937 domains that resolved (33.4%) publish no DMARC record at all. These are not obscure sites, they are the most-visited domains on the web. Without DMARC a receiver has no published instruction for what to do when SPF and DKIM fail, and you get none of the aggregate reporting that tells you who is sending as you.

It does get better at the very top. Among the top 1,000 domains, 28.4% have no DMARC, versus 34% across the rest of the 10k. Better, not good.

The real problem is p=none, not missing records

This is the number that actually matters. Of the 6,619 domains that do publish DMARC, only 46.5% are at p=reject. About a quarter (26%) are still sitting at p=none.

p=none is monitor-only. It asks receivers to report what they see and to enforce nothing. It is the correct first step: publish p=none, collect aggregate reports, fix the sources that should be passing, then tighten the policy. The trouble is that p=none is also where most deployments quietly stop. The reports start arriving, nobody reads them, and the domain sits unprotected behind a policy that does nothing while looking like progress.

Moving from p=none to p=reject is the step that turns DMARC from a dashboard into a defense, and it is the step most people never finish. I wrote up the safe way to make that move, since it is the question I get most often: read your aggregate reports until every legitimate source aligns, go to p=quarantine, then p=reject, raising pct if you want to ease in.

SPF is widespread but quietly broken on some domains

25% of the domains have no SPF record, higher than I expected for the top of the web. A smaller but more interesting group, 1.7%, publish an SPF record that exceeds the 10 DNS-lookup limit from RFC 7208. Once you cross that limit the record returns a permerror, so SPF effectively fails even though a record exists and looks fine to the eye. This usually creeps in through include: chains: you add a few SaaS senders, each brings its own includes, and one day you are over ten lookups without having changed anything visible. It is the kind of failure you only catch if you count.

Transport security is basically unused

This is the most lopsided result in the scan. 97.8% of the domains have no MTA-STS policy (RFC 8461), and 97.1% publish no TLS-RPT. MTA-STS is what lets a sending server insist on TLS and a valid certificate when delivering to you, closing the downgrade gap that plain STARTTLS leaves open. Nearly the entire top 10k has skipped it. Some of that is fair, MTA-STS needs a policy file served over HTTPS on an mta-sts. subdomain plus a DNS record, so it is more work than a single TXT entry. But "more work" does not explain a 2% adoption rate at the top of the web.

BIMI is still early

8.9% of domains publish a BIMI record, climbing to 15.7% in the top 1,000. That fits: BIMI rewards brands that already enforce DMARC and have budget for a verified mark. It is the one area where low adoption is genuinely fine, BIMI is optional and brand-driven, not a security baseline.

What I take from this

The headline is not "people don't adopt email auth." Most of the top 10k publish SPF and DMARC. The gap is follow-through: a DMARC record stuck at p=none, an SPF record one include over the limit, a transport-security feature nobody enabled. Each of these looks like a configured domain and behaves like an unconfigured one.

If you own a sending domain, the highest-value 20 minutes you can spend is checking which of these you are actually in: is your DMARC enforcing or just watching, is your SPF under the lookup limit, and have you ever published an MTA-STS policy. The records are public, so the answer is one DNS lookup away.

Disclosure: I'm the founder of Relaymetry, a free SPF/DKIM/DMARC/MTA-STS checker, which is the tool I used to run this scan. The numbers are from a June 2026 crawl of the Tranco top 10,000; happy to share more on the methodology if anyone wants it.