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

What PermError means

SPF allows a limited amount of DNS work. RFC 7208 caps an SPF check at 10 DNS-querying mechanisms, and if your record needs more than that to evaluate, the receiver must return permerror (a permanent error), not a pass or a fail. permerror means “this SPF record could not be evaluated,” and receivers treat it as SPF not passing.

You will see it in the message headers as:

Authentication-Results: ... spf=permerror ...
Received-SPF: permerror ...

When a message is rejected for it during the SMTP conversation, RFC 7208 says the server should use a 550 reply with the 5.5.2 enhanced code.

What actually counts toward the 10

This is the short version; the full walkthrough is in Counting your SPF lookups.

• Counts (one each, including everything reached inside an include:): include, a, mx, ptr, exists, and the redirect= modifier.
• Free (zero lookups): ip4, ip6, and all.

Every include: is recursive and spends from the same budget, so three or four stacked providers are the usual way domains cross 10. There is also a separate limit: more than two “void” lookups (a name that does not exist, or has no record of the type queried) is its own permerror, usually caused by an include: pointing at a retired hostname.

Why it breaks more than SPF

permerror is not a pass, so it contributes nothing to DMARC. DMARC passes only if SPF passes and aligns, or DKIM passes and aligns. So if your SPF is in permerror and DKIM is not passing-and-aligned, DMARC fails. A quarantine or reject policy requests that treatment, but the receiver decides delivery. (The flip side: if DKIM passes and aligns, DMARC still passes despite the SPF permerror. Fixing SPF is still worth it, but DKIM is your safety net.)

How to fix it (safest first)

• Confirm a service is retired before removing its include. Check with the service owner and review sending history, including seasonal mail and mailbox replies. Public DNS shows authorization, not whether a service is still used. A quiet report window alone is not proof that removal is safe. Keep the original record so you can restore it if a legitimate sender stops passing SPF.
• Drop ptr mechanisms. ptr is slow, discouraged, and lookup-heavy. Replace its intent with the provider's include: or explicit ip4: / ip6:.
• Merge multiple SPF records into one. If you have more than one v=spf1 record, that is its own permerror; see Merging multiple SPF records.
• Swap a stable mx for ip4: / ip6:. IP mechanisms cost zero lookups. Safe only when those IPs do not change.
• Split sending by subdomain. Move bulk or marketing mail to a subdomain with its own SPF record. Each subdomain gets a fresh 10-lookup budget.
• Flatten, carefully. Replacing an include: with the provider's published IP ranges buys the most headroom (IPs are free), but it freezes a snapshot: when the provider rotates its sending IPs, your record silently stops covering real mail and you get no error. Only flatten ranges a provider documents as stable, and re-check them on a schedule. Never flatten a provider that tells you to use their include:.

How to confirm it is fixed

• Run the SPF lookup counter: it walks every include:, counts your lookups against the RFC 7208 cap, and explains what is over budget.
• Re-check that spf=permerror is gone from a test message's Authentication-Results and that you now see spf=pass.
• Watch your DMARC reports: the sources that were failing on SPF should start passing.

Frequently asked