Research
Ok, this is a topic I’ve looked at for years, my views have been built up based on a range of things from the theory, the reality of what I find/see and the incidents I respond to and hear about.
I’ve used Claude largely for this because it’s meant as a quick snapshot in time and a high level thematic view. SPF, DMARC, MTA-STS and DNSSEC (and DNS/Domain management in general) are complex topics and there’s lots of nuance in things.
That said, who wants to see what ‘scanning’ 1 million domains looks like? Let’s take a look at what Claude has come up with:
A million domains
The following is a report generated by Claude using Opus 4.8:
Does the Web Actually Use DNSSEC and Email Authentication? Scanning the Top 1,000,000 Domains
We scanned the entire Majestic Million domain list to answer two questions: how many domains are protected by DNSSEC, and how many have working email authentication (SPF, DMARC, MTA-STS)? The short version: DNSSEC is a rounding error, email authentication is widespread — but most of it doesn’t actually enforce anything.
TL;DR
- DNSSEC: only ~7% of all domains (~8% of those that resolve) are signed. Adoption is almost entirely driven by a handful of country registries.
- SPF: ~85% of mail-enabled domains publish it — near-universal hygiene.
- DMARC: ~57% publish it, but over half sit at
p=none(monitoring only). Only ~26% of mail domains actually enforce anti-spoofing. - MTA-STS: ~1%. Barely off the ground.
- The cheap, reversible controls (SPF, DMARC-in-report-mode) get adopted broadly; the ones that require operational commitment (enforcing DMARC) or carry breakage risk (DNSSEC) lag badly.
The Method
The dataset
The source was the Majestic Million — a freely available CSV ranking the top one million websites by the number of referring subnets. It is a list of names (including subdomains such as play.google.com), not just registrable domains, which matters for how the checks were designed.
The tooling
Everything ran in PowerShell 7 using the built-in Resolve-DnsName cmdlet, parallelised with ForEach-Object -Parallel. A million DNS lookups is an I/O-bound problem, so the scanner:
- ran up to 500 concurrent lookups (benchmarking showed this was the sweet spot — higher just saturated CPU scheduling the runspaces);
- spread queries across three public resolvers (Cloudflare
1.1.1.1, Google8.8.8.8, Quad99.9.9.9) via a per-domain hash, so no single resolver rate-limited the run; - processed domains in batches that flushed to CSV as they completed, keeping memory bounded and making the multi-hour run resumable after any interruption.
A critical early lesson: a typical ISP/system resolver often strips DNSSEC data, which silently makes every domain look unsigned. Using a DNSSEC-aware resolver explicitly was essential — an early run that returned “zero signed domains” was the giveaway.
How DNSSEC was detected
The naive approach — querying for a DNSKEY record at the domain — only works at a zone apex. It wrongly reports every subdomain (like www.cloudflare.com) as unsigned, because subdomains have no DNSKEY of their own.
Instead, the scanner queried the domain’s address record with DNSSEC requested, and looked for an RRSIG (a signature) whose owner name matches the queried name. This correctly handles:
- Zone apexes (e.g.
cloudflare.com) — signed. - Subdomains inside a signed zone (e.g.
www.cloudflare.com) — also correctly signed. - Signed apexes with no address record — detected via the signed
SOA/NSECauthenticated-denial proof. - The CDN trap — a domain that is a
CNAMEonto a signed CDN target (e.g.*.cdn.cloudflare.net) is not a false positive, because the signature there has a different owner name. Only the listed name’s own signed record counts.
How email authentication was detected
Email auth is only meaningful for domains that actually run mail, so each domain was first checked for an MX record (null MX, per RFC 7505, was treated as “no mail”). Only mail-enabled domains were then checked for:
- SPF — a
TXTrecord at the apex startingv=spf1. EachTXTrecord was evaluated individually so that site-verification strings weren’t mistaken for the SPF policy. - DMARC — a
TXTrecord at_dmarc.<domain>startingv=DMARC1, with the policy tag (p=none/quarantine/reject) captured. - MTA-STS — a
TXTrecord at_mta-sts.<domain>startingv=STSv1. Note this only proves a policy is advertised in DNS; the actual policy file (served over HTTPS) was not fetched.
DKIM was deliberately excluded. DKIM records live at <selector>._domainkey.<domain>, and DNS provides no way to enumerate selectors. You can only guess common ones, so “not found” would never reliably mean “no DKIM.”
Results, Part 1: DNSSEC
Of one million domains, 67,462 (6.75%) were signed. About 18% didn’t resolve at all (dead/parked), so among resolvable domains the rate is 8.21%.
| Status | Domains | Share |
|---|---|---|
| Signed (DNSSEC) | 67,462 | 6.75% |
| Unsigned | 754,303 | 75.43% |
| Did not resolve | 178,235 | 17.82% |
Adoption is almost entirely a TLD story
The global average is nearly meaningless. DNSSEC adoption is wildly bimodal: a few country-code registries that financially incentivise signing sit at 40–60%, while the big generic TLDs are at the floor.
| High adoption (TLD) | Signed | Big but low (TLD) | Signed |
|---|---|---|---|
| .dk (Denmark) | 61.2% | .com | 4.6% |
| .cz (Czechia) | 58.3% | .org | 5.9% |
| .nl (Netherlands) | 56.9% | .net | 4.3% |
| .no, .se (Nordics) | 41–43% | .uk | 3.7% |
| .gov (US, mandated) | 40.2% | .cn | 0.5% |
.com alone is half the entire list at 4.6% — that single TLD is what pins the global average down to ~7%. Adoption also concentrates at the top of the rankings: 17.9% of the top 1,000 domains are signed, falling to 6.5% across the long tail.
Results, Part 2: Email Authentication
Two-thirds of the list (641,945 domains, 64.2%) run mail. Among those:
| Control | Domains | % of mail domains |
|---|---|---|
| SPF | 547,720 | 85.3% |
| DMARC | 366,325 | 57.1% |
| MTA-STS | 7,138 | 1.1% |
The DMARC headline is misleading
Publishing DMARC is not the same as enforcing it. Ap=nonepolicy only sends reports — it blocks nothing. Over half (54.7%) of DMARC records arep=none. Only ~45% of DMARC domains enforce (quarantine or reject), which works out to just ~26% of all mail-enabled domains being meaningfully protected against spoofing.
| DMARC policy | % of DMARC domains | Effect |
|---|---|---|
p=none | 54.7% | Monitoring only — no protection |
p=quarantine | 23.6% | Suspicious mail to spam |
p=reject | 21.5% | Full enforcement |
SPF is broad but soft
Of the SPF records, 54.8% end in ~all (softfail) versus 38.8% with -all (hardfail). A small fraction are neutral or outright broken (3.7% ?all, plus 216 domains that publish +all — which passes everything). Operators tend to hedge with softfail because SPF alone breaks on forwarded mail.
Adoption climbs steeply with rank
| Rank band | SPF | DMARC | DMARC enforcing |
|---|---|---|---|
| Top 1,000 | 94.0% | 91.9% | 71.1% |
| 1k – 10k | 92.0% | 82.2% | 54.9% |
| 10k – 100k | 87.8% | 66.8% | 36.4% |
| 100k – 1M | 84.9% | 55.6% | 24.1% |
SPF stays high everywhere, but DMARC enforcement collapses down the tail — from 71% of the top 1,000 to 24% of the long tail. Unlike DNSSEC, SPF adoption barely varies by TLD (~70–95% across the board); DMARC is where TLDs diverge, led by .nl (78.5%), .au (75.9%) and .ca (69.8%), with .cn (23.8%) and .ru (33.1%) trailing.
The Big Picture
Put the two scans side by side and a clear pattern emerges. Email authentication is adopted roughly ten times more than DNSSEC (85% SPF / 57% DMARC versus ~8% DNSSEC). The difference is not about how useful each control is — it’s about cost and risk:
- Cheap and reversible (SPF, DMARC in report-only mode): adopted broadly, almost as table stakes.
- Requires commitment (enforcing DMARC): a big drop-off — most stop at
p=none. - Carries breakage risk or needs new infrastructure (DNSSEC, MTA-STS): adopted only where a registry or regulator pushes it, or by the most sophisticated operators at the top of the rankings.
DNSSEC in particular remains a niche choice for ordinary commercial domains. The modern web has layered defenses against DNS spoofing and tampering:
- TLS (HTTPS) prevents on-path eavesdropping and modification of the actual web session, regardless of DNS integrity.
- HSTS (Strict-Transport-Security) pins browsers to TLS and prevents downgrade attacks, making DNS poisoning less useful for phishing.
- DoH/DoT (DNS over HTTPS/TLS) encrypts the recursive query itself, protecting against ISP-level or local network DNS eavesdropping — a more tractable problem than DNSSEC for most operators.
- Certificate Transparency logs make forged TLS certificates detectable, closing the trusted-CA attack vector that DNS spoofing would otherwise enable.
This layered architecture means DNSSEC solves a narrower problem than it first appears: it protects against MITM or hijacking of the DNS lookup itself, but only when the recursive resolver and downstream systems properly validate the chain of trust. For most web traffic, TLS+HSTS+CT already prevent the attacks DNSSEC would address. Operators evidently judge the operational fragility of DNSSEC (complex validation logic, no easy recovery from misconfiguration, breakage on delegation errors) to outweigh the marginal benefit of adding one more layer. Where DNSSEC is common, it’s because a registry made it easy or free — not because site owners sought it out.
Caveats
- Snapshot in time. DNS configurations change; this reflects the day of the scan.
- MTA-STS is DNS-only here. We detected the advertised TXT record, not the HTTPS policy file, so true working MTA-STS is at most the figure shown.
- DKIM was not measured (selectors can’t be enumerated from DNS).
- TLD = last label, so
.ukaggregatesco.uk,gov.uk, etc. - DMARC sub-domain inheritance (a missing
_dmarcon a sub-domain falling back to the org policy) was not modelled, so sub-domain DMARC figures are a lower bound. - “Signed” means the answering record is signed (an RRSIG is present); a full parent-to-child chain-of-trust validation was not separately performed.
Methodology: PowerShell 7, multithreaded DNS lookups via Resolve-DnsName across Cloudflare, Google and Quad9 resolvers, over the full Majestic Million list. Roughly 3.5 million DNS queries in total.
Summary
You can see here how this gives a view of the world based on a reasonable sample set. This is not a perfect dataset, but it is a sample and it is thematically in line with my experiences in the field. If someone wishes to develop a more comprehensive analysis, please fill your boots and go wild, the intent here was to show themes, the techniques here can be improved.
