Historical data limit: The original extraction outputs have not been reproduced for this update. The qualifier and include tables use inconsistent totals, so their historical figures are preserved as reported observations, not independently verified prevalence estimates. A softfail policy or absence of all alone is not evidence of misconfiguration.
The historical extraction reported 19,682 records containing +all. If evaluation reaches that mechanism, it returns pass for any sender. Earlier matching mechanisms still take precedence. SPF checks the SMTP identity, not every use of a domain in a visible From header; see RFC 7208.
How I Found These
Project Sonar, maintained by Rapid7, performs regular internet-wide scans and publishes the results as open datasets. Their Forward DNS (FDNS) dataset captures DNS responses across hundreds of millions of domains, including TXT records: which is where SPF lives.
I worked with the 2020-04-24 snapshot, which contains 262.7 million TXT records. Filtering for records starting with v=spf1 yielded 12,686,152 SPF records. From there, I parsed each record to extract the qualifier on the all mechanism, counted include: directives, measured record lengths, identified IP range breadth, and flagged duplicates.
For trend comparison, I also pulled equivalent metrics from a 2018 snapshot. The two-year delta turned out to be one of the most interesting parts of the analysis.
This is historical data, a snapshot of SPF deployment at scale. But based on everything I've seen in ongoing DNS monitoring, the patterns I found here haven't fundamentally changed. If anything, the problems have grown alongside email infrastructure complexity.
The +all Problem: 19,682 Domains That Defeat Their Own SPF
A policy consisting of v=spf1 +all authorizes every source for the checked SPF identity. It supplies no useful source restriction. Review such a policy against the actual sending inventory before changing it.
The + qualifier returns pass when its mechanism matches. A trailing +all permits any source that reaches it; it does not override a mechanism that matched earlier, authenticate message content, or by itself establish DMARC alignment. See the authentication setup guide.
Out of 12,686,152 SPF records, 19,682 used +all, that's 0.16% of all SPF-enabled domains. A small percentage, but in absolute terms, nearly twenty thousand domains with actively dangerous configurations.
What makes this worse is persistence. Comparing the 2018 and 2020 snapshots, the count barely moved: 19,831 in 2018 versus 19,682 in 2020. These aren't transient misconfigurations being quickly caught and fixed. They're sitting in DNS, year after year, actively undermining the domain's email security.
Some of these are likely abandoned domains where nobody's maintaining DNS records anymore. But others are active, domains with MX records, with web traffic, with real organizations behind them that simply never noticed or never understood what +all does.
The ~all Gray Zone
| Qualifier | Count | Percentage | Meaning |
|---|---|---|---|
-all | 6,205,568 | 48.9% | Fail; receiver chooses disposition |
~all | 5,042,259 | 39.7% | Softfail; distinct from pass |
?all | 1,095,462 | 8.6% | Neutral, no opinion either way |
+all | 19,682 | 0.16% | Pass if evaluation reaches this mechanism |
No all | 323,181 | 2.5% | Check redirect and default result |
~all returns softfail; -all returns fail. Neither is an instruction that every receiver must handle identically. Softfail is distinct from pass. Google's SPF guidance recommends ~all, so its presence is not automatically a defect.
Choose policy using the sender inventory, receiving behavior and aligned SPF/DKIM results. DMARC policy applies when authentication does not produce an aligned pass; it does not repair an invalid SPF record.
Records Without an all Mechanism
The historical classification contains 323,181 records without an all mechanism. That does not establish 323,181 incomplete policies. A valid redirect= can supply the policy, and earlier matching mechanisms can return an authentication result.
If no mechanism matches and there is no applicable redirect, RFC 7208 section 4.7 specifies a neutral result. For example, v=spf1 include:_spf.google.com permits matching included senders but has a neutral default for others. Confirm whether that default is intentional.
The DNS Lookup Limit
SPF has a hard limit that catches many administrators off guard: a single SPF evaluation cannot exceed 10 DNS lookups. The terms that count are the ones that cause a DNS query during evaluation: the include, a, mx, ptr, and exists mechanisms, plus the redirect modifier (RFC 7208 Section 4.6.4). Note that redirect is a modifier rather than a mechanism, that exists counts too, and that all, ip4, and ip6 do not count at all. The limit also applies to terms actually evaluated, not to a count of what is written in the record: a term sitting after an earlier mechanism that already matched may never be reached. And crucially, it's recursive. If your SPF record includes _spf.google.com, and that record includes three more domains, that's four lookups from a single include in your record.
Here's how include usage breaks down. The counts below partition a set of 14,288,172 records, which is not the 12,686,152 figure from my v=spf1 filter above. I cannot now reconcile the two: this table came from a different parsing pass, and I no longer have the intermediate output to determine which snapshot or filter produced it. The row percentages are computed against the table's own total, and I would trust the shape of the distribution well ahead of the absolute counts.
| Include Count | Records | Percentage |
|---|---|---|
| 0 | 8,387,016 | 58.7% |
| 1 | 5,382,753 | 37.7% |
| 2 | 263,247 | 1.8% |
| 3 | 118,985 | 0.9% |
| 4 | 120,788 | 0.8% |
| 5+ | 15,383 | 0.1% |
| of which 10+ | 67 | under 0.001% |
The first six rows are mutually exclusive and sum to the total. The 10+ row is nested inside 5+, not additional to it.
The majority of domains keep it simple, nearly 59% have no includes at all (typically bare IP addresses or a single a mechanism), and another 38% use just one include. But 67 records had 10 or more includes in a single SPF record, which almost certainly pushes them over the lookup limit before you even account for recursive lookups within those includes.
When the lookup limit is exceeded, the SPF evaluation returns a "permerror", a permanent error. Different receiving servers handle permerror differently, but the result is unpredictable: some treat it as a fail, some as neutral, some skip SPF entirely. Your carefully constructed sender list becomes meaningless.
The insidious thing about this limit is that it can break silently. You add a third email marketing platform and everything seems fine, until one of your existing includes adds another layer of indirection on their end, pushing your total over the limit without you changing anything.
Modern workarounds exist. SPF "flattening" services resolve all includes down to raw IP addresses, eliminating DNS lookups at the cost of requiring regular updates as provider IP ranges change. Some organizations use SPF macros for more dynamic resolution. But these are band-aids on a fundamental design limitation that RFC 7208 baked into the protocol.
Broad IP Ranges: When SPF Covers Too Much
SPF lets you authorize IP addresses and CIDR ranges to send on your behalf. The idea is straightforward: if your mail server is at 203.0.113.5, you add ip4:203.0.113.5 and only that server is authorized. But I found thousands of records authorizing absurdly broad IP ranges.
From the dataset, tens of thousands of records authorize a /16 or broader range (65,536+ addresses), and a smaller subset of those authorize an entire /8 or more (16.7 million+ addresses).
I am deliberately not giving you precise counts for those two buckets. The figures I originally published were mutually contradictory, implying more records in the /8-or-broader set than in the /16-or-broader set that contains it, and I no longer have the parsing output needed to establish what the bucket boundaries actually were or which number belonged to which. Rather than present a reconstruction as a measurement, here is what I can stand behind: broad-range authorization at this scale is common enough to be a structural problem, not a handful of outliers.
A /8 block contains 16,777,216 IP addresses. Authorizing an entire /8 in your SPF record means that any of those 16.7 million addresses can send email as your domain and pass SPF. That's not authentication, it's a rubber stamp.
Some of these are likely cloud hosting providers that gave customers broad ranges to cover their infrastructure. Others might be large enterprises with massive IP allocations. But in most cases, a /16 or broader range represents a fundamental misunderstanding of what SPF is supposed to do. You're authorizing not just your servers but potentially thousands of other organizations sharing that IP space.
The whole point of SPF is to restrict who can send on your behalf. When your SPF record authorizes millions of IP addresses, you've achieved the illusion of email authentication without any of the actual security.
The Trending Problem: Strict Enforcement Is Declining
This is the data point that concerns me most. Comparing the 2018 and 2020 snapshots:
| Qualifier | 2018 | 2020 | Change |
|---|---|---|---|
-all (hard fail) | 52.9% | 48.9% | -4.0 points |
~all (soft fail) | 30.8% | 39.7% | +8.9 points |
+all (pass all) | ~0.16% | 0.16% | Flat |
Strict enforcement is losing ground. In two years, -all usage dropped from a majority position at 52.9% to a minority at 48.9%, while ~all surged from 30.8% to 39.7%. The email ecosystem is becoming less strict about SPF enforcement, not more.
The dataset does not establish why a domain chose a qualifier. Provider instructions, sender changes and local delivery requirements may all matter. The separate email-authentication study also needs corpus coverage to be distinguished from real-world adoption.
The reported policy proportions differ between the historical snapshots. Without comparable target coverage and reconstructed extraction, they do not establish that the same domains changed policy or that security deteriorated. The presence of ~all is not itself a security failure.
Why These Misconfigurations Persist
After digging through millions of these records, I've identified several recurring themes in why SPF misconfigurations are so durable.
Copy-paste syndrome. SPF records are notoriously copied from Stack Overflow answers, vendor documentation, and blog posts without understanding what each part does. A record that was correct for one organization's infrastructure gets transplanted verbatim to another's, where it's either too permissive or too restrictive.
Vendor-driven complexity. Every SaaS tool that sends email on your behalf needs to be in your SPF record. Salesforce, HubSpot, Mailchimp, SendGrid, your helpdesk, your invoicing system, each one adds an include. Organizations with five or six email-sending services are already using half their DNS lookup budget on third-party includes.
No built-in feedback. SPF fails silently. If your record is misconfigured, you don't get an error message. Your email might still be delivered (especially with softfail), so there's no obvious signal that something is wrong. Without DMARC reporting, you're flying blind.
Organizational churn. The person who set up the SPF record three years ago left the company. Nobody remembers why include:legacy-mailserver.example.net is there, so nobody removes it. New services get added, old ones never get cleaned out, and the record grows until it hits the lookup limit.
Fear of breaking email. Email is mission-critical. The downside of a false positive (blocking a legitimate email) feels worse than the downside of a false negative (allowing a spoofed email through). This asymmetry pushes administrators toward permissive configurations, softfail instead of hard fail, broad IP ranges instead of specific ones.
How to Audit Your SPF Record
If you're reading this and wondering about your own domain, here's how I'd approach an SPF audit.
Step 1: Look up your current TXT records. You can use a tool like the DNS Inspector to query the TXT records for your domain. Look for the record starting with v=spf1.
Step 2: Review the effective policy. Identify the outcomes of matching mechanisms, the fallback qualifier and any redirect. Confirm that they match the intended sender inventory. Investigate +all because it permits every remaining source; do not classify ~all or a valid redirect as an automatic error.
Step 3: Evaluate DNS-querying terms. The limit applies during evaluation to include, a, mx, ptr, exists and the redirect modifier, including nested evaluations. A count of top-level includes alone is insufficient. See RFC 7208 section 4.6.4.
Step 4: Review your IP ranges. Any ip4: or ip6: mechanism with a CIDR mask broader than /24 (for IPv4) deserves scrutiny. Anything broader than /16 is almost certainly too permissive.
Step 5: Verify every include is still needed. For each include: in your record, confirm that the corresponding service is still actively sending email on your behalf. Remove any that are no longer in use.
Step 6: Check for duplicate SPF records. The dataset revealed 837 domains with multiple v=spf1 records. RFC 7208 says a domain must have at most one SPF record, multiple records result in a permerror. If you have more than one, merge them.
Step 7: Check TXT encoding. One SPF TXT record may contain multiple character strings, which are concatenated without added spaces. Each string is limited to 255 octets; the complete SPF record may be longer. The historical 477 length candidates are not confirmed errors without their wire-format strings and parser output.
Step 8: Deploy DMARC with reporting. Even a p=none DMARC policy with rua= reporting gives you visibility into who's sending email as your domain and whether SPF is passing or failing. This data is essential for moving from softfail to hard fail with confidence. Also verify DKIM alignment so that forwarded messages still authenticate when SPF fails due to IP changes.
An SPF audit should test actual authorization paths and DNS results, not equate every softfail or long TXT value with a defect. The unreproduced corpus does not support the original claim that over six million records were misconfigured. After an intentional change, test email deliverability using real messages and inspect aligned authentication results.