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

What this error means

Your SPF record requires more than 10 DNS lookupsto evaluate, which violates a hard limit in the SPF standard (RFC 7208). Receiving servers stop evaluating and returnpermerror — and here is the part that surprises people: a permerror invalidates your entire SPF record, for every sender, including the ones that were configured perfectly. Combined with DMARC, it can mean all your mail suddenly fails authentication at once.

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

Every include:, a, mx,ptr, exists and redirectmechanism in your SPF record costs at least one DNS lookup — andincludes count recursively. A typical small-business record accumulates lookups invisibly:

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. Count your actual lookups. The limit counts recursively — every include’s own nested includes spend your budget too — so resolve the full tree rather than counting only the mechanisms you can see at the top level.
2. Remove what you don’t use. Old vendors, theptr mechanism (deprecated and expensive), anda/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 doesn’t just weaken your posture; it zeroes it.