Why Your SPF Fails: The 10 DNS Lookup Limit Explained

It’s 9 AM on a Tuesday, and your most important outbound emails are suddenly bouncing. The nondelivery receipts are cryptic, filled with SMTP codes and a vague message about a 'Permanent Error' during policy evaluation. Panic sets in. You check the sender's IP against your Sender Policy Framework (SPF) record, and it looks fine. The IP is authorized. So why are major providers like Google and Microsoft rejecting your mail?

The answer is almost always hidden one level deeper, in a strict but often misunderstood constraint buried in RFC 7208. Your SPF policy evaluation is exceeding the maximum of 10 DNS lookups, causing downstream mail servers to immediately fail the check.

This isn't a bug; it's a feature designed to protect the internet's infrastructure. But in an era of sprawling third-party services, it’s become the single most common reason legitimate email authentication breaks. Let's pull this thread and see how a simple TXT record can bring your entire mail flow to a halt.

The DoS Protection You Didn’t Know You Had

The 10-lookup limit is fundamentally a safeguard. Imagine an SPF record crafted with malicious intent, containing a circular reference or pointing to a non-responsive DNS server. A receiving mail transfer agent (MTA) attempting to validate that record could be tricked into an endless loop of DNS queries, consuming resources and effectively creating a denial-of-service attack against itself.

RFC 7208 put a hard stop to this. It dictates that any single SPF check must not result in more than ten DNS lookups. If the evaluation chain hits an eleventh lookup, it must terminate immediately and return a `permerror`.

What Counts as a Lookup?

It’s critical to understand which parts of your SPF record—known as 'mechanisms'—contribute to this count. The mechanisms `include`, `a`, `mx`, `ptr`, and `exists` each require a DNS query and therefore count against your limit of ten. This includes any lookups from nested `include` statements. If you include a vendor's SPF record, you inherit their lookup count.

Conversely, the mechanisms `ip4`, `ip6`, and `all` do not require a DNS query. They are direct instructions that are evaluated locally by the receiving server. You can have as many of these as you need without affecting the lookup count.

Tracing a Permerror with Your Own Two Hands

When an `Authentication-Results` header shows `spf=permerror`, you can't just look at your own domain's TXT record. You have to trace the entire evaluation path just like the receiving MTA would. The simplest tool for this is `dig`.

Let's work through a hypothetical but realistic failure. Your company, `example.com`, has an SPF record that looks crowded:

v=spf1 include:_spf.google.com include:mail.zendesk.com include:servers.mktg.com mx a ~all

Here's how the lookups stack up. The `mx` and `a` mechanisms each cost one lookup, so we start with a count of 2. Now let's follow the `include` chain. A `dig +short TXT _spf.google.com` shows it contains three more `include` statements for its own infrastructure. That brings our total to 5 (2 base + 3 from Google). Next, `dig +short TXT mail.zendesk.com`. It might contain two `include`s of its own. Now we're at 7. Finally, `dig +short TXT servers.mktg.com`. This is the marketing automation platform the demand-gen team just signed up for. A query reveals it has four `include`s of its own.

Our running total: 2 (base) + 3 (Google) + 2 (Zendesk) + 4 (Mktg) = 11 lookups. The moment the receiver's evaluation hits that eleventh lookup, it's game over. The check terminates with a `permerror`, and depending on your DMARC policy (`p=reject` or `p=quarantine`), your legitimate email gets junked or dropped entirely.

Death by a Thousand Vendor Includes

No one sets out to build a fragile SPF record. The problem creeps in over time, one `include` at a time. This is vendor sprawl, and it's the primary driver of SPF `permerror` events in modern organizations.

The Unseen Technical Debt

Every time a new SaaS platform is onboarded that needs to send email on your behalf—think Salesforce, HubSpot, SendGrid, a new HR platform—the setup guide tells you to add their `include` to your SPF record. The Marketing department adds one. Sales adds another. Support adds their own for their ticketing system. Each one seems harmless in isolation.

But nobody is managing the total count. Each of those vendor records can, and often does, contain multiple lookups of their own. Worse, vendors can change their SPF records at any time without notifying you, potentially pushing you over the limit overnight. What was a valid record with 9 lookups on Monday could suddenly become an invalid one with 11 on Tuesday, all due to a change completely outside of your control.

Forwarders and Indirect Mailflows

Even with a valid SPF record, indirect mailflows can trigger failures. When an email is forwarded, the new sending server's IP address won't be in your SPF record. This breaks SPF authentication, a notorious problem that affects everything from mailing lists to simple auto-forwarding rules. While protocols like ARC (Authenticated Received Chain, RFC 8617) are designed to fix this, adoption isn't universal. A complex SPF record that is close to the lookup limit is more brittle and more likely to fail in these common forwarding scenarios, as any intermediate MTA processing can add its own complexity.

The Remediation Playbook

Fixing a bloated SPF record requires more than just deleting a line. It requires a strategy. There are two primary paths forward: consolidation and segregation.

Strategy 1: Consolidate and Flatten

The most direct approach is to reduce the number of lookups. First, audit every `include` mechanism in your record. Is that service still in use? Often, includes for decommissioned services are left in place for years. Removing them is an easy win.

For the services that remain, you can sometimes 'flatten' the lookups. Instead of using a vendor's `include`, which might contain multiple lookups, you can replace it with the specific `ip4` or `ip6` ranges that the vendor uses. This replaces a potentially costly lookup mechanism with a zero-cost one. The tradeoff is administrative overhead; if the vendor changes their sending IPs, you are responsible for updating your record. This can be brittle and is only recommended for vendors with stable, well-documented IP addresses.

Strategy 2: Strategic Subdomains

This is the most scalable and resilient solution. Instead of authorizing all third-party senders from your primary corporate domain (`example.com`), you delegate that authority to subdomains. Each subdomain gets its own separate SPF record with its own 10-lookup limit.

For example, you could configure your marketing platform to send from `mktg.example.com`. The SPF record for that subdomain would only need to contain the `include` for that specific vendor. Your support tickets could come from `support.example.com`, with an SPF record authorizing only Zendesk. This isolates the lookup chains. Your primary domain's SPF record remains lean and clean, reserved only for corporate mail and a few critical services.

This approach not only solves the 10-lookup problem but also improves security and brand reputation. It ensures that different types of mail traffic are properly segmented, making it easier to track deliverability and diagnose issues. It also aligns perfectly with DMARC, as you can set specific policies for each subdomain.

The takeaway

An SPF `permerror` is not just a technical glitch; it's a symptom of unmanaged technical debt in your domain's sending identity. The 10-lookup limit is a forcing function, compelling you to confront the sprawl of services sending email on your behalf. Don't wait for a critical email to bounce.

Proactively audit your SPF record. Trace the lookups. Question every `include`. The subdomains-for-services model is a powerful paradigm shift, moving you from a reactive, fragile state to a proactive, resilient one. Running a full analysis with a tool that can visualize the entire DNS lookup chain, like the SPF checker within MailSleuth.AI, turns a postmortem into a routine health check.