Between June 2018 and April 2020, DMARC adoption grew 16.4x. That single number, from 10,920 domains to 179,508, captures the most dramatic shift in email security that has ever happened in a two-year window. I processed two snapshots of Rapid7 Project Sonar's forward DNS TXT record data to measure exactly how email authentication protocols evolved during this critical period, and the story is more nuanced than "adoption went up."
SPF was already mature by 2018 with over 14 million records. DKIM was growing steadily. But DMARC, the protocol that actually ties SPF and DKIM together into an enforceable policy, went from a niche deployment to a mainstream standard in under 24 months. And yet, even at 179,508 DMARC records, the majority of those policies were set to do absolutely nothing when authentication fails. The numbers reveal an industry that was racing to adopt the appearance of email security without committing to its enforcement.
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 records: Any TXT record containing DKIM key material (published at
*._domainkey.subdomains)
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=).
This methodology has a built-in limitation: Project Sonar captures records as observed during scanning, which means some domains may be over- or under-represented depending on scan timing. The TXT record counts include all TXT records, not just email-related ones, site verification tokens, DNSBL entries, and other miscellaneous TXT records make up the majority. The absolute percentages (SPF as a share of all TXT records) are therefore conservative estimates relative to the total number of domains scanned.
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
SPF was already a mature protocol by 2018. With 14.3 million SPF records in the first snapshot, it was by far the most widely deployed email authentication mechanism. By 2020, the count settled at 12.7 million, a nominal decline in the count, but likely reflecting deduplication or domain churn rather than actual rollback of SPF deployment.
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
| Qualifier | 2018 Count | 2018 % | 2020 Count | 2020 % | Meaning |
|---|---|---|---|---|---|
-all (hard fail) | 7,557,620 | 52.9% | 6,205,568 | 48.9% | Reject unauthorized senders |
~all (soft fail) | 4,396,177 | 30.8% | 5,042,259 | 39.7% | Flag but accept unauthorized senders |
?all (neutral) | 1,993,898 | 14.0% | 1,095,462 | 8.6% | SPF result is meaningless |
+all (pass all) | 19,831 | 0.1% | 19,682 | 0.2% | Allow anyone to send as this domain |
The shift from -all toward ~all between 2018 and 2020 is counterintuitive. You would expect adoption to move toward stricter enforcement over time. But there is a straightforward explanation: DMARC.
When a domain has a DMARC policy, the enforcement decision is driven by DMARC rather than by the SPF qualifier alone. It is worth being precise about the mechanism, because "DMARC overrides the SPF qualifier" is a common shorthand that misdescribes it. DMARC passes when at least one authentication method passes with alignment. An aligned SPF softfail is still a softfail and does not produce the SPF pass DMARC needs, though an aligned DKIM pass will. So a domain with ~all and p=reject rejects unauthorized email because neither aligned SPF nor aligned DKIM passed, not because DMARC rewrote the SPF result. Many email administrators migrated from -all to ~all precisely because they were deploying DMARC and wanted SPF to soft-fail while DMARC handled enforcement. This avoids bouncing legitimate email that fails SPF due to forwarding while still rejecting spoofed messages through DMARC alignment.
The decline in ?all (neutral) from 14% to 8.6% is encouraging. Neutral means "I published an SPF record but I don't want it to affect delivery decisions": which effectively defeats the purpose of having SPF at all. Domains were migrating from neutral to either soft-fail or hard-fail, which represents genuine progress.
DMARC: From Obscurity to Mainstream
The DMARC numbers are the most striking finding in this dataset. In June 2018, only 10,920 domains had published DMARC records. By April 2020, that number was 179,508, a 16.4x increase in under two years.
To put that growth rate in context: this means DMARC adoption roughly doubled every six months during this period. No other DNS-based security protocol has ever seen this rate of adoption. DNSSEC, which has been standardized since 2005, still sits at single-digit percentage adoption rates decades later. DMARC went from nearly nonexistent to the default expectation for any domain sending email, in a fraction of the time.
DMARC Policy Distribution
| 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 growth in p=reject is notable, 18.4x from 1,932 to 35,541, outpacing overall DMARC growth. Domains weren't just adopting DMARC; an increasing proportion were deploying it in enforcement mode. The share of p=reject grew from 17.7% to 19.8%, while p=quarantine also gained share from 8.5% to 10.2%.
But the dominant story remains p=none. Seven out of ten DMARC records in 2020 were set to monitor-only mode. This is the email security equivalent of installing a security camera that records footage but alerts no one. The domain can receive reports about authentication failures, provided it published a valid rua address and receivers choose to send them, but unauthenticated email is delivered as if no DMARC record existed.
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. Domains were adding DMARC in monitor mode and then never progressing to enforcement. The on-ramp was working; the graduation to enforcement was not.
In 2018, 8,802 DMARC records included a rua= tag (aggregate reporting address), and 2,779 included a subdomain policy (sp=). These are indicators of more sophisticated deployments, domain operators who are actively monitoring their authentication results and thinking about subdomain spoofing. To inspect authentication results for a specific message, paste the raw headers and see exactly which checks passed or failed. But they represented a minority even among the already-small DMARC population.
The Email Provider Ecosystem
SPF include: directives reveal which email-sending platforms domains authorize, giving a market share map of the email infrastructure ecosystem.
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 | , | 68,899 | New entrant |
The headline: Google nearly closed a 97,000-include gap with Microsoft in two years. Microsoft held a clear lead in 2018, 671,790 includes to Google's 574,314. By 2020 the two were within about 10,000 of each other, with Microsoft still narrowly ahead at 617,416 to Google's 607,097. Microsoft had not been overtaken, but Office 365 includes declined 8.1% while Google Workspace grew 5.7%, and on that trajectory the crossover was close.
The more important trend is the explosive growth of transactional email platforms. SendGrid grew 38.7%. Mailgun nearly doubled. Amazon SES appeared as a significant new entrant with nearly 69,000 includes. This reflects the broader architectural shift from "one server sends all email" to "we use five different services for different email types." A typical modern domain might include Microsoft for employee email, SendGrid for transactional email, Mailchimp for marketing, and a fourth platform for automated notifications.
This fragmentation is directly relevant to email authentication because it makes SPF records longer, more complex, and harder to maintain. SPF has a 10-DNS-lookup limit, every include: directive counts as a lookup, and the included domains can themselves contain nested includes. A domain authorizing Microsoft, Google, SendGrid, and Mailchimp might already be at 8-9 lookups before adding any internal mail servers. This mechanical limit pushes domains toward SPF flattening tools, toward ~all instead of -all (to avoid losing email when the SPF evaluation hits the lookup limit), and ultimately toward relying on DMARC for enforcement decisions.
The Persistent Problems
Despite overall progress in email authentication adoption, the data reveals stubborn categories of misconfiguration that barely changed between 2018 and 2020.
The +all Problem
Nearly 20,000 domains in both snapshots published SPF records ending with +all. This qualifier explicitly tells receiving mail servers: "accept email from any IP address as authorized by this domain." It is the SPF equivalent of handing out signed blank checks. An attacker can send email from any server claiming to be from that domain, and the SPF check will pass.
The count was 19,831 in 2018 and 19,682 in 2020. Essentially unchanged. These domains aren't gradually migrating to better configurations, they're stuck. I break down +all and the other recurring failures in detail in my deep dive on misconfigured SPF records. Some are likely misconfigured by administrators who misunderstood SPF syntax. Others may be legacy configurations that no one maintains. But nearly 20,000 domains actively telling the internet "anyone can send as us" represents a persistent attack surface for phishing and email spoofing.
The Soft-Fail Default
The growth of ~all from 30.8% to 39.7% of SPF records is a mixed signal. As I noted above, some of this migration is strategic, domains pairing soft-fail SPF with DMARC enforcement. But for the millions of domains that have ~all without any DMARC record, soft-fail means essentially nothing. In practice many receivers treat ~all much like ?all: the SPF result is recorded but rarely drives delivery on its own. RFC 7208 Section 8.5 is explicit that receivers SHOULD NOT reject solely on a softfail, so how much weight it carries is local policy and varies by provider. Without DMARC to consume that SPF result and make an enforcement decision, ~all is security theater.
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. These domains had taken the first step of declaring authorized senders but hadn't taken the second step of declaring what should happen when authentication fails. Their SPF records were advisory at best.
What Drove the DMARC Explosion
DMARC's 16.4x growth didn't happen in a vacuum. Several forces converged between 2018 and 2020 to push adoption from niche to mainstream.
PCI DSS and compliance frameworks began referencing DMARC in guidance documents. While not a hard requirement for most organizations, the compliance association triggered deployment across financial services, healthcare, and government sectors. The U.S. Department of Homeland Security's BOD 18-01 (issued October 2017) mandated DMARC for all federal agencies, creating a deadline-driven adoption wave that was still rolling out through 2018-2019.
Google and Yahoo's sender requirements were being signaled well before their formal 2024 deadlines. Bulk senders were already seeing deliverability advantages from DMARC alignment as early as 2019. Organizations that depended on email marketing: which is most organizations, had a direct financial incentive to deploy DMARC.
Email security vendors created an entire product category around DMARC deployment. Companies like Agari, Valimail, dmarcian, and others offered monitoring, visualization, and managed enforcement tools that lowered the barrier to entry. The 71% of DMARC records in p=none mode in 2018 likely reflects these vendors' recommended "start with monitoring" playbooks.
Phishing costs escalated dramatically during this period. FBI IC3 data showed business email compromise losses exceeding $1.7 billion annually by 2019. Executive teams that previously viewed email authentication as an IT concern started seeing it as a financial risk management issue.
The combination of compliance mandates, deliverability incentives, available tooling, and rising threat costs created a perfect adoption environment. What makes DMARC's trajectory notable is that these forces acted simultaneously rather than sequentially, unlike DNSSEC, which has lacked a comparable convergence of incentives.
Where This Is Heading
The trajectory from this 2018-2020 data pointed toward a world where DMARC becomes functionally mandatory for sending email. That is largely what has happened.
Google and Yahoo formally required DMARC for bulk senders starting February 2024. Microsoft followed with similar requirements for Outlook.com and Hotmail in 2025. These requirements turned DMARC from a best practice into a deliverability prerequisite, domains without DMARC began seeing their email silently filtered or bounced. You can test deliverability against these provider requirements to see how your domain scores today.
Based on the growth trajectory visible in this data, I would expect DMARC deployment to have reached millions of domains by 2025-2026, a continuation of the exponential curve visible between 2018 and 2020. More importantly, the policy distribution should have shifted toward enforcement. When receiving servers start rejecting email from domains without DMARC, the incentive to move from p=none to p=reject becomes concrete and immediate.
The SPF +all problem likely persists. The ~20,000 domains with dangerously permissive SPF records represent a class of abandoned or poorly maintained domains that external pressure doesn't reach. They are not sending email to Google or Yahoo in volumes that trigger bulk sender requirements. They are simply sitting in DNS, advertising their vulnerability.
For current security findings across DNS infrastructure, see the security dashboard, which tracks various categories of DNS misconfiguration and risk.
Recommendations
If you are responsible for a domain's email configuration, here is what the data says you should prioritize.
Deploy DMARC immediately, even as p=none. The data shows that most domains have SPF but no DMARC. Starting with p=none and a reporting address gives you visibility into who is sending email as your domain. A minimal DMARC record looks like: v=DMARC1; p=none; rua=mailto:[email protected]
Graduate from p=none within 90 days. The 69% of DMARC records stuck at p=none represents the biggest gap in the email authentication ecosystem. After collecting 30-90 days of aggregate reports and confirming all legitimate senders are authenticating, move to p=quarantine and then p=reject. Check your DMARC configuration to see your current policy and identify whether it is ready for enforcement.
Audit your SPF includes. If your SPF record has more than 6-7 include: directives, you are approaching the 10-lookup limit. Each provider you add increases the risk of exceeding the limit and causing all SPF checks to return a permanent error. Consider SPF flattening or consolidating email services.
Check for +all. If your SPF record ends with +all, fix it immediately. This is the single most dangerous email misconfiguration possible. It explicitly authorizes every server on the internet to send email as your domain. Replace with -all or at minimum ~all.
Add DKIM alongside SPF. SPF breaks on forwarding: when an email is forwarded, the sending IP changes and SPF fails. DKIM signatures survive forwarding because they are attached to the message, not the sending server. Verify your DKIM records to confirm the public key is published and the signature algorithm is strong enough. DMARC requires either SPF or DKIM to pass with alignment, so having both ensures authentication survives the full range of legitimate email routing scenarios.
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.8 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.