A State of TXT: 150 Million Mail Domains, and Why Only 9% Actually Stop Spoofing

Three weeks ago we published The Hidden SaaS Map, a vendor census built from the verification tokens domains leak into their apex TXT records. That post carried a loud caveat in its methodology: because the crawl queried hostnames as they appear in the dataset, it could not see the synthetic-prefix records where the email-authentication world actually lives. DMARC sits at _dmarc.example.com. MTA-STS sits at _mta-sts.example.com. BIMI sits at default._bimi.example.com. None of those names appear in a normal hostname list, so none of them could be measured. We could count SPF — it lives at the apex by design — and we counted 142 million apexes carrying it, but we explicitly declined to report DMARC, MTA-STS, or BIMI numbers because the corpus could only have caught accidental misconfigurations.

This post closes that gap. The May 2026 measurement pass added dedicated query sets for exactly those prefixes — a full sweep of _dmarc, _mta-sts, and default._bimi across the master hostname corpus — alongside MX, A, and apex TXT. For the first time we can answer the question the SaaS Map couldn't: not which vendors do domains trust, but how many domains can actually defend their own name in the From: header — and how far the published policy is from a policy that does anything.

The conventional way this question gets answered is through vendor adoption reports. Valimail, Red Sift, EasyDMARC, and Cisco/Agari each publish annual "state of DMARC" numbers, usually framed around how many domains in some commercial sample have a DMARC record. Those reports tend to celebrate adoption curves. They are also measuring populations selected for being worth selling to — Fortune 500 lists, customer bases, Alexa/Tranco top-N rankings — which systematically over-represents the organizations most likely to have done the work. The open Internet is not the Fortune 500. When Google and Yahoo turned on their bulk-sender requirements in February 2024 — mandating SPF, DKIM, and DMARC for anyone sending more than 5,000 messages a day to their users — the entire deliverability industry spent a year insisting adoption had been transformed. We wanted to measure the transformation against the whole population, not the sales funnel.

So we did it with the only honest denominator available in DNS: the MX record. A domain that publishes a real MX record is telling the world it expects to receive mail, which is the cleanest signal we have that email authentication is relevant to it. We took every apex with a working MX record as the universe, then measured what fraction of that universe publishes each layer of the modern email-authentication stack — SPF, DMARC, DMARC at an enforcing policy, MTA-STS, and BIMI — deduplicating everything to the registrable domain (eTLD+1) via the Mozilla Public Suffix List and excluding Russian-territorial TLDs per project policy.

The headline: of 150,020,997 mail-capable apex domains, 71.3% publish SPF, 34.1% publish DMARC, but only 11.7% publish DMARC at an enforcing policy (p=quarantine or p=reject), and just 9.0% run the minimum credible stack of SPF plus enforced DMARC. Two-thirds of all DMARC records — 65.5% — sit at p=none, which monitors and protects nothing. MTA-STS reaches 0.144% of mail domains and BIMI 0.084%. And in the single most concentrated finding of the study, 45.7% of all DMARC aggregate-report destinations point at one registrar's auto-generated default configuration. Email authentication is widely published and rarely enforced; the gap between the two is the real state of TXT.

The Data

DomainsProject runs full-corpus, typed DNS measurement passes against its master hostname dataset. The May 2026 pass produced separate result archives for each record type and prefix class. This post draws on five of them.

Each archive is single-line JSON per query (xz-compressed). We stream-filtered each file for the relevant signal string ("type":"MX", v=spf1, v=DMARC1, v=STSv1, v=BIMI1), parsed the matching records, computed the registrable apex of each query name, dropped Russian-territorial TLDs, and reduced to one row per (apex, signal) before counting. The full universe and the per-signal funnel:

Mail-capable apexes are the denominator for every adoption rate in this post. The 11.4 million null-MX domains are a finding in their own right — operators explicitly declaring "this name sends and receives no mail," the RFC 7505 anti-spoofing posture — and we exclude them from the adoption denominator because authentication policy on a non-mail domain is a different question (covered briefly below).

Methodology

This post makes quantitative adoption claims, so the definitions and rules are explicit.

Mail-capable. An apex is mail-capable if its MX query returned NOERROR with at least one MX answer whose exchange is not the RFC 7505 null target (0 . or .). An apex whose only MX answer is the null target is counted separately as null-MX, not mail-capable. Apexes with no MX answer at all (SOA-only NOERROR, i.e. the name exists but publishes no MX) are not counted in either bucket.

SPF and its qualifier. An apex "publishes SPF" if a TXT record at the apex begins with v=spf1. We classify each SPF record by the qualifier on its final all mechanism: -all = hardfail (receivers should reject unlisted senders), ~all = softfail (accept but mark), ?all = neutral, +all = pass (authorize the entire Internet to send as this domain — a self-defeating configuration), and no all when the record omits a terminal mechanism. Where an apex carries more than one SPF record (itself a misconfiguration), we take the strictest qualifier present, which biases the reported strictness upward.

DMARC and enforcement. An apex "publishes DMARC" if a TXT record at _dmarc.<apex> begins with v=DMARC1 and the query name reduces to the apex itself (org-level policy). We deliberately restrict to org-level _dmarc records and ignore _dmarc.www.<apex>-style subdomain records, because the organizational policy is the one that governs the registrable domain. We read the p= tag: p=reject and p=quarantine are enforcing; p=none is monitor-only; a v=DMARC1 record with no parseable p= tag is invalid (non-compliant per RFC 7489). Where an apex has multiple DMARC records, we take the strongest policy. "Enforced" throughout means p=quarantine or p=reject.

MTA-STS and BIMI. An apex "publishes MTA-STS" if _mta-sts.<apex> carries a TXT record beginning with v=STSv1 (the policy id record; we do not separately fetch the HTTPS policy file, so this is an upper bound on functioning MTA-STS). An apex "publishes BIMI" if default._bimi.<apex> carries a TXT record beginning with v=BIMI1; we mark it VMC-backed if it carries an a= authority-evidence tag or references a .pem (a Verified Mark Certificate), and logo-only otherwise.

Apex extraction. Every query name is reduced to its registrable apex (eTLD+1) using the Mozilla Public Suffix List via golang.org/x/net/publicsuffix. _dmarc.mail.foo.co.uk → strip the prefix → mail.foo.co.uk → apex foo.co.uk; the org-level rule then requires the stripped name to equal the apex, so _dmarc.mail.foo.co.uk is dropped and only _dmarc.foo.co.uk is counted. This correctly handles compound suffixes (.co.uk, .com.br, .gov.in) that a naive last-two-labels heuristic mishandles. Note that PSL private-section entries (e.g. duckdns.org, dynamic-DNS and hosting suffixes) are treated as their own apexes, which is the intended behavior for an "independently controlled name" definition.

Excluded TLDs. Per project policy we exclude .ru, .su, .moscow, .xn--p1acf, .xn--p1ai, and any apex ending in .yandex from every count.

Known limitations.

• MTA-STS is an upper bound. We confirm the DNS _mta-sts id record but do not fetch and validate the https://mta-sts.<domain>/.well-known/mta-sts.txt policy file. A domain with a stale or missing policy file but a lingering id record is counted as publishing. The real working-MTA-STS number is lower than 0.144%.
• DKIM is not measured. DKIM selectors live at <selector>._domainkey.<domain> and the selector name is not discoverable without per-message inspection or a selector wordlist. DKIM is therefore absent from this study; "the stack" here means SPF + DMARC, the two layers that are cleanly observable from DNS alone.
• Snapshot, not history. This is a single May 2026 measurement pass. Adoption-curve and "since the Google/Yahoo mandate" claims in this post are framed against external longitudinal reports, not against our own prior crawls, which used different query sets.
• Stale records bias upward. SPF, DMARC, and BIMI records persist long after the underlying mail configuration changes. Every published-rate here is an upper bound on live, correct configuration.
• Registrar boilerplate. A large share of both SPF and DMARC records are auto-published registrar/hosting defaults rather than deliberate operator choices. We treat this as a finding (see the report-aggregator section) rather than filtering it out, because from a receiver's perspective the record is real regardless of who authored it.

Reproducibility. The extractor is ~250 lines of Go: a streaming JSONL reader with a hand-rolled field scanner, a PSL apex function, and per-mode parsers for MX/SPF/DMARC/MTA-STS/BIMI, driven by xzcat | grep -F <signal> | extractor across 14 cores and reduced with sort -u and streaming awk. The May 2026 active dataset underlying the crawl is available at domainsproject.org/dataset; the typed-crawl archives are part of the subscriber feed.

The Scorecard

The adoption funnel, expressed as a share of the 150,020,997 mail-capable apexes. The SPF → DMARC → enforced → full-stack chain is strictly nested (each is a subset of the line above); MTA-STS and BIMI are independent layers measured against the same mail-capable denominator.

SPF is the only layer the open Internet has actually adopted. At 71.3% of mail-capable domains, SPF is effectively table stakes — old, cheap, automatically configured by most hosting providers, and required by every major mailbox provider. From there the funnel collapses fast. DMARC publication halves to 34.1%, and the moment you require the policy to do something, it halves again to 11.7%. The drop from "publishes DMARC" to "enforces DMARC" — from 51.1 million apexes to 17.6 million — is the single largest leak in the funnel, and it is entirely a matter of one tag: p=. The full credible stack (SPF present and DMARC enforcing) covers 13.5 million apexes, 9.0% of mail domains. Nine in ten domains that can receive mail cannot, today, stop someone from forging their name in a way a compliant receiver will reject.

MTA-STS and BIMI are not yet population-scale phenomena. At 0.144% and 0.084% respectively they are the practices of a small, deliberate cohort — and as the methodology notes, both numbers are upper bounds.

The soft middle

The funnel hides why enforcement is so rare. The answer is that the email-authentication stack ships two "cautious" defaults — SPF ~all and DMARC p=none — and most operators never move past them.

Most published authentication is advisory, not instructive. Nearly two-thirds of SPF records (63.6%) end in ~all, which tells a receiver "mail from unlisted sources is probably not us, but accept it anyway." Only 30.6% use -all, the qualifier that actually asks for rejection. The DMARC picture is starker: 65.5% of all DMARC records are p=none, a setting whose entire function is to send reports while changing nothing about message handling. p=none is the correct first step in a DMARC rollout — you publish it, you read the aggregate reports, you fix your legitimate senders, and then you ratchet to quarantine and reject. The data is consistent with an Internet that took the first step at scale and never took the second. The 33.5 million p=none records are the monitoring-forever cohort.

The tails matter too. 44,530 mail-capable domains publish v=spf1 +all — an SPF record that authorizes the entire Internet to send as them, which is strictly worse than publishing no SPF at all because it launders forgeries through a passing check. And 46,424 domains publish a v=DMARC1 record with no p= tag, which is syntactically invalid and ignored by compliant receivers — the security-theater configuration of having "done DMARC" without it doing anything.

The Enforcement Gap Is National

Break the funnel down by TLD and a geographic pattern appears that mirrors the ccTLD governance stories we've covered before. Publication rates are moderately high across most large TLDs. Enforcement rates are wildly different — and the difference tracks national mail-operations culture, not domain volume.

The Netherlands, Poland, Switzerland, and Germany convert publication into enforcement; Italy and Japan do not. .nl and .pl lead the large TLDs on both axes — .nl at 58.3% published / 26.3% enforced, .pl at 54.9% / 29.3% — consistent with the registrar-scorecard and registry-incentive cultures we documented in the Netherlands and Poland deep-dives. .ch is the cleanest converter of all: 38.9% publish and 26.4% enforce, meaning roughly two-thirds of Swiss domains that bother with DMARC go all the way to enforcement.

The opposite pattern — high publication, near-zero enforcement — is most extreme in .it (51.3% published but only 4.0% enforced) and .jp (30.8% / 4.4%). These are not domains that ignored DMARC; they adopted it and then parked it at p=none almost universally. The data is consistent with a compliance-driven rollout (publish a record to satisfy a checklist or a mailbox-provider prompt) that never progressed to the operational work of fixing senders and ratcheting the policy. .br shows the same shape more mildly (41.9% / 7.6%). The lesson is that DMARC publication rate is a near-useless headline metric — the enforcement rate is the one that corresponds to actual anti-spoofing protection, and the two diverge by more than 10x between the best and worst large TLDs.

.com, the giant, sits in the unremarkable middle on publication (31.0%) and low on enforcement (10.1%) — but as the next section shows, even that 10.1% is not what it appears.

Who Reads the World's DMARC Mail

DMARC's rua= tag specifies where a domain's aggregate reports — daily XML summaries of who is sending mail under its name — should be delivered. Those reports are the forensic backbone of DMARC: they are how an operator discovers spoofing and validates legitimate senders. They are also a concentration story. We extracted every rua=mailto: destination from the DMARC corpus (27,625,097 reporting destinations across all DMARC records) and grouped them by receiving service.

Nearly half of all DMARC reports in the world flow to a single registrar's default configuration. onsecureserver.net — GoDaddy's hosting/reporting domain — receives 45.7% of all rua destinations, an order of magnitude more than the next-largest receiver. This is not GoDaddy winning a competitive DMARC-vendor market; it is the footprint of GoDaddy auto-publishing a v=DMARC1; p=quarantine; ... rua=mailto:[email protected] record on millions of the domains it hosts and parks. We saw this exact record repeatedly in the raw data on small, parked, often never-emailing domains.

This finding reframes the enforcement numbers above. A meaningful share of the world's "enforcing" DMARC — and specifically of the p=quarantine population — is registrar boilerplate, not a deliberate operator decision. It inflates .com's enforcement rate (GoDaddy's hosted base is .com-heavy) and it means the deliberate enforcement rate among organizations that actually run their own mail is lower than the headline 11.7%. The flip side is a genuine privacy-and-visibility concentration: GoDaddy and Cloudflare together receive aggregate spoofing telemetry for roughly 49% of all reporting domains — a two-vendor concentration in DMARC forensic data that mirrors the two-vendor concentration we found in the Kubernetes DNS edge. The specialist market that sells DMARC management — Valimail, Proofpoint, dmarcian, DMARC Analyzer, Agari, Red Sift, MxToolbox — collectively splits under 10% of destinations.

The Domains That Opt Out Entirely

Not every domain in the dataset is trying and failing. Two populations are deliberately declaring that they do not send mail, which is its own valid anti-spoofing posture.

• 11,410,546 apexes publish a null MX (0 .) and nothing else — the RFC 7505 declaration that the domain neither sends nor receives mail. On a parked or web-only domain this is the correct configuration, and it is more honest than a dormant MX that invites probing.
• 22,019,997 apexes publish SPF but have no working MX, and 16,973,606 publish DMARC with no working MX. Many of these are the defensive posture in its purest form: a parked domain publishing v=spf1 -all and p=reject to say "no mail legitimately originates here, reject anything claiming to." Brand-protection registrations and domain portfolios do this deliberately.

These populations are healthy signals — they are the minority of operators who understand that the absence of mail is also a configuration. The problem the funnel describes is not these domains; it is the much larger middle that runs live mail behind advisory-only authentication.

What's at Stake

• Spoofability is the default, not the exception. With only 9.0% of mail-capable domains running SPF plus enforced DMARC, the overwhelming majority of the namespace remains forgeable in a way that compliant receivers will not reject — the precondition for business-email-compromise and brand-impersonation phishing.
• p=none is a plateau, not a ramp. 33.5 million domains are stuck in monitor-only mode. DMARC's value is realized only at quarantine/reject; a decade of p=none records is a decade of telemetry collected and never acted on.
• The Google/Yahoo mandate moved publication, not enforcement. Adoption pressure since February 2024 plausibly explains the high SPF and rising DMARC publication rates, but the 11.7% enforcement rate suggests the mandate's threshold (have a DMARC record; p=none satisfies it) is being met at the floor, not exceeded.
• DMARC forensic visibility is concentrated in two vendors. GoDaddy and Cloudflare receive spoofing telemetry for ~49% of reporting domains. That is operationally convenient and a meaningful single-point concentration of who can see attack patterns across the namespace.
• The enforcement gap is a national-policy lever. The 10x spread between .ch/.pl/.nl and .it/.jp enforcement rates shows that registry and registrar incentives — not technology — determine whether published DMARC becomes enforced DMARC.

What Would Help

1. Mailbox providers: raise the bar from "has DMARC" to "enforces DMARC." The 2024 bulk-sender requirements are satisfied by p=none. The data shows operators stop exactly where the requirement stops. A staged requirement that expects p=quarantine for high-volume senders by a published date would move the 65.5% p=none population in a way no amount of best-practice advocacy has.
2. Registries and registrars: publish enforcement rates, not adoption rates. The Dutch and Polish registries' scorecard cultures correlate with the best enforcement numbers in the dataset. A public per-registrar DMARC-enforcement scorecard (distinct from publication) would make the .it/.jp plateau visible and competitive to fix. See /stats/ for the per-TLD baselines this builds on.
3. Registrars auto-publishing DMARC: default to a real reporting handoff and a ratchet plan. GoDaddy's auto-p=quarantine is, narrowly, better than nothing — but a default that collects 45.7% of the world's reports into one inbox with no per-customer feedback loop is a missed opportunity. Defaults that surface the reports to the domain owner and prompt the move to p=reject would convert boilerplate into protection.
4. Operators: treat ~all/p=none as a 90-day state, not a destination. The single highest-leverage action for the 33.5 million monitoring-only domains is to read one month of aggregate reports, fix the legitimate senders they reveal, and move to enforcement. The tooling market (rank 4–10 above) exists precisely to make this routine.
5. Security researchers: measure enforcement, and measure DKIM next. Publication-rate headlines overstate protection by roughly 3x. The missing piece in this study is DKIM, which requires selector discovery; a selector-wordlist pass against this same corpus would let the stack be measured end-to-end. The dataset and the methodology above are the starting point.

Methodology: derived from a May 2026 typed DNS measurement pass over the DomainsProject master hostname corpus, covering MX, apex TXT (SPF), _dmarc, _mta-sts, and default._bimi query sets (172 GB compressed across the five archives used here). All counts are unique registrable apexes (eTLD+1) via the Mozilla Public Suffix List, with .ru, .su, .moscow, .xn--p1acf, .xn--p1ai, and .yandex apexes excluded per project policy. Mail-capable apexes (real MX, excluding RFC 7505 null MX) are the denominator for all adoption rates. MTA-STS counts confirm the DNS id record only and are an upper bound on functioning policy; DKIM is not measured. Explore the per-TLD baselines at /stats/ and the underlying dataset at /dataset.