What is an SPF lookup limit?

SPF lookup limit, defined
The SPF lookup limit is the ceiling of ten DNS queries a receiving server will spend evaluating your SPF record, after which the check returns permerror and effectively fails.

The mechanisms that cost a lookup are include, a, mx, ptr and exists. The ip4 and ip6 mechanisms cost nothing, which is the arithmetic behind flattening.

A single include:_spf.google.com spends one lookup and then several more inside, because Google's record includes three of its own. Four platforms configured this way is how a record that looks short breaks.

The failure is silent and total. A permerror is not a soft failure on one message; receivers treat the whole record as unusable, so mail that would have passed now has no SPF result at all.

Checking is quick and worth doing after any change to your stack. Adding a helpdesk trial that nobody removed is the classic way a working record quietly crosses the line.

How ZapBounce reports it

The SPF checker reports the exact count and the chain that produced it, rather than a pass or fail badge. Seeing which include spent four lookups is what tells you where to cut.

Counting a record by hand with dig

Run dig +short TXT yourdomain.com and find the line starting v=spf1. Write down every include, a, mx, ptr and exists, plus a redirect if there is one, because that modifier costs a lookup too. Each of those is one. Now run the same command against every include target and keep counting what you find inside.

Say your record has three includes and an mx. That looks like four. The first include holds three more includes, the second holds one, and the third is plain ip4 ranges. Your real total is 4 + 3 + 1 = 8. Add one more vendor whose include nests two others and you're at eleven without having typed anything that looked risky.

The mx mechanism has its own wrinkle. It costs one lookup toward the ten, and the address lookups for the mail hosts behind it fall under a separate cap of ten per mechanism.

The second limit almost nobody checks

RFC 7208 sets another ceiling beside the famous one. If more than two lookups come back empty (a name that doesn't exist, or a name with no matching record), the evaluation ends in permerror as well. These are called void lookups.

This is how an old vendor hurts you after you've stopped paying them. Their include target gets deleted, your record still points at it, and that's one void lookup spent on every message. A second dead include, or an a mechanism aimed at a hostname you retired, puts you on the limit with no room left.

It helps to know the scope of the budget too. Those ten lookups apply to one evaluation of one domain, which is the domain in the envelope sender. A subdomain with its own SPF record gets its own ten. That's why moving your marketing platform to news.yourdomain.com frees up room on the main domain instead of just shuffling the problem around.

SPF lookup limit: common questions

Which mechanisms count toward the limit?

include, a, mx, ptr and exists each cost at least one. ip4 and ip6 cost nothing, which is why flattened records stay under it.

What happens at eleven lookups?

The receiver returns permerror and discards the result. Your mail is evaluated as though you published no SPF record.

How do I get back under ten?

Remove unused senders, split by subdomain, or flatten the largest include. Removal is the fix that does not need maintaining.

See this on your own list

100 free checks a month, and the unknowns come back labeled.