SPF PermError high
SPF PermError: Too Many DNS Lookups
Your SPF record triggers more than 10 DNS-querying mechanisms, so evaluators return PermError and SPF fails for every message.
What you see
Received-SPF: permerror (google.com: permanent error in processing during lookup of [email protected]: Number of lookups exceeded) spf=permerror (sender IP is 203.0.113.5) smtp.mailfrom=yourdomain.com
What’s actually happening
Mail that used to authenticate starts failing SPF, and the Authentication-Results header shows spf=permerror instead of pass. Nothing changed on the sending IP. What changed is the count of nested lookups, usually because someone added another vendor include. DMARC reads a PermError as an SPF failure, so if DKIM is not aligned the whole message fails DMARC too.
Common causes
- The record chains too many include: statements; each vendor (Google, a CRM, a help desk, a marketing tool) adds one or more lookups, and the total crossed 10.
- Nested includes hide the real cost. include:_spf.google.com alone expands to several sub-includes that each count.
- Use of a, mx, ptr, or exists mechanisms, all of which require a DNS query and count toward the limit.
- More than two void lookups (queries returning NXDOMAIN or NODATA) from a dead include or a stale a/mx target. The void cap is 2, and each void also counts against the 10.
- A redirect= modifier that itself points at a record full of includes.
How to fix it
- Count the lookups firstRun your domain through an SPF checker, or expand the record by hand. ip4:, ip6:, and all do not count. include, a, mx, ptr, exists, and redirect do. You need the DNS-querying count at 10 or fewer.
- Drop includes for tools you no longer send fromOld vendor includes pile up. If you stopped using a service, delete its include. This is the cheapest fix and often gets you back under the limit on its own.
- Flatten the recordReplace high-cost includes with the literal ip4:/ip6: ranges they resolve to. This trades zero lookups for those ranges. The tradeoff: when the vendor changes IPs you must re-flatten, so either monitor it or use a managed flattening service that keeps the record current.
- Move some senders to subdomainsSend bulk mail from mail.yourdomain.com or news.yourdomain.com with their own SPF records. Each subdomain gets its own 10-lookup budget, which splits the load.
- Fix or remove void lookupsCheck for includes or a/mx targets that return NXDOMAIN/NODATA. Repoint or delete them so you stay under the 2-void cap.
Stop it recurring
Treat the SPF record as a budget: every time a vendor is added, recount the lookups and prune anything unused so you never silently cross 10.
Related errors