SPF Too Many DNS Lookups: How to Fix the PermError

If your SPF record is failing with a PermError, the most common cause is SPF too many DNS lookups. RFC 7208 caps the number of DNS-querying mechanisms a receiver will resolve while evaluating your record, and once you cross that ceiling, evaluation stops and returns an error instead of a pass. The result is that legitimate mail can be treated as unauthenticated even though every sender in your record is genuine. This guide explains the limit, why exceeding it hurts deliverability, how to diagnose it, and how to fix it — with flattening as a deliberate last resort.

Key takeaways

• The SPF 10 lookup limit from RFC 7208 counts DNS-querying mechanisms — include, a, mx, ptr, exists, and redirect — and the count is recursive, so lookups nested inside your includes count too.
• Crossing the ceiling returns an SPF PermError, which removes SPF as a passing result and can drag DMARC down with it.
• Fix the count in order: remove unused includes, consolidate, delegate to a subdomain, and only then flatten.
• SPF flattening works because ip4 and ip6 cost zero lookups, but a flattened record goes stale when a vendor changes IPs — so it must be maintained.

Understanding the SPF 10 lookup limit from RFC 7208

The SPF 10 lookup limit comes from RFC 7208, which states that evaluating an SPF record must not require more than ten DNS lookups. The mechanisms that count toward this limit are the ones that trigger a DNS query: include, a, mx, ptr, and exists, plus the redirect modifier.

Crucially, the count is recursive. When your record has include:_spf.example.com, every lookup inside that included record counts against your total too. A single include from a large email platform can consume three or four lookups by itself, so a record with a handful of vendors can quietly blow past ten and hit the SPF too many DNS lookups error. Note that ip4 and ip6 mechanisms cost nothing — they are literal addresses requiring no query.

Why exceeding limits causes an SPF PermError

When a receiver evaluating your record needs an eleventh lookup, it does not simply ignore the extra mechanism — it returns a permanent error, or SPF PermError. A PermError means the record could not be processed as published, and it is treated as an authentication failure rather than a temporary glitch.

The practical consequences of SPF too many DNS lookups depend on your DMARC and alignment setup, but they are never good: SPF stops contributing a pass, DMARC may fail if DKIM is not also aligned, and some receivers weigh a malformed SPF result against your reputation. If you are working toward stricter policy, our guide on how to enforce DMARC explains why a clean SPF pass matters before you tighten. Because the error is “permanent,” retrying will not help — the record itself must be fixed, which is why a record that “used to work” can start failing the moment a vendor expands its own SPF include.

How to diagnose SPF too many DNS lookups

Start by counting lookups, not characters. List every include, a, mx, ptr, exists, and redirect in your record, then expand each include to count the lookups nested inside it. An SPF generator or a checker that resolves the full tree will show the running total and pinpoint which include pushes you over. ToolTrusted evaluates your published SPF record as part of the free email tools and the Email Health Check, reporting on your public DNS posture — it reads what is published, so it will surface a record that is at or over the limit. Once you can see which mechanisms cost the most, the fix becomes obvious.

Work through the diagnosis in this order:

1. Count only the DNS-costing mechanisms in your root record — the include, a, mx, ptr, exists mechanisms and the redirect modifier. Ignore ip4 and ip6; they cost nothing.
2. Expand every include one level at a time and add the nested lookups to your running total, since the limit is evaluated recursively across the whole tree.
3. Watch for void lookups — mechanisms that resolve to nothing (NXDOMAIN or no records). RFC 7208 caps these at two, and a stray typo or a retired vendor can trip that limit independently of the ten-lookup ceiling.
4. Identify the single heaviest include — one large platform can consume three or four lookups on its own and is usually where the real budget goes.
5. Re-check the published record with the Email Health Check so you are grading what receivers actually resolve, not a draft you have not published yet.

How to fix SPF record limits without breaking mail

Work through these fixes in order — the goal is to fix your SPF record by reducing genuine lookups before resorting to anything that trades away flexibility. The table below summarizes the tradeoffs so you can pick the lightest-touch fix that gets you back under the limit.

• Remove unused includes. The single most effective step. Every SPF record accumulates vendors that are no longer used — an old CRM, a retired ticketing tool, a trial platform. Each unused include may cost several lookups. Remove any sender that no longer sends on your behalf.
• Drop expensive, low-value mechanisms. The ptr mechanism is deprecated and should be removed. An a or mx mechanism that exists only to authorize a server you could reference directly can often be replaced with an ip4 address, which costs zero lookups.
• Consolidate where you can. If several includes belong to one provider, check whether the provider offers a single consolidated include. Fewer, tighter includes mean fewer nested lookups.
• Flatten as a last resort. If you have trimmed everything and still exceed ten, SPF flattening replaces lookup-costing includes with the literal IP addresses they currently resolve to, collapsing many lookups into zero.

One option that sits between consolidating and flattening is subdomain delegation. Send a given stream from a dedicated subdomain — for example a marketing platform from mail.example.com — so that vendor’s includes count against the subdomain’s own ten-lookup budget instead of your root domain’s. Each subdomain publishes its own SPF record and is evaluated independently, which spreads heavy senders across separate budgets without touching literal IPs. Delegation adds records to maintain, but it avoids the staleness problem that flattening introduces.

Fixing the lookup count is a separate decision from your enforcement qualifier. The choice between ~all (softfail) and -all (hardfail) governs how receivers treat mail that is not authorized — it does nothing to reduce lookups, and loosening -all to ~all will not clear a PermError, because the record still cannot be evaluated. Fix the count first, then set the qualifier deliberately. One rare extra source of lookups worth knowing about is the macro feature, which some vendors use to build hostnames dynamically; if your record uses macros, expand them when you count.

SPF flattening: The last resort for complex setups

Flattening works because ip4 and ip6 mechanisms do not count toward the limit. Our SPF Flattener resolves your includes and outputs the verbatim ip4 and ip6 addresses they currently publish — it does not synthesize or summarize ranges into broader CIDRs, so the record reflects exactly what your vendors declare at that moment.

That precision is also the catch. Flattening captures a snapshot in time: when a vendor changes its sending IPs — which large platforms do without notice — your flattened record becomes stale, and mail from the new IPs will fail SPF until you regenerate and republish. Treat a flattened record as something you must maintain, not set and forget. Re-checking your published SPF on a schedule — for example on the email health platform — catches the drift before it silently becomes another SPF too many DNS lookups failure, which is why flattening should be the last lever you pull rather than the first.

Frequently asked questions

What causes the SPF “too many DNS lookups” error?

RFC 7208 limits SPF evaluation to ten DNS-querying mechanisms — include, a, mx, ptr, exists, and redirect. The count is recursive, so lookups nested inside your includes count too. When the total would exceed ten, receivers stop and return a PermError.

Does a PermError mean my email won’t be delivered?

Not necessarily, but it removes SPF as a passing authentication result and can cause DMARC to fail if DKIM is not aligned. That raises the odds of messages being filtered or rejected. Because the error is permanent, it will persist until the record itself is fixed.

Do ip4 and ip6 mechanisms count toward the 10-lookup limit?

No. The ip4 and ip6 mechanisms are literal addresses that require no DNS query, so they cost zero lookups. This is exactly why flattening includes into their published IP addresses brings a record back under the limit.

Is SPF flattening safe to use?

It is effective but has a staleness tradeoff. A flattened record captures a vendor’s IPs at one moment; if they change their sending IPs later, mail from the new addresses fails SPF until you regenerate and republish. Use flattening as a last resort after removing and consolidating includes, and re-check the record periodically.

What is the difference between ~all and -all when fixing SPF?

The ~all (softfail) and -all (hardfail) qualifiers only tell receivers how to treat mail from sources not listed in your record — they have no effect on the ten-lookup limit. Switching from -all to ~all will not resolve a PermError, because the record still cannot be evaluated. Reduce the lookup count first, then choose the qualifier that matches how strictly you want unauthorized mail handled.