What happens when an SPF record exceeds DNS lookup limits?

SPF has a hard cap: 10 DNS lookups during evaluation. Every include, a, mx, ptr, or exists mechanism counts, and some of them chain into further lookups you can't see from the outside. Cross that limit and SPF returns a permerror.

Permerror means the receiving server can't finish evaluating your record. Most mailbox providers treat a permerror the same as a fail. Your authentication doesn't pass, DMARC can't align on SPF, and deliverability takes a hit even for your legitimate mail.

Why 10?

But The limit lives in the SPF spec (RFC 7208) to protect DNS infrastructure from recursive lookup loops and amplification attacks. It's not arbitrary, and no receiver is going to raise it. You have to work within it.

How to tell if you're over

Our SPF checker counts lookups and flags the culprits. The usual suspects are domains running several senders at once (Google Workspace plus Mailchimp plus SendGrid plus a helpdesk), each one chaining into nested includes you didn't know existed.

How to fix it

A few options, in the order you should like them:

• Remove senders you don't actually use. The easiest win. Audit every include and delete the ones from services you stopped using 2 years ago (it happens to everyone).
• Consolidate senders. If you're running 4 ESPs, ask whether you really need 4. Each one eats lookups.
• Replace "include" with specific IP ranges. Instead of including a third party's whole record, list the specific ip4: or ip6: ranges they give you. This trades maintenance for headroom.
• SPF flattening as a last resort. Some tools rewrite your record with only IPs, eliminating lookups. It works, but you have to refresh it when the upstream provider's IPs change. Set a reminder. Otherwise mail will silently break.

So if If your record is blowing past 10 lookups and you're not sure which includes to cut, the SOS hotline is free and we've seen every variation of this mess.