Too many lookups in your SPF record
RFC 7208 §4.6.4 caps an SPF evaluation at ten DNS lookups. Exceed it and the result is permerror — not a warning, not a partial pass. Most receivers treat permerror as a fail, so a record that looks entirely reasonable can already be costing you delivery.
How the count works
The limit is global across the whole recursive evaluation, not per record. Each include, a, mx, ptr, exists and redirect costs one — and every mechanism inside an included record counts against the same budget.
That is why the number rises without anyone touching your record: include:_spf.google.com alone expands into several further includes, and a provider that adds one on their side pushes you over your limit from their DNS.
Getting back under it
In rough order of how much they buy you and how little they cost:
- Remove includes for services you no longer use. This is usually where the whole overage sits.
- Replace a stable include with the
ip4:/ip6:ranges behind it. Those cost no lookup — but they are now yours to keep in sync when the provider renumbers. - Drop
ptrentirely. It is deprecated (RFC 7208 §5.5), costs a lookup, and receivers dislike it. - Drop a bare
mxif your mail servers do not send outbound. It costs a lookup plus one per MX host returned.
Void lookups, the second limit
The same section caps void lookups — queries returning no record — at two. An include pointing at a domain that no longer publishes SPF is a void lookup, so a decommissioned service can trip this even while your total stays under ten.
Measuring it
The scan at the bottom of this page evaluates your record recursively, prints the count, and lists every include it followed with the record it retrieved from each. That list is where you see which include is responsible.
Frequently asked questions
My record has four includes. How can that be over ten?
Because each include expands. _spf.google.com and spf.protection.outlook.com each pull in several more records; the budget is spent inside them, not in your own record.
Does a longer TXT string break anything?
Length is a separate concern: a single character-string caps at 255 bytes, and longer values are split across several strings which a receiver concatenates without a separator (RFC 7208 §3.3). That is normal and does not affect the lookup count.