SPF 'Too Many DNS Lookups' (PermError): What It Means and How to Fix It

The SPF "too many DNS lookups" error means your SPF record requires more than 10 DNS queries to evaluate, so receiving servers stop processing it and return a permerror — which most mailbox providers treat as an SPF failure. The fix is to reduce the number of include, a, mx, ptr, exists, and redirect terms in your record, usually by removing unused services, consolidating to ip4 ranges, or splitting mail streams across subdomains.

If you just got this error, start here: paste your domain into the free SPF checker. It evaluates your record exactly like a receiving server would, counts every lookup recursively, and shows you which include is blowing the budget.

Why Does the SPF 10 Lookup Limit Exist?

The limit isn't arbitrary gatekeeping. It's written into RFC 7208, section 4.6.4, and it exists for one reason: DNS amplification protection.

Here's the problem the RFC authors were solving. Every time a receiving server evaluates your SPF record, it may have to fire off DNS queries — and those queries can spawn more queries. Without a cap, a malicious or sloppy domain could construct an SPF record that fans out into hundreds of DNS lookups per incoming message. Multiply that by millions of messages a day, and SPF becomes a free DDoS weapon against DNS infrastructure.

So the RFC drew a hard line:

• An SPF evaluation may cause at most 10 DNS-querying mechanisms or modifiers.
• Exceed it, and the result is `permerror` — a permanent error.
• There's a second, lesser-known cap: more than 2 "void" lookups (queries that return no answer or NXDOMAIN) also triggers permerror. Dead includes count against you twice.

One nuance that trips people up: the limit applies per evaluation, per message, per receiving server. It's not a limit on your DNS zone's health — it's a limit on how much work you're allowed to make every receiver do, every single time they get mail from you.

Which SPF Mechanisms Count Toward the Limit?

Not everything in your record costs a lookup. Only these terms count:

Two traps hide in that table:

1. `include` is recursive. include:_spf.google.com costs 1 for the initial TXT query. But Google's record contains three more includes (_netblocks.google.com, _netblocks2.google.com, _netblocks3.google.com). Total cost: 4 lookups for one service.

2. `mx` costs more than it looks. The MX query itself is 1 lookup. But evaluation then has to resolve an A record for each MX hostname returned. If your domain has 4 MX records, a bare mx mechanism can cost 5 lookups by itself. The same applies to a on hosts with multiple records. This is how records that "only have six things in them" blow past 10.

Try it: the SPF checker expands every include recursively and shows the true per-mechanism cost — including the hidden mx and nested-include amplification.

How Do You Count Your SPF Lookups? (Worked Example)

You can count lookups by hand with dig. Start with your own record:

dig TXT example.com +short

Say it returns:

v=spf1 include:_spf.google.com include:sendgrid.net include:servers.mcsv.net mx ~all

Now count, term by term:

1. `include:_spf.google.com` — query it:

``bash dig TXT _spf.google.com +short ` Returns v=spf1 include:_netblocks.google.com include:_netblocks2.google.com include:_netblocks3.google.com ~all. That's **1 + 3 nested = 4 lookups**. (Query each netblock record and you'll find they're pure ip4` — no further cost. Good.)

1. `include:sendgrid.net` — returns a flat list of ip4 ranges. Cost: 1.

1. `include:servers.mcsv.net` (Mailchimp) — flat ip4 list. Cost: 1.

1. `mx` — the MX query (1) plus A lookups for each MX host. Google Workspace sets 4–5 MX records, so this costs 4–5.

Total: 4 + 1 + 1 + 5 = 11 lookups. PermError. And that's a record with only four terms in it — nothing about it looks broken.

The rule of thumb: count the included records' contents, not just the includes. Keep a running total of every include, a, mx, ptr, exists, and redirect you encounter at every depth.

The Classic Failure Story

If this sounds familiar, you're in good company. It almost always happens the same way:

1. Company starts on Google Workspace. SPF is v=spf1 include:_spf.google.com ~all. Cost: 4. Fine.
2. Marketing adds Mailchimp. Someone pastes in include:servers.mcsv.net. Cost: 5. Fine.
3. Product adds SendGrid for transactional mail. include:sendgrid.net. Cost: 6. Still fine.
4. Sales buys a CRM with its own sending domain requirement. include:crm-vendor.example. Their record includes two more records internally. Cost: 9.
5. A new IT admin tidies up and adds mx "for safety." Cost: 13–14. Every receiver now gets `permerror`.

The scary part: nobody gets alerted. SPF just quietly starts failing. Under Gmail's and Yahoo's sender requirements, failing authentication contributes to spam-folder placement and, since Gmail's hard 5xx enforcement began in November 2025, outright rejection for non-compliant bulk senders. Teams usually notice because open rates fall off a cliff, not because anything errored on their side.

This is also why SPF belongs in drift monitoring — a vendor adding an include to their record can push your record over the limit overnight, with zero changes on your end. WillItInbox's domain monitoring scans your SPF record for exactly this kind of drift and alerts you before it costs you placement.

How Do You Fix SPF Too Many DNS Lookups?

Ranked from safest to most dangerous. Do them in order — most domains never need step 4.

Fix 1: Remove services you don't actually send from

This solves the problem for most domains and carries zero risk.

Audit every include in your record against reality:

• Did marketing migrate off Mailchimp six months ago? Remove the include.
• Is that CRM trial over? Remove it.
• Is mx in there because someone copy-pasted a template from 2014? If your MX hosts aren't a documented sending source, remove it — that's 4–5 lookups back instantly.
• Kill any ptr mechanism. It's deprecated by RFC 7208 and was never a good idea.

One warning: verify before deleting. Check your ESP's dashboard or your DMARC aggregate reports to confirm a source is truly idle. Removing a live include converts permerror into fail for that stream, which is not an improvement.

Fix 2: Consolidate to `ip4` ranges

ip4 and ip6 terms are free — they cost no lookups. If a vendor publishes a stable set of sending IPs, you can replace their include: with explicit ip4: entries.

v=spf1 include:_spf.google.com ip4:167.89.0.0/17 ip4:208.117.48.0/20 ~all

That swapped SendGrid's include (1 lookup) for two free terms. The catch: you're now responsible for tracking the vendor's IP changes. If they add a range and you don't, their mail starts failing. Only do this for vendors with well-documented, rarely-changing IP lists — and put a calendar reminder on it.

Fix 3: Split mail streams across subdomains

This is the architecturally correct fix for domains with many senders. SPF is evaluated per domain (per MAIL FROM), and each subdomain gets its own fresh budget of 10 lookups.

• example.com → website, Google Workspace mail
• mail.example.com or marketing.example.com → Mailchimp/ESP, with v=spf1 include:servers.mcsv.net ~all
• transactions.example.com → SendGrid, with v=spf1 include:sendgrid.net ~all

Each record costs 1–4 lookups. You could add six more ESPs and never touch the limit again. Bonus: reputation isolation — a spammy marketing stream can't drag down your transactional domain, which matters even more now that Yahoo moved to domain-reputation-first filtering in April 2025.

The cost is operational: each stream needs its own DKIM key and DMARC alignment, and you'll want DMARC sp= or explicit subdomain DMARC records. Our email subdomain strategy guide walks through the full setup.

Fix 4: SPF flattening (with eyes open)

"SPF flattening" means resolving every include to its final ip4/ip6 ranges and publishing one flat record:

v=spf1 ip4:35.190.247.0/24 ip4:64.233.160.0/19 ip4:66.102.0.0/20 ... ~all

Zero lookups. PermError impossible. Two serious problems:

1. It goes stale. ESPs change IPs without telling you. Google updates its netblocks records. Your flat record silently becomes wrong, and mail fails — the exact failure you were trying to avoid, just slower and harder to diagnose.
2. The 255-character DNS limit. TXT strings max out at 255 characters, and a heavily flattened record can exceed what fits comfortably in one record. Multiple strings get concatenated, but past ~2 KB of record you're creating operational risk with some DNS providers. "SPF record too long" errors are real.

If you flatten, use a hosted/dynamic SPF service that re-resolves the record automatically and serves it via include — this keeps you at 1–2 lookups while someone else handles the staleness. Manual flattening plus a quarterly re-check is the budget version. Either way, treat a flattened record as a living artifact, not a set-and-forget fix. See our SPF cheat sheet for flattening syntax and safe record structure.

How Do You Verify the Fix?

Don't assume it's fixed. Verify in three steps:

1. Re-count the lookups. Run your domain through the SPF checker. You're looking for a total of 10 or fewer — ideally 8 or fewer, leaving headroom for vendors to grow their records.
2. Send a real test email. Use the deliverability tester and send from each stream you touched. Confirm SPF shows pass in the authentication results — not permerror, not temperror (that's transient DNS trouble; retest in a few minutes).
3. Watch DMARC reports for a week. DMARC aggregate reports show SPF results as receivers actually computed them, from real traffic, across every provider. WillItInbox's monitoring ingests these reports and flags unknown sources and auth failures automatically — useful here both for confirming the fix and for catching the next time a vendor's include grows.

If you're also unsure whether the rest of your sender setup meets current Gmail/Yahoo rules, run the free sender compliance checker — it covers SPF, DKIM, DMARC, one-click unsubscribe, and complaint-rate prerequisites in one pass.