Email & DNS
SPF lookup limits: avoid permerror from too many DNS-dependent mechanisms
SPF evaluation has a limit on DNS-querying mechanisms so one sender policy cannot trigger unbounded recursive work. A record can look syntactically valid yet produce PermError when include, a, mx, ptr, exists, or redirect processing exceeds the lookup budget.
Count mechanisms that cause DNS lookups
Inspect the published SPF record and recursively expand includes/redirects from every legitimate sending provider. ip4 and ip6 mechanisms do not consume DNS lookups in the same way, while include and nested provider records often do.
Provider records can change later, so a policy near the limit has little safety margin.
Do not publish multiple SPF records
A domain should have one SPF TXT policy at a given name. Adding a second record for a new service is not additive; receivers can treat multiple policies as an error.
Combine legitimate senders into one policy while staying within syntax and lookup limits.
Remove senders you no longer use
Old newsletter, CRM, support, invoice, website, and marketing services are common sources of unnecessary includes. Confirm ownership before removal so legitimate mail is not broken.
Flattening provider IPs manually can reduce lookup count but creates maintenance risk when providers change infrastructure; use it only with a reliable update process.
Validate with representative mail
Run an SPF parser/validator, then send through every legitimate source and inspect Authentication-Results. DMARC alignment still depends on the visible From domain and is not guaranteed by SPF pass alone.
- Recursively count DNS mechanisms.
- Maintain one SPF record.
- Remove obsolete senders.
- Test every real sending source.