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. permerrormeans “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 is 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 and your mail is quarantined or rejected per your policy. (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)

• Remove dead and duplicate includes. Audit each include: against the tools you actually send from and delete the ones you do not. This also clears stale void lookups. Zero risk, you are removing authorizations nothing uses.
• Drop ptr mechanisms. ptris 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 genuinely 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 authorizing 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

Is permerror the same as an SPF fail?

No. A fail (the -allqualifier) means “this IP is not authorized to send.” A permerrormeans “your SPF record could not be evaluated at all,” here because it needs more than 10 DNS lookups. Receivers treat permerror as SPF not passing, which is why it can drag DMARC down with it.

Do ip4 and ip6 count toward the 10?

No. Only the mechanisms that trigger DNS, which are include, a, mx, ptr, and exists, plus the redirect modifier, count toward the limit. ip4, ip6, and allare free. That is why replacing an include with the provider's IP ranges lowers your lookup count.

Will flattening my SPF record fix it for good?

It fixes the count, but it freezes your provider's IP list into a snapshot. When the provider rotates its sending IPs, your record silently stops authorizing real mail and you get no error. Only flatten ranges a provider documents as stable, and re-verify them on a schedule.

Does PermError mean my mail bounces?

It can. permerror is SPF not passing, so if DKIM is also failing or unaligned, DMARC fails and your mail is quarantined or rejected per your policy. If DKIM passes and aligns, DMARC still passes despite the SPF permerror.