Misconfigured SPF Records: Too Many Includes, Missing -all, and Other Common Mistakes

Somewhere out there, 19,682 domains have published an SPF record that explicitly tells the world: "anyone can send email on my behalf." They took the time to create a DNS TXT record, typed out v=spf1, added their mail server details — and then ended with +all, which negates every single thing before it. It's the email authentication equivalent of installing a deadbolt on your front door and leaving the key taped to the outside. I found these records by processing 12.7 million SPF entries from Rapid7's Project Sonar dataset, and the results paint a picture of an ecosystem where SPF misconfigurations aren't edge cases — they're endemic.

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

Let me be blunt: publishing v=spf1 +all is worse than having no SPF record at all. With no SPF record, a receiving mail server at least knows there's no policy to evaluate — it might apply other heuristics or be cautious. But +all is an explicit, authenticated statement that says "every IP address on the internet is authorized to send mail for this domain."

The + qualifier means "pass." The all mechanism matches everything. Together, +all tells receiving servers to treat every single sender as legitimate. Any phishing email, any spam campaign, any spoofed message claiming to be from that domain gets a green light from SPF.

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

The most common SPF qualifier isn't the strict -all that security best practices recommend. It's ~all — the softfail — and it's growing.

Here's the qualifier distribution from the 12.7 million records:

Five million domains are in SPF limbo. The ~all qualifier tells receiving servers: "If someone fails SPF, mark it as suspicious, but don't reject it." In practice, most modern mail servers treat softfail identically to a pass — the message lands in the inbox. Gmail, for instance, has historically used softfail as just one of many signals, rarely rejecting on softfail alone.

The original intent of ~all was as a transitional mechanism. You'd deploy SPF with softfail first, monitor for legitimate senders you might have missed, and then switch to -all once you were confident in your sender list. The problem is that millions of domains deployed ~all and never completed the transition. It became the default recommendation in countless setup guides, and there it stayed.

For domains that also have DMARC with p=reject, the softfail doesn't matter as much — DMARC policy takes precedence. But for the millions of domains with ~all and no DMARC, or DMARC with p=none, the softfail is effectively no protection at all.

The Missing -all: 323,000 Incomplete Records

Then there are the 323,181 SPF records that don't have an all mechanism at all. These are records like:

v=spf1 include:_spf.google.com

No all directive means there's no default policy for IPs that don't match any mechanism. According to RFC 7208, the result is "neutral" — equivalent to ?all. The receiving server gets no guidance on what to do with senders that aren't explicitly listed.

This is almost certainly unintentional in every case. Someone set up their SPF record, added their includes, and forgot (or didn't know about) the trailing all mechanism. The record looks complete at a glance — it has v=spf1 and an include — but it's missing the most important part: the enforcement directive.

These 323,000 domains went through the effort of deploying SPF and got zero security benefit from it.

The DNS Lookup Limit

SPF has a hard limit that catches many administrators off guard: a single SPF evaluation cannot exceed 10 DNS lookups. This includes every include:, a:, mx:, ptr:, and redirect= mechanism — 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 across the 12.7 million records:

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:

• 11,109 records authorize a /16 or broader range (65,536+ IP addresses)
• 36,409 records authorize a /8 or broader range (16.7 million+ IP addresses)

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:

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.

Why? I suspect several factors are converging. First, the rise of SaaS email tools — marketing platforms, CRM systems, transactional email services — makes it harder to enumerate every legitimate sender. Administrators switch to softfail as a safety net because they're afraid of blocking legitimate email from a service they forgot to include. Second, many vendor setup guides explicitly recommend ~all, either out of caution or because they don't want support tickets from customers whose email got rejected. Third, DMARC adoption gives some administrators a false sense that the SPF qualifier doesn't matter (it does — DMARC alignment and SPF evaluation are distinct checks).

The +all count staying flat is a silver lining of sorts — at least the worst misconfiguration isn't growing. But the migration from hard fail to soft fail represents a real erosion of SPF's value as a security mechanism.

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 our DNS Inspector to query the TXT records for your domain. Look for the record starting with v=spf1.

Step 2: Check your all qualifier. Is it -all, ~all, ?all, or +all? If it's anything other than -all, you should have a documented reason. If it's +all, fix it immediately — that's a critical misconfiguration.

Step 3: Count your DNS lookups. Each include:, a:, mx:, ptr:, and redirect= in your record costs at least one DNS lookup. Then check what those includes resolve to — nested includes count against your limit too. If you're near 10, you need to optimize.

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 record length. SPF records that exceed 255 characters need to be split across multiple strings within a single TXT record. I found 477 records that appeared to exceed this limit, risking truncation by DNS resolvers that don't properly handle multi-string TXT records.

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.

SPF was designed over two decades ago as a relatively simple mechanism: list the servers authorized to send your email, and tell the world to reject everything else. But "simple" and "easy to get right" are not the same thing. With 12.7 million records in the dataset, over 6 million had some form of suboptimal configuration — whether it was the actively dangerous +all, the noncommittal ~all, overbroad IP ranges, or missing enforcement entirely. The good news is that every one of these issues is fixable with a single DNS record change. The bad news is that fixing it requires knowing there's a problem in the first place.