sfw/fix
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

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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