SPF PermError: What Too Many DNS Lookups Actually Means
Published August 2026 by Solarc Labs
SPF PermError is a configuration error, not a soft warning
RFC 7208 defines permerror as a condition where the published SPF record cannot be correctly interpreted and requires DNS-operator intervention. One common cause is exceeding the DNS-query budget during SPF evaluation. That is different from a temporary DNS failure: a permanent error will not become healthy merely because the receiver retries later.
The limit is 10 DNS-querying terms across the evaluation
The SPF specification requires implementations to limit the combined number of include, a, mx, ptr and exists mechanisms plus the redirect modifier to 10 during evaluation. If the limit is exceeded, the result must be permerror. Terms such as all, ip4 and ip6 do not consume that same lookup budget. The important operational detail is that nested include chains count too: a short-looking top-level record can expand into a much larger dependency tree.
Count the dependency tree, not just the words in your TXT record
A domain that authorizes several SaaS mail services can move close to the limit without obvious visual complexity. Each included provider can reference more providers, and those nested terms share the same evaluation budget. A useful check therefore resolves the whole SPF path and reports where the lookup budget is spent instead of simply counting include strings in the first record.
Fix unnecessary authorization before reaching for flattening
Start by removing senders that no longer use the domain, separating genuinely different sending jobs onto appropriate subdomains where that fits the mail architecture, and reducing redundant mechanisms. Static flattening can reduce live DNS lookups, but it creates a maintenance obligation because provider IP ranges can change. If a team uses flattening, it needs a controlled refresh and evidence path rather than a one-time copy-and-forget fix.
Monitor SPF as a changing control surface
SPF health is not a one-off setup task. Marketing tools, help desks, billing systems and transactional providers change over time. The practical control is to keep an explicit inventory of authorized senders, monitor material DNS-state changes, and re-evaluate the lookup tree after provider changes. That catches both accidental PermError risk and stale authorization without pretending that SPF alone proves inbox placement.
Primary sources
Sources used for this article
Continue the job