What Is the SPF Lookup Limit?
TL;DR
The SPF lookup limit is the rule that a single SPF evaluation may follow at most 10 DNS lookups. Exceeding it returns permerror, which leaves the receiver with no usable SPF result at all, so a record that has grown too long fails rather than degrading quietly.
Which mechanisms count toward the 10 lookups?
The include, a, mx, ptr and exists mechanisms, and the redirect modifier. The all, ip4 and ip6 mechanisms and the exp modifier cause no DNS query while SPF is being evaluated, so they are free.
The count is cumulative across nesting. Every include your record names pulls in a record that may hold includes of its own, and each of those counts against the same total of 10, which is how a record that looks short reaches the cap.
What happens when the limit is exceeded?
The evaluation returns permerror. That is neither a pass nor a fail: there is no usable result, so DMARC has no aligned SPF pass to work with and the message rests on DKIM alone.
There is a second, tighter limit worth knowing. Lookups that come back with no records, called void lookups, should be capped at two, so a record pointing at an include target that no longer exists can produce a permerror well before ten queries have been made.
How do you get a record back under the limit?
Start by removing sending platforms that are no longer in use, which is usually where the slack is. Then replace an include with explicit ip4 terms where a provider publishes a stable range, because those terms cost nothing.
Flattening, meaning resolving every include down to addresses and publishing those directly, does bring the count to zero, but it moves the maintenance to you. When the provider changes an address the record is silently wrong until somebody refreshes it.
Frequently asked questions
No. The query that fetches your own record is not one of the ten. The count applies to the terms inside it that cause further queries, which is why a record with ten includes is already at the cap before any nesting is considered.