SPF 'too many DNS lookups': understanding and fixing the 10-lookup limit

What counts (and what doesn't) toward the ten

This is the heart of the matter, and the source of most misunderstandings. Counting toward the limit are the mechanisms that require a DNS resolution:

• include: — each include costs at least one resolution, and often more if it contains others in cascade.
• a and mx — resolve A/MX records.
• ptr — reverse resolution (to be avoided, see below).
• exists: and the redirect= modifier — also count.

Not counting are the mechanisms that require no query:

• ip4: and ip6: — literal addresses, zero resolution.
• all — the terminal mechanism (-all, ~all).

The consequence is clear: the more include: mechanisms give way to ip4:/ip6:, the lighter the count. And beware of cascading includes: an include:_spf.provider.com can itself contain three or four includes, all of which count toward the same ten. That's how a record exceeds the limit unnoticed — a few greedy providers is all it takes.

A second, lesser-known limit: void lookups

Beyond the ten-lookup ceiling, RFC 7208 sets another guard that trips teams less often but just as hard: the cap on void lookups. A void lookup is a DNS query that returns no usable answer — the name doesn't exist, or it exists without the expected record. The RFC recommends tolerating at most two of them per evaluation; past that, the result is a PermError as well. In practice, this punishes stale entries: a decommissioned provider whose hostname no longer resolves, a typo in an include target, a subdomain deleted without cleaning the record behind it. An SPF can therefore fail while sitting comfortably under ten resolutions — one more reason periodic cleanup matters as much as the count itself.

Diagnosing: how many resolutions are being used?

Before fixing, measuring. Nothing gets repaired that can't be seen. Our free analyzer evaluates the SPF, unfolds cascading includes, and situates the count. The goal is to visualize the tree of the record: every published include, and everything it drags in behind it. Once that tree is laid out, the culprits jump out — typically one or two big providers that, on their own, consume half the budget.

An example: anatomy of an overflow

A realistic record, that of a small business that stacked its tools over the years:

v=spf1 include:_spf.google.com include:sendgrid.net include:mailchimp.com
  include:_spf.salesforce.com include:servers.mcsv.net include:spf.protection.outlook.com -all

At first glance, six includes — six resolutions, seemingly. Reality is heavier, because each include unfolds:

• include:_spf.google.com → 1, but it itself contains several includes (_netblocks, _netblocks2, _netblocks3) → ~4 total.
• include:spf.protection.outlook.com → 1, plus its own sub-includes → ~2-3.
• include:_spf.salesforce.com, sendgrid.net, mailchimp.com, servers.mcsv.net → 1 to 2 each.

Added up, the total easily exceeds twelve or thirteen resolutions. Result: PermError, and all of that business's mail — including its real invoices via Salesforce — risks quarantine.

The fix takes two moves. First, servers.mcsv.net and mailchimp.com are duplicates (same provider): one goes. Then marketing (Mailchimp) moves to a news.company.com subdomain with its own SPF. The root domain drops back to six or seven resolutions, under the limit, and each stream keeps its budget. No legitimate mail lost, and no more PermError.

Five ways to get back under the limit

Here are the fixes, from the simplest to the most structural:

1. Removing unnecessary includes. The most obvious, and the most often forgotten. That tool marketing tested two years ago and no longer uses? Its include is still lingering. A clean house keeps only the sources that actually send.
2. Replacing includes with ip4:/ip6:. When a provider publishes stable IP ranges, they can be hard-coded instead of its include. DNS resolutions become literals that don't count. Careful though: if the provider changes its IPs, the record has to keep up.
3. Flattening the record (SPF flattening). Flattening means resolving the includes once and replacing them with the corresponding ip4:/ip6:. Powerful, but to be handled with method (providers' IPs change). We devote a whole guide to it: what is SPF flattening.
4. Splitting the sending by subdomain. Rather than stacking everything on the root domain, marketing goes out from mail.example.com and transactional from notif.example.com. Each subdomain has its own ten-resolution budget, independent. It's often the most durable solution for large senders.
5. Avoiding the ptr mechanism. Slow, unreliable, and discouraged by the RFC itself. Lingering in a record, it deserves removal.

And an advanced path: exists macros

The five fixes above reduce the count. There is a sixth path, more technical, that bypasses it: the exists mechanism combined with SPF macros authorizes an unlimited number of IPs in a single lookup, with the decision delegated to a DNS zone under the sender's control. Reserved for large senders with a dynamic fleet and carrying its own trade-offs, it's a path we explain in detail in SPF macros and the exists mechanism.

The mistake not to make while fixing

In trying to reduce the count, some teams switch their SPF to ~all (softfail) "to be safe," or even remove it. Bad idea. Weakening the terminal qualifier (-all → ~all, or worse +all) has no effect on the resolution count — it fixes nothing — but it weakens the protection. The right reflex is to reduce the number of resolutions, not to lower the guard. For the difference between -all and ~all, see the -all and ~all mechanisms.

Verifying that it's fixed

Once the record is lighter, two checks:

1. A new pass through the free SPF checker confirms the count dropped under ten and there's no more PermError. See also how to check an SPF record.
2. The aggregate reports: a source that was failing SPF on overflow should now pass (and align). That's the definitive proof the fix landed.

A related note: this overflow PermError isn't to be confused with other permanent errors (invalid syntax, duplicate record). The breakdown is in the permanent-error case.

Frequently asked questions

Does the ten-lookup limit also apply to DKIM? No. DKIM has no such constraint — it's specific to SPF, tied to how it resolves authorizations in DNS. In fact, in real-world deployments, DKIM alignment is often more robust than SPF, precisely because it escapes this kind of ceiling (see how the three protocols work together).

How many resolutions does an include "cost"? At minimum one, to resolve it. But if it itself contains include, a or mx, those add up. A single provider include can consume three or four on its own.

Is flattening the best solution? Not always. It settles the count, but it freezes IPs that may change at the provider — at the risk of breaking deliverability if the record doesn't keep up. For many organizations, cleaning out unnecessary includes and splitting by subdomain is enough, without the maintenance debt of flattening.

Why did my record "work" before? Because it was under the limit. Every new provider pushes the count up; one day, one include too many tips it into PermError. It's a threshold, not a gradual degradation.

Prevention rather than cure

The PermError never comes as a surprise when the count is watched. Three habits prevent it for good:

• Checking the cost before adding a provider. Every new include can hide several; its tree is worth reading before publication, not after.
• Preferring subdomains from the start for high-volume streams (marketing, notifications). That means a ten-resolution budget per stream, and no panic untangling later.
• Auditing the SPF periodically. Sending estates drift: one tool arrives, another leaves without its include being removed. A quarterly check is enough to keep the record clean.

The golden rule: an SPF record is alive. It's an asset to maintain, not a line published once and forgotten. The few minutes a quarter it takes are far cheaper than a day spent diagnosing why invoices suddenly land in spam — and far cheaper than the lost trust when a customer's password-reset email never arrives.

Thomas watches the SPF

The SPF count drifts with every new tool plugged into the domain. Thomas, the virtual CISO, unfolds the record, spots greedy and useless includes, suggests the safest fix for the case at hand (cleanup, subdomains, or controlled flattening), and raises the alarm before the limit is crossed — not after the mail starts dropping.

Analyze a domain for free or create an account to keep an SPF under control.