Why SPF has a 10-lookup limit
SPF mechanisms such as include, a, mx, ptr and exists, plus the redirect modifier, trigger DNS work during evaluation. RFC 7208 requires evaluators to stop with PermError when more than 10 of these terms are used.
The count can grow inside nested include chains, so a short-looking top-level record can still exceed the limit. This scanner follows visible include and redirect records on a best-effort basis and shows the result against the limit.
Common causes
Too many providers
Each sending platform often adds an include, and those providers can include other records.
Nested includes changed
A third-party provider can change its SPF tree without changing your top-level record.
Legacy senders remain
Old CRM, support or newsletter includes keep consuming lookup budget after migration.
DNS-querying mechanisms accumulate
a, mx, exists, ptr and redirect also count; ip4, ip6 and all do not.
How to fix it
- Inventory every service currently allowed to send mail for the domain.
- Remove includes for retired providers instead of keeping them as a safety blanket.
- Consolidate overlapping services where the provider offers a supported combined record.
- Treat flattening cautiously: flattened IP lists can become stale and need reliable maintenance.
- Re-scan after each DNS change and test production sending flows before tightening the final policy.
FAQ
An SPF implementation must return PermError when the evaluation exceeds the limit of 10 DNS-querying terms.
The include term counts, and the DNS-querying terms evaluated inside the included SPF record also contribute to the total.
No. Removing unused senders and simplifying supported provider includes is usually easier to maintain. Flattening creates an IP list that must stay synchronized with providers.