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 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 DMARC policy overrides the SPF qualifier for enforcement decisions. A domain with ~all in SPF and p=reject in DMARC will still reject unauthorized email. 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 receives reports about authentication failures, 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. 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 us 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 overtook Microsoft in SPF includes by 2020. Microsoft still held the top position in 2018 with 671,790 includes to Google's 574,314. By 2020, Google had pulled ahead at 607,097 versus Microsoft's 617,416 — nearly even, but the trajectory was clear. Google Workspace was gaining ground while Office 365 SPF includes slightly declined.
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. 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. Most modern mail servers treat ~all the same as ?all in practice: the SPF result is noted but doesn't affect delivery. 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. For every domain with DMARC, roughly 70 had SPF but no DMARC. 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.
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.
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. DMARC requires either SPF or DKIM to pass with alignment, so having both ensures authentication survives the full range of legitimate email routing scenarios.
Publish a subdomain policy. Attackers increasingly spoof subdomains (e.g., invoice.yourdomain.com) rather than the apex domain, because many DMARC records only cover the organizational domain. Add sp=reject to your DMARC record to extend enforcement to all subdomains.