SPF permerror: too many DNS lookups, and how to fix it

“Permerror” is SPF’s way of saying your record is broken by construction. It is not a judgement about being too permissive or too strict. The most common cause, by far: your record triggers more than 10 DNS lookups to evaluate, and RFC 7208 caps SPF evaluation at 10. Past that, receivers are required to stop evaluating and treat the whole record as an error, which means none of your legitimate senders are authorized, not just the ones past the limit.

Why the limit exists (and why it bites without warning)

Every include:, a, mx, ptr, and exists mechanism costs one lookup, and if that lookup points at another SPF record with its own includes, those count too. A record that looked fine when you had two senders quietly crosses 10 as you add a CRM, a support tool, a marketing platform, and a transactional-email service, each contributing an include: that itself expands to 3-4 more lookups. Nobody edited the record incorrectly; it just grew.

How to fix it

1. Count your current lookups. Run the free checker below. It walks every mechanism recursively and shows you the exact count, not just a pass/fail.
2. Remove includes for senders you no longer use. This is almost always the fastest win: an old marketing tool or a trial you never sent through in production is often still sitting in the record.
3. Consolidate where a vendor offers a single include. Some providers publish multiple legacy includes for the same service, so check their current docs for the one they recommend today.
4. Flatten a genuinely necessary include as a last resort, by replacing it with its resolved ip4:/ip6: ranges directly in your record. This removes the lookup cost, but you now own re-checking it whenever that vendor rotates IPs (their SPF record changing is exactly the signal you’d otherwise inherit for free).

# Before: 4 includes, several with their own nested includes, ~13 total lookups
v=spf1 include:_spf.google.com include:sendgrid.net include:spf.mandrillapp.com include:servers.mcsv.net ~all

# After: trimmed to the senders actually in use, 6 total lookups
v=spf1 include:_spf.google.com include:sendgrid.net ~all

A permerror record is worse than no SPF record at all in one specific way: it looks like you configured something, so nobody goes looking for the real problem until deliverability has already dropped.

Confirm it’s fixed

Run the free SPF checker below. It recounts your lookups after every edit, so you can see the number drop below 10 before you consider it done.