SPF and DMARC across the top 10,000 domains: 2026 data

We ran InfraNest's SPF and DMARC checkers over the 10,000 most popular domains on the Tranco list. Of the 7,204 that accept mail, only 55.7% pair a valid SPF record with a DMARC policy that is actually enforced. Most of the rest publish something that looks like email authentication, but it is either one change away from breaking or set up to block nothing.

This is the first InfraNest data report. The method and the aggregated numbers are public, and anyone can rerun the same checks on their own domain.

How we measured SPF and DMARC

• The list: the top 10,000 domains of Tranco list K9PXW, a research ranking of popular sites built to be hard to manipulate. Scanned on 25 September 2026.
• The checks: exactly the code behind our free SPF checker and DMARC checker. A number in this report is what those tools would tell the domain's owner.
• DNS: Cloudflare's resolver over HTTPS, with Google's as a fallback. 23 domains could not be read by either and are left out.
• Who counts: only domains that accept mail, meaning they have a real MX record. That leaves 7,204. The other 2,773 are mostly CDN, API and tracking hostnames that never send mail (75 of them say so explicitly with a null MX record).

Two definitions carry most of the numbers:

What we did not measure: DKIM, because its selectors cannot be listed from DNS; whether real mail passes alignment; and subdomains. The aggregated dataset is free to use with attribution.

A second opinion. We re-checked a random sample of 100 domains with checkdmarc, an independent open-source tool. The SPF verdict agreed for 98 of them, the lookup count for all 76 records both tools found valid, and the DMARC policy for 99; each remaining difference was a record checkdmarc could not read or objected to on style, which we confirmed by hand. The cross-check also caught a bug in our own checker: records that include the same provider through two senders were mistaken for include loops. It is fixed in our SPF checker too, and every number here comes from the corrected scan.

SPF: almost everyone has it, and one in six is close to breaking

92.9% of domains that accept mail publish an SPF record. The weak point is not whether an SPF record exists but how many DNS lookups it costs.

RFC 7208 allows a receiving server 10 DNS lookups to evaluate an SPF policy, and every include, a, mx and exists counts, including the ones nested inside a provider's include. At 11, the result is a permanent error, and receivers treat the domain as if it had no SPF at all.

• 2.7% of SPF records (184 domains) are already over the limit. Their SPF record does nothing.
• Another 14.3% use 8 to 10 lookups. Each include costs at least one lookup, and many providers nest further includes behind theirs. So a new CRM, helpdesk or newsletter tool is often enough to push these domains over, and nothing warns the person who adds it.
• The median record uses 4 lookups; one in ten uses 9 or more.
• 52 domains (0.8%) publish two SPF records. That is also a permanent error: with two records, receivers evaluate neither.

How records end is less worrying than it looks. 46.3% end in -all and 47.4% in ~all. With an enforced DMARC policy in front of it, ~all is a perfectly reasonable choice. Only 2.1% end in ?all, which asks for nothing, and just 3 domains end in +all, which authorises the entire internet to send as them.

TipCheck your own count with the free SPF checker. It walks every include the way a receiver does and shows which sender costs the most.

DMARC: widely published, enforced far less often

82.3% of domains that accept mail publish a DMARC record, but only 58.3% enforce it. The gap is p=none: a policy that asks receivers to report failures and do nothing about them.

Monitoring mode is the right way to start DMARC. It is the wrong place to stay, and the data suggests many domains never leave it: 21.8% of all mail domains are there right now.

The reporting side has its own problems:

• 11.0% of mail domains publish DMARC with no report address (rua) at all. They have a policy but no way to see what it catches.
• A further 5.3% send their reports to an address that will never receive them. When the report address is at another domain, RFC 7489 requires that domain to publish an authorisation record (<your-domain>._report._dmarc.<their-domain>). Without it, conforming receivers send nothing, and the owner concludes that nobody is sending mail as them.
• 2.1% of DMARC records apply their policy to only part of the mail with pct below 100.

The top 1,000 does better, but not much

Among the 1,000 most popular domains, 71.1% have valid SPF and enforced DMARC, against 54.1% for ranks 1,001 to 10,000. The top 1,000 is also more likely to use p=reject: 57.2% of its DMARC records, against 40.8% below it.

One thing gets worse at the top: 3.4% of the top 1,000's SPF records are over the lookup limit, against 2.7% below it. Bigger organisations send through more services, and every one of them costs lookups.

What I take from this

I expected to find neglect. I didn't. More than nine in ten of these domains publish SPF, and four in five publish DMARC. Someone, at some point, did the work. What goes wrong is everything after that first setup.

Nobody owns the record. Marketing adds a newsletter tool, sales adds a CRM, support adds a helpdesk, and each one quietly spends a lookup or two until the budget runs out. p=none was meant to be a few weeks of watching and becomes the permanent setting. And the reports go to an inbox nobody reads, or, for one domain in twenty, to an address that will never receive them.

I recognise that pattern. I spent twelve years building point-of-sale and automation systems for restaurants and shops, and it was always the same: the setup gets attention, the upkeep doesn't, because nothing breaks on the day you make the change. Email authentication is that kind of system. It fails quietly, weeks after the change that broke it, and the first sign is often a customer asking why your email ended up in their spam folder.

That is also why I built InfraNest's checkers to show the arithmetic instead of a green tick, and why I'll say plainly that our own SPF checker got one case wrong until this week. Checking this report against an independent tool is what caught it. If you measure things for other people, you check your own instruments first.

If your domain sends mail, these three checks are worth ten minutes this week:

1. Count your SPF lookups. At 8 or more, plan before the next tool arrives. Move bulk senders to a subdomain with its own SPF record, or remove includes for services you no longer use.
2. Give p=none an end date. Read the reports for a few weeks, fix the legitimate senders that fail, then move to quarantine and later to reject.
3. Make sure your reports arrive. If rua points at another domain, check that it publishes the authorisation record for yours. The DMARC checker tests this for you.

Check your own domain

Run your domain through the SPF checker and the DMARC checker; if either needs fixing, the SPF generator and DMARC generator build a corrected record. To catch these records changing later, InfraNest's DNS management includes drift detection across your providers.

Source: InfraNest scan of the top 10,000 domains of Tranco list K9PXW (Le Pochat et al., "Tranco: A Research-Oriented Top Sites Ranking Hardened Against Manipulation", NDSS 2019), 25 September 2026. Aggregated data: email-auth-2026-09.json, CC BY 4.0.