SPF's 10-lookup limit: why a valid-looking record can still silently fail

RFC 7208 caps SPF evaluation at exactly 10 DNS lookups. Go over, and a receiver is required to treat the whole record as a permerror — not “fail the check,” but stop evaluating it entirely, with nothing in your own DNS ever showing you the count.

The record can look completely fine and still be broken

A DNS lookup for a TXT record either resolves or it doesn’t — there’s no such thing as a query that fails because there were “too many other queries.” That’s exactly why this failure mode is so easy to miss: the record itself resolves fine, lists the right senders, and passes a casual read. The failure happens one layer up, during evaluation — the receiver walks the record, follows every mechanism that requires its own DNS lookup, and once that walk passes 10, RFC 7208 requires it to stop and return permerror for the whole record, not just the mechanisms past the limit.

What actually counts against the budget

Five mechanism types cost a lookup each time they appear: include, a, mx, ptr, and exists. A redirect also costs one, and then hands off evaluation to the record it points at — so its cost doesn’t stop there. mx is the sneakiest of the five: it doesn’t just cost one lookup for itself, it costs one lookup per MX record the domain has, since each one has to be resolved to an IP. A domain with 4 mail exchangers spends 4 of its 10 lookups on a single mx mechanism.

ip4, ip6, and the all qualifier at the end are free — they’re literal values, not lookups.

Why it creeps up without anyone editing the record

The usual path to 11 lookups isn’t someone hand-editing a TXT record until it breaks — it’s include chains. Most cold-email and marketing platforms publish their own SPF record as an include: target, and that record often includes another provider’s record in turn. Add a second ESP, a helpdesk tool, and a CRM that each ask to be included, and the budget is gone before you’ve written a single mechanism yourself — nobody touched the record’s visible content, the total lookup count just grew underneath it.

Bringing it back under 10

• Drop any include for a service you no longer send through — these accumulate silently over a domain’s lifetime.
• Replace mx or a mechanisms with the literal ip4/ip6 ranges they resolve to, if those ranges are stable — this trades a per-request DNS lookup for a free literal.
• Remove ptr entirely if present — it’s deprecated by RFC 7208 itself specifically because of how expensive and unreliable it is, and almost nothing needs it.
• For a genuinely large set of includes, a dedicated SPF-flattening service can pre-resolve the chain into static ip4 ranges — worth it only once simple removal isn’t enough.