Seventy Percent Spoofable: Email Authentication and Transport Security Across the Top One Million Domains

Abstract#

We assessed 1,000,050 domains from the Cloudflare Radar Top 1 Million list against the complete email security standards stack: SPF (RFC 7208), DKIM (RFC 6376), DMARC (RFC 7489), MTA-STS (RFC 8461), TLS-RPT (RFC 8460), DANE (RFC 7672), DNSSEC, and Null MX (RFC 7505). Despite its name, the Radar "Top 1M" export does not contain exactly one million entries: the snapshot we used held 1,000,054 domains, of which four (malformed lines and bare top-level labels) were rejected by the assessor's fail-closed input validation, leaving 1,000,050 assessed. The scan ran at the beginning of July 2026 in a single two-hour window using a purpose-built assessor that performs full policy retrieval, including HTTPS fetch and validation of MTA-STS policy files rather than DNS-only checks.

Three findings stand out. First, the authentication layer is wide but shallow: 89.1% of mail-enabled domains publish SPF, 63.5% publish DMARC, yet only 29.0% enforce it (p=quarantine or p=reject). 70.9% of mail-enabled domains remain spoofable in the practical sense: they publish either no DMARC record or an explicit p=none. Second, the transport security layer has effectively not been deployed: MTA-STS in enforce mode covers 0.64% of mail-enabled domains, fully valid DANE covers 1.11%, and only 1.67% have either. Third, cryptographic hygiene lags a decade behind: of the domains where we discovered live DKIM RSA keys, 55.3% have at least one 1024-bit or weaker key still in service, and we found exactly 19 Ed25519 keys across the entire corpus.

Only 2,398 domains (0.34% of mail-enabled) deploy the full defensive stack: strict SPF, DMARC p=reject, discoverable DKIM, and enforced downgrade-resistant transport. Provider analysis shows enforcement is driven almost entirely by whoever operates the MX: domains behind dedicated security gateways reach 51% to 72% DMARC enforcement, while domains on retail hosting bundles sit between 1% and 4%. Email security at internet scale is no longer a protocol design problem. It is a defaults problem.

Key Findings at a Glance#

• 1,000,050 domains assessed at the beginning of July 2026 in a single two-hour window; 70.2% are mail-enabled.
• 70.9% of mail-enabled domains are spoofable (no DMARC record or p=none); only 13.4% reach p=reject.
• SPF is present on 89.1% of mail-enabled domains, but 57% of records end in ~all; 431 mail-enabled domains publish +all, authorizing the entire internet.
• DKIM is discoverable on 58.8% of mail-enabled domains, yet 55.3% of key-publishing domains still expose a live 1024-bit-or-weaker RSA key; we found 19 Ed25519 keys in the whole corpus.
• The transport layer is effectively undeployed: MTA-STS enforce 0.64%, fully valid DANE 1.11%, either 1.67% of mail-enabled domains.
• 79.8% of all domains score below 40/100; 1,012 domains (0.10%) reach the 90+ band and 428 achieve a perfect score.
• The full defensive stack is deployed by 2,398 domains (0.34%); DMARC enforcement varies by a factor of 60 depending on the MX operator.
• Mapped to compliance frameworks, NIS2 basic cyber hygiene (Art. 21(2)(g)) is fully met by 4.3% of mail-enabled domains; the cryptography and transport controls (NIS2 Art. 21(2)(h), ISO 27001 A 8.24, CIS 3.10) are fully met by less than 0.1%.
• 295,141 domains publish no MX at all, but only 2,512 declare non-mail intent via RFC 7505 Null MX.

1. Introduction#

Email spoofing remains one of the cheapest attacks on the internet. The standards to stop it have existed for years: SPF binds sending IPs to a domain, DKIM binds message content to a domain key, and DMARC ties both to the visible From: header and tells receivers what to do on failure. A second stack protects the transport itself: MTA-STS and DANE defend SMTP against STARTTLS stripping and MX interception, TLS-RPT provides failure telemetry, and DNSSEC anchors the whole construction in the DNS. RFC 7505 (Null MX) even covers the domains that never intend to send or receive mail.

Individually, each mechanism is well understood. What is measured far less often is the joint state of the stack: not "how many domains have a DMARC record" but "how many domains an attacker can actually not spoof, and whose mail transit an attacker can actually not downgrade." This study measures exactly that, across the full global Cloudflare Radar Top 1 Million popularity list, with per-domain evidence retained for every check.

Our contributions:

1. A complete-stack assessment of 1,000,050 popular domains in a single consistent two-hour measurement window.
2. Effective-protection metrics (spoofability, transport downgrade resistance, full-stack deployment) rather than record-presence counts.
3. DKIM key strength distribution obtained from over one million retrieved public keys, including a census of revoked, test-mode, and sub-2048-bit keys.
4. A provider-level breakdown showing MX operator choice is the strongest single predictor of DMARC enforcement.
5. A taxonomy of malformed DMARC policies found in the wild, including localized policy keywords in seven languages and RSA public keys pasted into p= tags.
6. A per-domain compliance mapping of the measured controls onto NIS2, ISO/IEC 27001:2022, CIS Controls v8, and BSI IT-Grundschutz requirements, aggregated across the corpus.

2. Dataset and Methodology#

2.1 Corpus#

We used a weekly snapshot of the Cloudflare Radar Top 1 Million domains dataset. Radar ranks domains by aggregated resolver popularity, so the corpus includes mail-only and infrastructure domains, not just websites. The "Top 1M" export is not exactly one million entries: our snapshot contained 1,000,054 domains. Four of them (malformed lines and bare top-level labels such as single-label TLD entries) were rejected by the assessor's fail-closed input validation, leaving 1,000,050 domains assessed. 721 assessments (0.07%) recorded at least one per-domain error (mostly timeouts); these are retained in the dataset with partial results. The full corpus was assessed in a single two-hour window at the beginning of July 2026; a single narrow window avoids the temporal smearing that affects multi-day crawls.

2.2 Measurement tool#

All measurements were performed with SecLens.ONE, an open assessor written in Go with a deliberately minimal supply chain (standard library plus golang.org/x/net/idna). Relevant properties of the measurement:

• DNS. All lookups use DNS-over-HTTPS (JSON API, Cloudflare resolver) with hardcoded provider endpoints. DoH exposes the resolver AD bit and all needed RR types (DS, TLSA) without a third-party DNS library.
• SPF. Full recursive evaluation: include: and redirect= chains are followed and stored, and both raw and effective lookup counts are computed against the RFC 7208 limit of 10.
• DMARC. _dmarc.<domain> TXT retrieval with full tag parsing (p, sp, pct, rua, ruf, adkim, aspf, fo, ri) and syntax validation.
• DKIM. Selector discovery against a curated list of common and provider-specific selectors (including MX-derived and year-stamped provider selectors), capped at 200 probes per domain. Retrieved keys are parsed; we classify key type, revocation (p= empty), test mode (t=y), and RSA modulus size class from the decoded SubjectPublicKeyInfo.
• MTA-STS. DNS advertisement check plus full HTTPS policy fetch with a strict no-redirect client per RFC 8461, policy syntax validation, id= consistency, and MX pattern coverage matching against the domain's actual MX set.
• TLS-RPT. _smtp._tls TXT retrieval and rua= URI validation.
• DANE. TLSA lookups at _25._tcp.<mx> for every MX host, RDATA parsing (including RFC 3597 unknown-RR form), MX coverage computation, and cross-validation against the DNSSEC result.
• DNSSEC. DS record presence at the parent, DNSKEY presence, and resolver AD-bit validation, with awareness of TLDs that do not support DNSSEC delegation.
• Null MX. RFC 7505 profile detection (single MX, preference 0, target "."), including detection of the mixed-MX violation.

Every domain was treated as untrusted input: SSRF guards filter MX hosts resolving to private ranges before any direct HTTPS or TLSA probing, and selector probing is capped to prevent amplification.

2.3 Profiles and scoring#

Domains are classified into two profiles:

• mail (997,538 domains): standard profile, all checks apply.
• null_mx (2,512 domains): domains publishing a valid RFC 7505 Null MX. These are scored on what matters for a no-mail domain: the Null MX record itself, restrictive SPF, DMARC, and DNSSEC.

Each domain receives a 0-100 score from a fixed rubric (Appendix A). The score is a hygiene summary, not a security guarantee; all headline findings below are stated directly in terms of protocol state, not score.

2.4 Definitions used in this paper#

• Mail-enabled: at least one non-null MX record (702,397 domains, 70.2% of the corpus).
• Spoofable: mail-enabled and publishing either no DMARC record or p=none. This is deliberately conservative; p=quarantine; pct=1 style configurations are counted as enforcing.
• Transport-protected: MTA-STS policy fetched and in enforce mode, or DANE with all MX hosts covered, valid TLSA syntax, and DNSSEC validation.
• Full stack: SPF with -all, DMARC p=reject, discoverable DKIM, and transport-protected.

3. Results#

3.1 Population overview#

Nearly 30% of the top million domains publish no MX, yet only 2,512 domains in the corpus opted into the standardized way of saying "this domain sends no mail." We return to this in Section 3.6.

3.2 SPF: near-universal presence, softfail by default#

654,275 domains (65.4% of the corpus, 89.1% of mail-enabled domains) publish SPF. Presence is a solved problem. Policy strength is not:

The majority position is ~all, the qualifier that asks receivers to accept-but-mark. In isolation, softfail SPF stops nothing; its practical value is realized only through DMARC alignment, which most of these domains do not enforce (Section 3.3).

Two failure classes deserve attention:

• Void policy. 488 domains publish +all, and 431 of them are mail-enabled. These records affirmatively authorize every host on the internet to send as the domain. This is worse than publishing nothing, because it converts a receiver-side heuristic ("no SPF, be suspicious") into an explicit pass.
• Permerror by lookup count. 16,316 records (2.5% of publishers) exceed the RFC 7208 limit of 10 DNS-querying mechanisms after include/redirect expansion. These records evaluate to permanent error at the receiver, silently disabling SPF for the domain. Include-chain sprawl from stacked SaaS senders is the dominant cause in the retained evidence.

14,161 records (2.2%) use redirect=. Recursive include data (captured per domain in the dataset) shows the usual concentration: a small number of provider includes (spf.protection.outlook.com, _spf.google.com, secureserver.net, and similar) terminate a large share of all chains.

3.3 DMARC: the enforcement gap#

471,571 domains (47.2% of the corpus, 63.5% of mail-enabled) publish a DMARC record. The policy breakdown among publishers:

More than half of all DMARC deployments are monitoring-only. Aggregated to the population that matters:

Seven in ten mail-enabled domains in the top million can be spoofed with the receiver's default policy machinery offering no instruction to quarantine or reject. p=none was designed as a transition state; the data shows it functioning as a terminal state.

Secondary weaknesses within the enforcing population:

• 14,012 records (3.0% of publishers) set pct<100, sampling enforcement.
• 16,260 records enforce at the organizational domain but explicitly relax subdomains with sp=none, leaving anything.example.com spoofable while example.com is protected.
• 955 records fail syntax validation outright and earn no protection at all.
• 63.1% of publishers request aggregate reports (rua=), meaning roughly a third of deployments operate blind, without the feedback loop that DMARC rollout depends on.

The 632 non-standard p= values are a study in how policy actually gets deployed: hand-typed and unvalidated. We observed localized policy keywords in at least seven languages (nenhum, keine, rejet, cuarentena, nessuno, ninguna, yok, quarantaine), phonetic misspellings (quarentine, qurantine, quanrantine, rejectv, re1ject), template text copied verbatim from documentation (<policy>, policy name, (none|reject|quarantine)), free-text aspirations (ignore, spam, dropped, monitor, strict, accept), and in two cases a complete base64 RSA public key pasted into the p= tag, presumably confused with DKIM's p=. Every one of these records evaluates as if no policy were published. Appendix B lists the taxonomy.

3.4 DKIM: discoverable keys, legacy strength#

Measurement note. DKIM is the one control in this study that cannot be assessed completely from the outside, and we flag the resulting distortion explicitly before presenting numbers. Selectors are arbitrary labels known only to the sender and revealed only in the headers of actual signed mail; DNS provides no way to enumerate them (s1._domainkey.example.com is only queryable if you already know s1). An external assessor is therefore limited to probing candidate selectors, and a domain that signs exclusively with a bespoke or high-entropy selector is indistinguishable from a domain with no DKIM at all. This biases the results in two directions at once: deployment counts are a strict lower bound, and the key census skews toward large providers whose well-known selectors dominate the probe list. We considered excluding DKIM for this reason and decided against it: a missing or misconfigured DKIM deployment (no key, revoked key, test-mode key, weak key) directly determines whether DMARC can align and enforce, which makes it too consequential for the overall risk picture to leave out. We accept the measurement uncertainty, state it here and in Section 6, and interpret all DKIM figures conservatively as floors, not point estimates.

Using capped probing of common and provider-derived selectors (Section 2.2), we discovered DKIM keys on 412,946 mail-enabled domains (58.8%), and 422,872 domains corpus-wide. Within those bounds, the data is an exact census of the keys we retrieved: over one million public keys with full parsing.

Key strength among live (non-revoked) RSA keys, across all domains with discoverable DKIM:

Per domain, the weakest live key is the security floor, because a receiver will validate a signature from any published selector:

RFC 8301 (2018) requires verifiers to support 2048-bit keys and instructs signers to move off 1024-bit. Eight years later, a majority of domains with discoverable DKIM still expose a 1024-bit signing key, and 684 domains expose keys at or below 512 bits, a size that has been practically factorable for years. An attacker who factors such a key can produce DKIM-valid, DMARC-aligned forgeries, converting the domain's own authentication stack into an attack tool.

Ed25519 (RFC 8463, 2018) is statistically absent: 19 keys across one million domains. Hygiene signals: 4,408 domains publish only revoked keys (empty p=, correct decommissioning), and 3,624 domains still carry t=y test-mode flags on at least one key.

3.5 Transport security: the undeployed layer#

Authentication protects the From: header. Nothing in SPF/DKIM/DMARC prevents an on-path attacker from stripping STARTTLS or spoofing MX resolution. That is the job of MTA-STS and DANE, and both remain in the low single digits:

The internal loss funnels are as telling as the totals. Of the domains advertising MTA-STS, 17.5% serve no fetchable policy: the DNS record points at an HTTPS endpoint that fails, which is a pure operational defect. Of fetched policies, 42.3% are in testing mode and 451 have policies that do not cover the domain's actual MX hosts, which under enforce would break their own mail. We also observed invented modes (enforced, enforce;) that fail validation. On the DANE side, only 26% of domains with any TLSA record reach the fully valid state, mostly because the remainder lack DNSSEC, without which DANE provides no security.

DNSSEC itself remains the bottleneck: 63,592 domains (6.4%) have a DS record at the parent. 5,774 domains sit under TLDs that do not support DNSSEC delegation at all and could not deploy DANE even if they wanted to.

3.6 Null MX: the cheapest control nobody uses#

295,141 domains publish no MX. Every one of them could publish MX 0 . plus v=spf1 -all plus a reject DMARC at near-zero cost, closing off their use in spoofing campaigns. 2,512 domains (0.84% of the combined no-mail population) publish a valid Null MX; all 2,512 records are syntactically correct, and 25 additional domains commit the RFC 7505 §3 mixed-MX violation (a null MX alongside real MX hosts). Only 279 Null MX domains complete the full posture (record + strict SPF + DMARC + DNSSEC where supported).

3.7 Composite posture#

The overall 0-100 hygiene score (rubric in Appendix A) summarizes the state of the corpus:

The score-band distribution is heavily left-skewed:

Fewer than one domain in a thousand reaches the excellent band, and exactly 428 out of one million achieve a perfect score. The 1,012 domains at 90+ are worth studying as reference deployments; they demonstrate that the full stack is achievable across TLDs, providers, and organization sizes.

The strict full-stack criterion (SPF -all, DMARC p=reject, discoverable DKIM, enforced MTA-STS or fully valid DANE) is met by 2,398 domains: 0.34% of mail-enabled domains.

3.8 The provider effect#

Grouping mail-enabled domains by MX operator (registered-domain approximation of MX hostnames; ccTLD grouping artifacts removed) and measuring DMARC enforcement within each group:

The spread is a factor of sixty between the top and bottom of the table, and it tracks the customer relationship, not the technology. Security gateway customers bought enforcement as a product outcome and get it. Enterprise suite customers get it roughly a third to half of the time. Customers of registrar and hosting bundles, the population least equipped to hand-edit DNS policy records, almost never get it. Every provider in the bottom half of this table controls both the MX and, frequently, the DNS zone of its customers; enforcement-by-default (or one-click enforcement with hosted reporting) at four or five of these operators would move the global spoofability number more than a decade of advocacy aimed at individual domain owners has.

A related concentration: Cloudflare is the authoritative DNS operator for 37.0% of the corpus, and Radar's own resolver popularity ranking underlies the corpus itself. A handful of infrastructure operators are in a position to make correct email policy the path of least resistance.

3.9 TLD concentration and registry effects#

The corpus is .com-heavy (48.3% of all domains), and the top 15 TLDs account for 74.1% of the population. Within the mail-enabled subset of each TLD:

DMARC enforcement is globally flat: most large TLDs cluster between 20% and 37%, confirming that the enforcement gap is not a regional phenomenon. Two outliers prove that policy levers work. .nl reaches 51.5% DNSSEC among mail-enabled domains (8 to 20 times the rate of comparable TLDs) and the highest DMARC enforcement in the table (44.5%), a direct legacy of the SIDN registry's per-domain DNSSEC fee incentive and the Dutch public-sector comply-or-explain standards list (which mandates DMARC, SPF, DKIM, and DANE). At the other end, .cn combines the lowest mail-enabled share (37.5%) with the lowest enforcement (14.0%), and .ru has effectively no DNSSEC (0.8%). Registry and national policy, like provider defaults, moves these numbers; individual advocacy does not.

3.10 Policy compliance mapping#

Email authentication and transport controls are not just hygiene; they are named requirements in the frameworks most organizations are audited against. The SecLens.ONE assessor ships a per-domain compliance mapping (identical logic in the public report UI and in this analysis) that translates check results into framework control states: met (check fully adopted at maximum score), partial (some points earned), gap (nothing in place). Aggregated over all 702,397 mail-enabled domains:

The table quantifies a gap that audits usually paper over. The authentication-oriented controls (NIS2 hygiene, CIS 9.5) show the characteristic "wide but shallow" signature: under 9% outright gap, but only 4.3% fully met, with the overwhelming majority stuck in partial (a record exists, enforcement does not). The cryptography and transport controls are simply not met at internet scale: NIS2 Art. 21(2)(h), ISO A 8.24, and CIS 3.10 are fully satisfied by fewer than 1 in 1,000 mail-enabled domains. For the tens of thousands of NIS2-covered entities inside this corpus, Art. 21(2)(h) compliance for the email channel effectively does not exist yet.

Corpus-wide numbers (including non-mail domains) are lower still and are included in the machine-readable statistics (Section 9). This mapping is an indicative technical view derived exclusively from DNS-visible controls; framework conformity always depends on the full ISMS scope, policies, and evidence beyond what any external scan can see.

4. Discussion#

The gap is between publishing and enforcing. Every presence metric looks healthy: 89% SPF, 64% DMARC, 59% discoverable DKIM among mail-enabled domains. Every enforcement metric collapses: 32% strict SPF, 29% enforced DMARC, 13% reject. The stack is deployed in a state that generates dashboards and reports but does not instruct receivers to stop anything. p=none deployments without rua= (roughly a third of publishers) do not even generate the reports.

Transport security failed to launch. At 1.67% combined enforced coverage nine and eight years after their respective RFCs, MTA-STS and DANE have adoption profiles of failed standards, not maturing ones. The causes differ (MTA-STS requires an HTTPS endpoint that 17.5% of advertisers cannot keep serving; DANE requires DNSSEC that 94% of domains lack) but the outcome is the same: for the overwhelming majority of domain pairs, SMTP TLS remains opportunistic and strippable. The exceptions cluster in ecosystems with mandates or provider defaults (DNSSEC-heavy ccTLD registries for DANE, a few large mailbox providers for MTA-STS).

Old keys are the quiet liability. DKIM deployment numbers hide the key-strength distribution. A 1024-bit floor on 55% of DKIM-enabled domains means that for those domains, the cost of producing a fully authenticated forgery is the cost of factoring a 1024-bit modulus, which is within reach of well-resourced attackers and trending cheaper. Unlike a missing record, a weak key is invisible to the domain owner's inbox deliverability, so nothing forces rotation.

Misconfiguration is a first-class failure mode. Across the corpus we found 16,316 SPF records that permerror themselves out of existence, 955 syntactically dead DMARC records, 632 hand-typed policy values in the wrong language or wrong syntax, 1,720 MTA-STS advertisers with no fetchable policy, and 451 MTA-STS policies that do not match their own MX set. Every one of these represents an operator who tried to deploy the control and silently failed. The standards stack offers almost no closed-loop feedback for these states; TLS-RPT, the one mechanism designed for it, sits at 1.6% adoption.

5. Implications for Security Teams#

Reading this data defensively, as the operator of a SOC, a red team, or a third-party risk program:

• Assume spoofing works until proven otherwise. With 70.9% of mail-enabled domains lacking enforcement, the default assumption for any given counterparty domain is that display-name and exact-domain impersonation will be delivered. Verify the counterparty's DMARC policy before trusting the channel for payment changes or credential flows.
• Treat p=none as telemetry, not as a control. Half of all DMARC deployments are in monitoring mode. In vendor assessments and M&A due diligence, p=none should score the same as no DMARC, with credit only for a documented rollout timeline.
• Put DKIM key strength on the audit checklist. A counterparty with p=reject but a live 1024-bit DKIM key (55.3% of key-publishing domains) has an authentication stack that a resourced attacker can subvert cryptographically. External scans see this; most questionnaires never ask.
• Do not rely on SMTP transport confidentiality. At 1.67% enforced transport protection, mail to an arbitrary domain must be assumed downgradeable by an on-path adversary. Sensitive content needs application-layer protection regardless of STARTTLS.
• Inventory and close your own no-mail domains. Parked, brand-protection, and infrastructure domains without Null MX plus v=spf1 -all plus DMARC reject are free ammunition for BEC campaigns against your counterparties. The fix is three DNS records per domain.
• Use the 90+ band as reference architecture. 1,012 domains demonstrate the complete stack in production. Their configurations (retained in the dataset) are directly reusable templates.
• Anchor budget requests in compliance language. Section 3.10 translates the measurement into NIS2, ISO 27001, CIS, and BSI control states. "We are in the 88% gap for NIS2 Art. 21(2)(h)" moves funding conversations in a way that "we should deploy MTA-STS" does not.

6. Limitations#

• DKIM undercount and inclusion rationale. External DKIM assessment is structurally incomplete: selectors cannot be enumerated via DNS, so selector-based discovery yields a lower bound, and domains exclusively using high-entropy custom selectors are counted as having no discoverable DKIM. Key-strength percentages apply to retrieved keys, which skew toward large providers with well-known selectors; the true 1024-bit share among all keys may differ. We include DKIM despite this known distortion (see the measurement note in Section 3.4) because the risk carried by an absent or misconfigured deployment is central to DMARC alignment and therefore to the spoofability results; readers should treat all DKIM figures as conservative floors.
• Single vantage point and resolver. All DNS observations were made through one DoH resolver in one window. Split-horizon DNS, geo-dependent answers, and transient failures (0.07% error rate) are folded into the results.
• DNS-observable state only. We do not send mail, so we measure published policy, not receiver behavior. A p=reject at a domain whose receivers ignore DMARC, or SMTP servers that enforce TLS without advertising it, are outside our view.
• Corpus bias. Radar's popularity ranking over-represents domains that receive DNS resolution traffic. Results should not be extrapolated to the long tail of registered domains, where hygiene is plausibly worse.
• Provider grouping. MX operator attribution uses a registered-domain approximation of MX hostnames, which merges some distinct services and splits some multi-brand operators.
• Null MX compliance ceiling. The full Null MX posture includes DNSSEC, which some TLDs cannot support; the 279 fully compliant figure is depressed accordingly (the rubric already excludes DNSSEC where the TLD lacks support, but resolver-validated deployment remains rare).

7. Recommendations#

For domain owners, in order of return on effort:

1. Close the DMARC loop. Move from p=none to p=quarantine, then p=reject, with rua= reporting throughout. Half of all current deployments are stalled at step zero.
2. Publish Null MX on no-mail domains. One MX record and a seven-byte SPF record remove an entire domain from the spoofing supply. This applies to ~295,000 domains in this corpus alone.
3. Rotate DKIM keys to 2048-bit minimum. Audit all published selectors, not just the active one; the weakest published key is the effective key strength.
4. Fix self-defeating records. SPF include chains over 10 lookups and syntactically invalid DMARC are worse than absent, because they read as deployed while providing nothing.
5. Deploy transport protection where feasible. MTA-STS in testing with TLS-RPT costs little and produces the telemetry needed to reach enforce; DANE where DNSSEC already exists.

For providers, one recommendation: make enforcement the default. The provider table in Section 3.8 is the entire story. Hosting and registrar bundles that provision SPF and MX automatically should provision p=quarantine with hosted aggregate reporting the same way. The customers most exposed are the ones who will never read RFC 7489.

8. Conclusion#

The email authentication stack has won the deployment argument and lost the enforcement one. Measured across the top million domains, 71% of mail-enabled domains remain spoofable, 98% of mail transit remains downgradeable, and the majority of discoverable DKIM keys include a modulus size deprecated eight years ago. The bright spot is structural: enforcement rates vary by a factor of sixty depending on who operates the MX, which means the problem is concentrated in a small number of decision-makers. The path to fixing email security at scale runs through perhaps twenty provider default settings, not through a million DNS consoles.

9. Reproducibility and Data Availability#

The measurement is reproducible from public inputs with the parameters stated in Section 2: a current Cloudflare Radar Top 1 Million domains snapshot, the SecLens.ONE assessor, DNS-over-HTTPS resolution, 25-second per-domain timeout, and bounded concurrency. A full pass completes in about two hours on commodity hardware and emits one JSON evidence record per domain (approximately 4.8 GB JSONL for this edition, 1,000,050 records, assessed in a single two-hour window at the beginning of July 2026).

All aggregate figures in this paper, including the compliance mapping in Section 3.10, are deterministic single-pass computations over that evidence and can be re-derived with any streaming JSON tool. The per-domain evidence includes raw DNS records, SPF include chains, retrieved DKIM keys, and assessed MTA-STS policies, so every claim can be audited down to the individual domain. The compliance mapping applies the same state logic as the public SecLens.ONE report UI, keeping paper and product consistent by construction.

The full evidence dataset and the machine-readable aggregate statistics are retained by the authors and are available on reasonable request for research verification. We plan to repeat the measurement on future Radar snapshots and publish delta reports against this baseline.

10. Ethical Considerations#

This study is a passive measurement of security policies that domain owners publish for exactly this kind of automated consumption. The assessor performs no active probing of mail servers: it never opens SMTP connections, never delivers or solicits test messages, and never scans ports or grabs banners. Its only interactions are standard DNS queries issued through a public recursive resolver and, where a domain advertises MTA-STS, a single HTTPS retrieval of the plain-text policy file from the standardized well-known endpoint defined in RFC 8461, a document published expressly for automated fetching by sending MTAs.

Per-domain load is negligible and bounded: a fixed budget of DNS lookups and at most one small HTTPS request, executed once during the measurement window. The resulting dataset contains no personal data; it consists solely of domain names from a public ranking and the public DNS records and policies those domains expose to the entire internet. We therefore consider this measurement to fall well within accepted community norms for internet-scale passive assessment, consistent with the principles of the Menlo Report.

References#

1. RFC 7208 - Sender Policy Framework (SPF), 2014.
2. RFC 6376 - DomainKeys Identified Mail (DKIM) Signatures, 2011.
3. RFC 7489 - Domain-based Message Authentication, Reporting, and Conformance (DMARC), 2015.
4. RFC 7505 - A "Null MX" Resource Record for Domains That Accept No Mail, 2015.
5. RFC 7672 - SMTP Security via Opportunistic DANE TLS, 2015.
6. RFC 8301 - Cryptographic Algorithm and Key Usage Update to DKIM, 2018.
7. RFC 8460 - SMTP TLS Reporting (TLS-RPT), 2018.
8. RFC 8461 - SMTP MTA Strict Transport Security (MTA-STS), 2018.
9. RFC 8463 - A New Cryptographic Signature Method for DKIM (Ed25519-SHA256), 2018.
10. RFC 4033/4034/4035 - DNS Security Introduction and Requirements; Resource Records; Protocol Modifications, 2005.
11. Cloudflare Radar - Top 1 Million Domains dataset.
12. EU Directive 2022/2555 (NIS2), Art. 21(2)(g), (h).
13. ISO/IEC 27001:2022, Annex A controls 5.14, 8.16, 8.24.
14. CIS Critical Security Controls v8, Safeguards 3.10 and 9.5.
15. BSI IT-Grundschutz Compendium, module APP.5.3.
16. SecLens.ONE - email and domain security assessor used for this measurement.
17. The Menlo Report: Ethical Principles Guiding Information and Communication Technology Research, U.S. Department of Homeland Security, 2012.

Appendix A: Scoring rubric#

Mail profile (max 100):

Null MX profile (max 100): Null MX record 25, strict SPF 25, DMARC 35, DNSSEC 15 (weights redistributed when the TLD does not support DNSSEC).

Appendix B: Taxonomy of malformed DMARC p= values (632 records)#

All 632 evaluate to no enforcement at the receiver. The tag-separator class is the most regrettable: these operators chose the right policy and lost it to a missing semicolon.

Numbers in this document are derived exclusively from the underlying assessment dataset (beginning of July 2026); no external statistics are cited without marking.