SPF lookup budget

What this check looks at

Authentication group · check id spf.lookups · all thirteen checks

“SPF is capped at 10 DNS lookups across the whole include chain. Go over and receivers stop evaluating it entirely.” - the wording shown beside this check while it runs.

Every include:, a, mx, ptr, exists and redirect in your SPF record costs a DNS lookup while a receiver evaluates it - and each included record can contain its own, which cost more. The standard caps the total at ten.

Why it matters

This is the failure that looks like success. Go over ten and the evaluation returns a permanent error, so a receiver stops evaluating your SPF entirely. Your record is still there. It reads perfectly. Nobody honours it, and nothing tells you.

It arrives by accretion rather than by mistake: a CRM, an invoicing tool, a helpdesk, a marketing platform - each one adds a legitimate include, and the eleventh one silently switches the whole record off.

What each verdict means here

Pass

The whole chain resolves inside the ten-lookup budget.

Warn

Close enough to the ceiling that the next provider you add will break it.

Fail

Over the limit. Receivers are entitled to ignore your SPF record completely, and many do.

What to do

1. Remove includes for services you no longer use - this is usually enough on its own, and costs nothing.
2. Consolidate: several tools sending through one provider need that provider included once, not each tool separately.
3. Replace an include with the specific ip4: or ip6: ranges it resolves to where the provider publishes stable addresses. Those cost no lookups - but they will not track a provider that changes its ranges, so this needs a review date.
4. Avoid ptr entirely. It is deprecated, slow, and counts against you.

What this check does not do

We count what public DNS returns today. A provider that changes its own included record tomorrow can push you over the limit without you touching anything - which is why this is worth re-checking rather than fixing once.