SPF PermError means your SPF record triggers more than 10 DNS lookups, the hard limit set by RFC 7208. Every include, a, mx, ptr, exists and redirect counts — and each include adds the lookups inside it. Fix it by removing unused includes, replacing some with ip4:/ip6: addresses, or flattening the record.
SPF is evaluated by the receiver in real time, so the spec caps DNS work at 10 lookups to prevent abuse and slow delivery. Cross the limit and the result is PermError — treated as a failure, which can send your legitimate mail to spam or get it rejected under DMARC.
Counts toward the 10: include, a, mx, ptr, exists, redirect — and recursively, everything inside each include. Does not count: ip4: and ip6: mechanisms, and the all mechanism. That asymmetry is the key to the fix.
1. Remove what you no longer use. Old ESPs and tools left in SPF are the most common cause. 2. Consolidate. Some providers publish a single leaner include. 3. Replace includes with IPs. If a service publishes stable IP ranges, swap include:service.com for its ip4: blocks — these cost zero lookups. 4. Flatten as a last resort, and only with monitoring, because a provider that changes IPs will silently break a flattened record.
Confirm there is exactly one SPF record and see its mechanisms:
$ dig TXT yourdomain.com +shortThe SPF checker above expands every include and reports your real lookup count and which include costs the most.
Check your SPF record now
Open the free SPF checker →No. ip4: and ip6: mechanisms cost zero DNS lookups, which is why replacing an include with its IP ranges is an effective fix.
It works but is fragile: it bakes a provider’s current IPs into your record, so when they change IPs your mail can fail. If you flatten, use a service that auto-updates the record and monitor it.
Yes — publishing more than one SPF record is a separate cause of PermError. A domain must have exactly one.
