SPF “permerror: too many DNS lookups” — the 10-lookup limit explained and fixed

What this error means

SPF permits at most 10 DNS-querying terms during evaluation (RFC 7208 §4.6.4). The budget includes evaluated nested includes and redirects. SPF stops at the first matching mechanism, so different sending IPs can follow different paths. Exceeding the budget returns permerror for that evaluation; it does not automatically invalidate every sender. DMARC can still pass through a valid, aligned DKIM signature.

You’ll see it in DMARC reports, in message headers (spf=permerror), or in a domain scan. Some receivers treat permerror as fail; under a DMARC enforcement policy, that can mean rejection.

Why you’re seeing it

The evaluated include:, a, mx,ptr, exists and redirect terms count toward the budget. Nested includes also count, whileip4, ip6 and all do not. A typical small-business record accumulates terms like this:

v=spf1 include:spf.protection.outlook.com include:_spf.google.com
include:servers.mcsv.net include:sendgrid.net
include:_spf.salesforce.com include:spf.invoicing-tool.example
a mx ~all

Each vendor’s include may itself contain two or three nested includes. Vendors also restructure their records without notice — which is why a record that validated last year can silently break today, with no change on your side.

How to fix it

1. Review the lookup paths. Resolve the include tree and test representative sending IPs. A recursive configuration count is a useful risk estimate, not a simulation of every message.
2. Remove what you don’t use. Old vendors, the ptr mechanism (deprecated and expensive), and a/mx mechanisms that duplicate an include.
3. Prefer DKIM where possible. Many services authenticate fully via DKIM alone; if a tool signs with your domain, its SPF include may be unnecessary for DMARC purposes.
4. Flatten as a last resort — with care. Replacing includes with literal IP addresses removes lookups but freezes a snapshot of your vendors’ infrastructure; when they change IPs, your record is silently wrong. If you flatten, it must be automated or monitored — a manually flattened record is a time bomb.
5. Re-check after every new tool. The lookup budget is the reason “set and forget” fails: each SaaS signup spends part of it.

Why this matters more than it used to

Until 2024, a broken SPF record mostly meant slightly worse spam scoring. Now Google, Yahoo and Microsoft require passing authentication, and EU guidance points the same way — CSIRTs across member states recommend SPF, DKIM and DMARC as the baseline defence against sender forgery, and supply-chain security clauses under NIS2 increasingly ask suppliers to demonstrate exactly this. A permerror can affect delivery, even when aligned DKIM still passes DMARC.