What the limit is
When a receiving server evaluates your SPF record, it is not allowed to make unlimited DNS queries. The specification caps it at ten. The cap exists to stop SPF being used to amplify traffic at a third party: without it, a maliciously nested record could make every receiving server in the world perform hundreds of lookups against a victim's DNS.
Five mechanisms count toward the limit: include, a, mx, ptr and exists. Two do not: ip4 and ip6, because a literal address needs no resolution. The all mechanism does not count either.
The trap is that nesting counts. An include costs one lookup for itself plus every lookup inside the record it pulls in. A single include for a large mail platform can consume three or four on its own, so a record that looks like five entries can quietly be evaluating twelve.
Why it breaks more than you expect
Going over the limit does not produce a softer result. The receiver returns PermError, and PermError is treated as though no SPF record exists - not as a fail, and not as a pass. Every legitimate message you send is now unauthenticated as far as SPF is concerned.
That matters most in combination with DMARC. DMARC passes if SPF or DKIM passes and aligns. With SPF returning PermError, your entire DMARC outcome now rests on DKIM alone. If DKIM is correctly configured you may never notice; if DKIM is missing for one sending system, that system's mail starts failing DMARC outright, and at p=reject it stops being delivered.
- The failure is silent. Nothing logs an error on your side and no alert fires - the count is evaluated by the receiver, not by you.
- It appears gradually. Each new SaaS tool adds an include, and the record crosses ten on some ordinary Tuesday when a colleague sets up a new mailing platform.
- It is order-dependent in effect. Evaluation stops when the budget runs out, so mechanisms near the end of a long record may never be reached even below a hard failure.
- Nested records change without warning. A provider restructuring their own SPF can push you over the limit with no change on your side at all.
How to get back under
- Remove senders that no longer send. This is the first thing to try and it usually works. Most over-limit records carry an include for a tool that was replaced two years ago.
- Flatten stable includes into ip4 ranges. ip4 costs nothing against the budget. The trade-off is real, though: you now own the maintenance, and if the provider changes their IP addresses without you noticing, that mail starts failing. Only flatten providers who publish stable ranges and commit to notifying changes.
- Move bulk senders onto their own subdomain. Marketing mail sent as news.example.com gets its own SPF record with its own budget of ten, and your primary domain keeps a short, stable record. This is the cleanest permanent fix and it improves your DMARC reporting at the same time.
- Never use ptr. It is deprecated, it costs a lookup, and some receivers ignore it entirely.
- Lean on DKIM. It has no equivalent limit and it survives forwarding, so a correctly signed message passes DMARC even when SPF is having a bad day.
Check the count with any SPF validator before and after a change, and re-check whenever you add a sending service. The full syntax reference is in SPF record, and the broader point that authentication does not touch attacks which never forge your domain is covered in can phishing bypass MFA?.