The two historical TXT snapshots reported 10,920 DMARC records in June 2018 and 179,508 in April 2020, a 16.4-fold difference in observed records. That does not by itself measure global domain adoption or transitions in a matched domain cohort. This article examines those reported snapshots and their limitations.
The snapshots contain millions of SPF records and a smaller DMARC population. Many reported DMARC policies used p=none, which requests no quarantine or rejection on DMARC failure but can enable reporting; receivers can still apply their own policies. DKIM selector coverage was not measured here, so this dataset does not establish a DKIM adoption trend.
Historical evidence limits (September 2026): Snapshot identifiers, extraction code, and deduplication rules are not published with this article. The tables retain the original reported counts, which have not been reconstructed for this update. Comparisons may reflect scan coverage and composition changes; they do not establish that the same domains retained or changed policy.
How I Measured This
I analyzed two snapshots from Rapid7's Project Sonar, a research project that conducts internet-wide surveys and publishes the results as open datasets. The same kind of internet-wide scanning underpins my look at what TCP services the average IPv4 host still exposes to the public internet; here, the specific dataset is the forward DNS (FDNS) TXT record collection, which captures TXT records observed across the public DNS.
Snapshot 1: June 4, 2018, 121.8 million TXT records Snapshot 2: April 24, 2020, 262.7 million TXT records
For each snapshot, I parsed every TXT record to identify:
- SPF records: Any TXT record starting with
v=spf1 - DMARC records: Any TXT record starting with
v=DMARC1(published at_dmarc.subdomains) - DKIM limitation: TXT scans can observe keys at queried selectors, but selector coverage and DKIM adoption were not measured in the published tables.
For SPF records, I extracted the qualifier mechanism (-all, ~all, +all, ?all) and parsed include: directives to identify third-party email providers. For DMARC records, I extracted the policy (p=none, p=quarantine, p=reject), reporting addresses (rua=), and subdomain policies (sp=).
A TXT-record count is not a domain count: one domain may have several TXT records, and a scan may omit names or selectors. Percentages of TXT records therefore do not estimate domain-level adoption. Reproducing these results requires the original snapshot identifiers, query coverage, parsing rules, and deduplication code.
You can check any domain's TXT records: including SPF, DKIM, and DMARC: using the DNS Inspector. Select the TXT record type and enter a domain to see its current email authentication configuration.
The SPF Landscape
The report counted 14.3 million SPF records in 2018 and 12.7 million in 2020. Coverage, churn, and parsing could affect that difference; the unmatched snapshots cannot identify its cause or measure a rollback in deployment. They also do not establish which email authentication mechanism was most widely deployed, because DKIM coverage was not measured.
The more revealing data is the qualifier distribution, the mechanism at the end of an SPF record that tells receiving servers what to do with email that doesn't match any authorized sender.
SPF Qualifier Distribution
The listed qualifier categories do not exhaust the reported SPF totals: their counts sum to 13,967,526 in 2018 and 12,362,971 in 2020. The original report did not reconcile the residual records, so they cannot be assigned to an omitted category without the extraction code.
| Qualifier | 2018 Count | 2018 % | 2020 Count | 2020 % | Meaning |
|---|---|---|---|---|---|
-all (hard fail) | 7,557,620 | 52.9% | 6,205,568 | 48.9% | SPF fail; receiver chooses disposition |
~all (soft fail) | 4,396,177 | 30.8% | 5,042,259 | 39.7% | SPF softfail; receiver applies policy |
?all (neutral) | 1,993,898 | 14.0% | 1,095,462 | 8.6% | SPF neutral for unmatched senders |
+all (pass all) | 19,831 | 0.1% | 19,682 | 0.2% | SPF pass for any unmatched sender |
The reported share of ~all is higher in 2020 than in 2018. That distribution does not show that particular domains changed policies or establish DMARC as the cause.
DMARC needs an aligned SPF pass or an aligned DKIM pass. SPF softfail is not a pass, but aligned DKIM may allow DMARC to pass when forwarding breaks SPF. A published p=reject requests rejection on DMARC failure; the receiver retains its own disposition policy. These protocol rules do not establish why administrators chose the qualifiers in the table.
The reported ?all share fell from 14.0% to 8.6%. For a sender that reaches that mechanism, SPF returns neutral. Earlier mechanisms can still authenticate authorized senders. Without matching domains across snapshots, this is a distribution difference rather than evidence of individual policy migrations.
DMARC: A Larger Observed Record Population
The report counted 10,920 DMARC records in June 2018 and 179,508 in April 2020, a 16.4-fold difference. The scan’s TXT population also changed from 121.8 million to 262.7 million records, so that ratio is not a global domain-adoption rate.
Two unmatched observations do not establish an exponential trend, a doubling interval, or a comparison with the adoption speed of other protocols.
DMARC Policy Distribution
The three listed policies sum to 10,687 records in 2018 and 178,418 in 2020, below the stated totals of 10,920 and 179,508. The residuals (233 and 1,090) are unexplained in the retained report; they are not evidence of any particular missing or invalid tag category.
| Policy | 2018 Count | 2018 % | 2020 Count | 2020 % |
|---|---|---|---|---|
p=none (monitor only) | 7,823 | 71.6% | 124,474 | 69.3% |
p=quarantine (spam folder) | 932 | 8.5% | 18,403 | 10.2% |
p=reject (block) | 1,932 | 17.7% | 35,541 | 19.8% |
The observed p=reject count was 18.4 times larger in the second snapshot, rising from 1,932 to 35,541. Its reported share rose from 17.7% to 19.8%, while p=quarantine rose from 8.5% to 10.2%. These describe the sampled record populations, not the policy history of a matched set of domains.
About seven in ten reported DMARC records in 2020 used p=none. That requests no DMARC-based quarantine or rejection, but reporting can still help operators discover legitimate and unauthorized senders. Receivers may filter messages under their own policies, so p=none does not guarantee delivery.
Some of this is intentional and healthy, domains should start with p=none to gather data before enforcing. The problem is that the 69-71% share held nearly constant between 2018 and 2020. The snapshots show a high share of monitoring policies. A matched longitudinal cohort would be needed to establish whether particular domains later progressed to enforcement.
In the reported 2018 sample, 8,802 of 10,920 DMARC records included rua=: about 80.6%, a majority. The 2,779 records with sp= were a smaller subset. These tags indicate configured reporting or subdomain policy, not proof that reports were received or reviewed. To inspect authentication results, examine a specific message’s headers.
The Email Provider Ecosystem
SPF include: directives identify policies a sender domain may consult during evaluation. These counts are not exclusive provider market shares: one domain can include several providers, and an include does not measure active message volume.
Top SPF Include Providers
| Provider | 2018 Count | 2020 Count | Change |
|---|---|---|---|
| Microsoft (Office 365) | 671,790 | 617,416 | -8.1% |
| Google (Workspace) | 574,314 | 607,097 | +5.7% |
| SendGrid (Twilio) | 171,776 | 238,328 | +38.7% |
| Mailgun | 44,996 | 89,506 | +98.9% |
| Mailchimp | 70,978 | 79,197 | +11.6% |
| Zoho | 57,339 | 68,884 | +20.1% |
| Amazon SES | Not reported | 68,899 | Not comparable |
Microsoft’s reported include count was 671,790 in 2018 and 617,416 in 2020; Google’s was 574,314 and 607,097. The observed count gap narrowed from about 97,000 to about 10,000. These unmatched observations do not establish customer migration or predict a crossover.
The reported SendGrid count was 38.7% higher and Mailgun’s 98.9% higher in the second snapshot. Amazon SES had 68,899 reported observations, with no comparable 2018 count in the table. It was not a newly launched service in 2020. A domain can authorize separate providers for employee, transactional, and marketing mail; these counts do not prove a change in that architecture.
Multiple senders can make SPF policies complex. RFC 7208 Section 4.6.4 limits evaluated DNS-lookup-generating terms, including nested includes. Exceeding that limit produces permerror; changing the final -all to ~all cannot prevent an error reached before all. Reduce unnecessary lookup-generating mechanisms and assess the actual policy path rather than assuming a fixed lookup count per provider.
The Persistent Problems
The snapshots contain permissive or non-enforcing policies. They cannot show whether the same domains retained those settings, or whether an observed policy was intentional.
The +all Problem
Nearly 20,000 domains in both snapshots published SPF records ending with +all. A sender that reaches this qualifier receives an SPF pass. This does not require the receiver to deliver the message or make DMARC pass without alignment.
The reported +all counts are similar: 19,831 and 19,682. A sender that reaches +all receives an SPF pass, which defeats SPF source restriction for that evaluation. The counts do not identify abandoned domains or prove that the same names persisted. See the guide to misconfigured SPF records for operational checks.
The Soft-Fail Default
The reported ~all share rose from 30.8% to 39.7% of SPF records. That change alone does not show which domains also had DMARC, why their policies changed, or how recipients handled messages. RFC 7208 advises against rejecting solely for softfail; it remains an authentication signal that receivers may combine with other evidence.
Missing DMARC on SPF-Enabled Domains
The gap between SPF deployment (12.7 million records) and DMARC deployment (179,508 records) was enormous even in 2020. That is roughly 70 times as many SPF records as DMARC records. It is worth stating that carefully: the analysis counted records, not the intersection of domain sets, so it does not establish that 70 domains had SPF but no DMARC for each one that had both. Without matching domain sets, the difference between these counts cannot establish how many SPF-publishing domains lacked DMARC.
Interpreting the Difference
Compliance requirements, provider rules, and deployment tools are possible influences on DMARC deployment. The snapshots do not isolate their effects or establish why the observed record populations differ. A matched cohort and documented scan coverage would be required for a causal or longitudinal conclusion.
Current Sender Requirements Are Separate Evidence
Gmail’s sender guidelines require SPF, DKIM, and DMARC for bulk senders to personal Gmail accounts. Microsoft’s Outlook.com policy introduced authentication requirements for domains sending more than 5,000 messages per day to Outlook.com, effective May 5, 2025. These current provider policies are independent evidence, not outcomes predicted by the 2018–2020 scan. They allow a DMARC policy of p=none; meeting a bulk-sender requirement does not itself require moving to p=reject.
Use the email tester to inspect a message’s authentication results. A successful authentication check is one part of deliverability and does not guarantee inbox placement.
For current security findings across DNS infrastructure, see the security dashboard. Its current data should not be treated as a reconstruction of these historical snapshots.
Recommendations
If you are responsible for a domain's email configuration, here is what the data says you should prioritize.
Publish and monitor a DMARC policy. Inventory the domain’s legitimate senders and configure reporting to an address you control. A monitoring record can be v=DMARC1; p=none; rua=mailto:[email protected]. Reports depend on participating receivers and valid reporting authorization; merely publishing a record does not prove that reports arrive.
Move toward enforcement when the evidence supports it. Review aggregate reports, verify alignment for legitimate sending systems, and test forwarding and third-party workflows before requesting quarantine or rejection. There is no universal 90-day deadline. Check the current DMARC policy as part of that review.
Audit the evaluated SPF lookup path. RFC 7208 limits DNS-lookup-generating terms, including nested includes. A small number of top-level includes can already exceed the limit. Remove obsolete senders and test relevant paths; automatically replacing provider policies with fixed IPs creates maintenance obligations when those IPs change.
Check for +all. It gives an SPF pass to any sender that reaches it. Inventory legitimate senders and replace an unintended permissive policy with an appropriate final qualifier; also verify DMARC alignment rather than treating SPF alone as complete protection.
Add DKIM alongside SPF. Forwarding can change the connecting IP and break SPF. A DKIM signature can survive forwarding if the signed content remains valid, but message modifications can break it. Check the published DKIM key, then inspect a delivered message to verify signing and alignment. Configuring both SPF and DKIM improves coverage without guaranteeing every mail route will authenticate.
Decide your subdomain policy deliberately. Attackers often spoof subdomains such as invoice.yourdomain.com rather than the apex domain. A common misconception is that the organizational domain's policy does not reach subdomains and that sp is needed to extend it. The opposite is true: RFC 9989 Section 4.7 states the p policy MUST be applied for subdomains unless sp (or the newer np, for non-existent subdomains) overrides it. So sp is the tag you use to set a different subdomain policy, and the risk to watch for is an sp value weaker than your p, which quietly opens the subdomain space back up.