The State of DMARC, 2026

• 51.8% of the top 100k domains publish no DMARC record at all.
• Among the 48.2% that do publish DMARC, 38.0% sit at p=none (observe-only), 27.8% at p=quarantine, and only 34.1% at p=reject.
• Net effect: only 16.2% of the top 100k are actually enforcing DMARC. Eighteen months after the major receivers raised the floor, the bulk of the public web has not budged.
• 11.8% of DMARC-having domains set an explicit sp= subdomain policy. The other 88% inherit p, which means millions of unprovisioned subdomains under p=none apexes are still spoofable.
• The SPF 10-lookup limit, which we expected to be a major quiet-breakage source, only bites 0.10% of domains. SaaS-stack growth has not yet produced the SPF apocalypse the email-ops folklore predicted.
• 78.5% of DMARC-having domains include rua= reporting. That is the bright spot. Even the operators stuck at p=none are mostly observing rather than flying blind.

We pulled the top 100,000 apexes as ranked on May 9, 2026 by the public Tranco list (a research-grade ranking that combines several traffic + DNS sources to resist the gaming individual lists are subject to). For each apex we issued three TXT lookups via the system resolver:

1. _dmarc.<apex> for the DMARC record
2. <apex> for the SPF record (filtering to TXT entries starting with v=spf1)
3. 18 well-known DKIM selectors (google, selector1, k1, etc.) for DKIM coverage detection

One tag-parse pass per record produced the structured shape; aggregations come from scripts/analyze-dmarc.ts. The crawl took 32 minutes at 100 concurrent DNS lookups and had a zero-error rate. No active scanning - everything was a single DNS query. The crawler script and analyzer are open in the repo.

Caveat one: the DKIM probe only checks 18 well-known selectors. Custom selectors are invisible to it. DKIM coverage numbers below are a floor, not a ceiling.

Caveat two: SPF lookup count is a static token-count of include: / redirect= / a: / mx: / exists: directives on the apex record. We do not recursively expand include: chains, so a domain showing 4 lookups here might actually evaluate to 11 when nested includes are walked. The real "over the limit" rate is higher than the 0.10% reported below; treat 0.10% as the floor for "obviously broken on the apex."

The headline number that has barely moved despite enforcement pressure from the major receivers in 2024:

• No DMARC published51.8%
• p=none (observe only)18.3%
• p=quarantine13.4%
• p=reject16.4%

Adoption among the DMARC-having half tells a more nuanced story. Of the 48,244 domains in our sample with a published DMARC record:

• p=none38.0%
• p=quarantine27.8%
• p=reject34.1%

The two-thirds of DMARC-having domains stuck below p=reject line up with what receiving-side data has shown for years: most operators publish DMARC, gather aggregate reports, and then never finish the migration. The gap between "I have DMARC" and "my DMARC blocks spoofing" remains huge.

We also caught a long tail of records with broken p= values: p=quarantaine (typo), p=rnone (typo), p=75 (someone confused pct with p), even p=policy (literal word "policy"). These are functionally equivalent to no DMARC - receivers ignore the malformed tag. About 50 domains across our sample. Tiny in proportion, but a useful reminder that publishing the record is not the same as publishing the right record.

If your apex is p=reject but you have not set an explicit sp=reject, the subdomain policy defaults to whatever p is. That works fine for the apex - but it means an attacker can spoof finance.acme.com even if you never provisioned that subdomain, because the spoof inherits the apex DMARC.

The fix: explicit sp=reject. We found this set on only 11.8% of DMARC-having domains. The other 88% of DMARC-having operators are leaving every unprovisioned subdomain spoofable.

This is the cheapest deliverability win in DMARC. Adding sp=reject to a record that already has p=reject takes one DNS edit. It costs nothing in legitimate-mail flow because you do not have legitimate mail flowing from unprovisioned subdomains. We expect this to be the next quiet posture lift in the receiver-side scoring weight, the way rua-presence quietly became one over 2023-2024.

Out of every metric we measured, rua reporting was the healthiest: 78.5% of DMARC-having domains have an active rua= endpoint. That means the operators publishing DMARC are mostly NOT flying blind - they are sending the aggregate reports somewhere that parses them.

This is a real shift from where adoption looked five years ago. Most managed DMARC services now require rua to function; even free / DIY rollouts increasingly point rua at a mailbox a human checks. The bottleneck is no longer observability; it is the willingness to act on the observations and ramp p=quarantine to p=reject.

We expected the SPF PermError: too many DNS lookups situation to be widespread. The folklore in email-ops slack channels has been that every SaaS-heavy mail stack is one vendor away from breaking. The actual data:

• 0-3 lookups85.4%
• 4-6 lookups13.1%
• 7-8 lookups (margin)1.3%
• 9 lookups (one away)0.1%
• 10 lookups (at limit)0.1%
• 11+ (broken)<0.1%

On the apex, only 0.10% of SPF-having domains are at or over the 10-lookup ceiling. Caveat: this is the static count on the apex record, not the recursively-expanded count. Nested include:s push the real evaluator past 10 even when the apex shows fewer. So 0.10% is a floor; the true number is higher, plausibly 1-3% based on the small sample we re-ran with full expansion. Still not the apocalypse.

Where the 7-8 lookup band IS interesting: those are the operators one vendor add away from breaking. SaaS stacks grow and the include count is monotonic until someone reflattens. The 1.3% in this band is the population most likely to hit the wall in the next 12 months.

The qualifier distribution is also worth noting:

• ~all (softfail)51.4%
• -all (hardfail)41.4%
• no qualifier7.1%
• +all (allow-anyone)0.1%

7.1% of SPF records have no terminating qualifier - so the implicit ?all ("neutral") is what receivers see. Functionally equivalent to no SPF for DMARC alignment purposes. Another silent broken-config population, larger than the lookup-limit one.

And yes, 22 domains in our sample publish +all. We will not name names, but several of them are receiving substantial inbound traffic. That config tells receivers "any IP may send mail claiming to be us."

Our 18-selector probe found 34.1% of domains have at least one common-name selector. The actual coverage is materially higher since custom selectors are invisible to this method - many mail services use selector names tied to a date or rotation generation that we do not probe.

Of the selectors we DO catch, the popularity ranking maps directly onto the dominant email service providers:

• google12,900
• s2 / s110,642
• mail6,503
• default6,385
• selector1 / selector28,946
• mandrill5,336
• k15,272

Two interesting observations: the volume of mandrill selectors surprised us - that selector belongs to a transactional email service we did not expect to be top-six. Indicates deeper SaaS-stack penetration than the SPF includes alone suggested. And the default / mail bucket - both of which are convention-based names without a single owner - combined to over 12,888, suggesting a lot of self-hosted or off-the-shelf MTA configs (Postfix / OpenDKIM defaults to mail / default).

Counting how often each SPF include appears across our sample paints the cleanest picture of the email-sending infrastructure market:

1. _spf.google.com - 7,787
2. spf.protection.outlook.com - 5,024
3. amazonses.com - 2,588
4. sendgrid.net - 1,277
5. mail.zendesk.com - 1,192
6. mailgun.org - 1,143
7. servers.mcsv.net (Mailchimp) - 1,069
8. _spf.mx.cloudflare.net - 954
9. spf.mandrillapp.com - 948
10. spf.efwd.registrar-servers.com - 594
11. spf.mailjet.com - 527
12. _spf.salesforce.com - 426
13. zoho.com - 379
14. _spf.yandex.net - 369
15. spf.mail.qq.com - 366
16. secureserver.net - 266
17. _spf.mlsend.com - 266
18. spf.unisender.com - 241
19. _spf.elasticemail.com - 230
20. spf.sendinblue.com - 207
21. helpscoutemail.com - 197
22. _spf.protonmail.ch - 183
23. _incspfcheck.mailspike.net - 182
24. spf.has.pphosted.com (Proofpoint) - 175
25. _spf.mail.hostinger.com - 172

Two big senders dominate: 7,787 domains include Google Workspace and 5,024 include Microsoft 365. That's about 27% of all SPF-having domains relying on those two for at least part of their mail flow. The next tier (Amazon SES, SendGrid, Zendesk, Mailgun, Mailchimp) is the standard SaaS stack - combined another 7,000+ inclusions.

For senders

• If you are at p=none, the receiver-side scoring weight has shifted enough since 2024 that you are visibly trailing the median. Finishing the migration to p=reject is the single highest-leverage deliverability move available right now.
• If your DMARC has no sp=, add sp=reject. One DNS edit, costs nothing in legitimate flow, removes the unprovisioned-subdomain spoofing surface entirely.
• If your SPF lookup count is at 7-8 on the apex, plan a flatten before your next vendor add. The 1.3% in this band is the population most likely to hit the lookup wall in the next year.
• Check that your SPF record terminates with an explicit ~all or -all. The 7.1% of records without a qualifier are functionally broken for DMARC alignment.

For domain owners watching for impersonation

• Posture is public. Anyone can see your DMARC. So can attackers. Weak DMARC is an open door.
• If your apex is at p=reject sp=none, attackers can spoof every subdomain you have not provisioned. They will pick the most plausible-sounding one (accounts., payments., support.) and send phishing under it. You will not see it on your live DNS because it does not exist there.

Free tools to check your own posture against any of the signals in this post:

DMARC analyzer

Inspect any domain's DMARC + SPF + alignment in seconds.

DMARC walk-through wizard

Personalised migration plan from p=none to p=reject.

SPF flattener

Resolve nested include: chains to a 0-lookup record.

DKIM checker + generator

Validate, look up, or generate a fresh keypair.

Wiredepth also runs all of these continuously across every domain you monitor, with alerts when DMARC weakens, SPF breaks, or a new lookalike domain appears. See pricing.

If the numbers above made you want to actually do something with your own posture:

Wiredepth CLI

Same checks, scriptable from a terminal or CI job. Drop the verdict into your pipeline.

Posture verification

Tamper-evident, third-party-timestamped proof of what your DMARC / SPF / DKIM looked like at a given moment.

Evidence pack

Auditor-ready PDF of every check, with citations. Drop into a SOC 2 / ISO 27001 control file.