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

It's one of the most frustrating SPF errors, because it strikes silently: your record is syntactically correct, your servers are the right ones, and yet SPF fails. The cause is almost always the same: you've exceeded the ten DNS lookup limit. Past that, receiving servers return a PermError, and your SPF stops being evaluated — as if it didn't exist. This guide explains where the limit comes from, what actually counts toward it, how to diagnose the problem, and above all how to get back under ten without breaking your deliverability.

What the error really means

When a server receives a message, it evaluates your SPF record to check that the sending IP is authorized. That evaluation can trigger DNS queries — for example to resolve an include:. RFC 7208 sets a hard ceiling: no more than ten DNS resolutions during the whole evaluation. Hit eleven, and the result is neither pass nor fail, but PermError (permanent error).

The trap is the effect of that state. For DMARC, an SPF in PermError neither aligns nor passes. If DKIM doesn't save the day, your message fails DMARC — and depending on your policy, it goes to spam or gets refused. So you can have perfectly legitimate mail rejected because of a record that became too greedy. That's why this error deserves a quick fix, not a shrug.

Why the limit exists

It isn't arbitrary. Without a ceiling, a malicious (or just badly built) SPF record could trigger a cascade of DNS queries on every received message — an ideal amplification lever for a denial-of-service attack against receiving servers. The ten-lookup limit bounds that cost and protects the world's mail infrastructure. In plain terms: the constraint that annoys you is also what stops SPF from becoming a weapon.

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 you replace include: with ip4:/ip6:, the lighter your count. And beware of cascading includes: an include:_spf.provider.com can itself contain three or four includes, all of which count toward your ten. That's how you exceed the limit without realizing it — a few greedy providers is all it takes.

Diagnose: how many resolutions are you using?

Before fixing, measure. You can't repair what you can't see. Our free analyzer evaluates your SPF, unfolds cascading includes, and tells you where your count stands. The goal is to visualize the tree of your record: every include you publish, and everything it drags in behind it. Once that tree is in front of you, the culprits jump out — typically one or two big providers that, on their own, consume half your budget.

An example: anatomy of an overflow

Take 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 — you might think six resolutions. 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.

Add it up: you easily exceed 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): remove one. Then move marketing (Mailchimp) 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. Remove 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. Clean house: keep only the sources that actually send.
2. Replace includes with ip4:/ip6:. If a provider publishes stable IP ranges, you can hard-code them instead of its include. You turn DNS resolutions into literals that don't count. Careful though: if the provider changes its IPs, you have to keep up.
3. Flatten your 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. Split your sending by subdomain. Rather than stacking everything on your root domain, send marketing from mail.your-domain.com and transactional from notif.your-domain.com. Each subdomain has its own ten-resolution budget, independent. It's often the most durable solution for large senders.
5. Avoid the ptr mechanism. Slow, unreliable, and discouraged by the RFC itself. If it's lingering in your record, remove it.

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 your protection. The right reflex is to reduce the number of resolutions, not to lower your guard. For the difference between -all and ~all, see the -all and ~all mechanisms.

Verify it's fixed

Once your record is lighter, two checks:

1. Run it through the analyzer again to confirm the count dropped under ten and there's no more PermError. See also how to check your record.
2. Watch your 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: don't confuse this overflow PermError with other permanent errors (invalid syntax, duplicate record). The breakdown is in PermError, what it means.

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 your provider — at the risk of breaking your deliverability if you don'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 you were under the limit. Every new provider you add pushes the count up; one day, one include too many tips you into PermError. It's a threshold, not a gradual degradation.

Prevent rather than cure

The PermError never comes as a surprise when you keep an eye on the count. Three habits prevent it for good:

• Check the cost before adding a provider. Every new include can hide several; look at its tree before you publish it, not after.
• Prefer subdomains from the start for high-volume streams (marketing, notifications). You give yourself a ten-resolution budget per stream, and you'll never have to untangle everything in a panic.
• Audit your 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. Treat it as an asset to maintain, not a line you publish once and forget. The few minutes a quarter you spend here are far cheaper than a day spent diagnosing why your invoices suddenly land in spam — and far cheaper than the lost trust when a customer's password-reset email never arrives.

Let Thomas watch your SPF

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

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