Kangarua

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:

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.

Check your domain

Free, no account. You get a list in plain language.