How do I fix an SPF too many lookups error?

Understand where the budget goes first. The mechanisms include, a, mx, ptr and exists each cost at least one lookup, and ip4 and ip6 cost nothing. A single include:_spf.google.com spends one and then several more inside it, because Google's own record includes three others.

So start by counting rather than guessing. An SPF checker resolves the whole chain and shows which include spent what, and the answer is regularly a platform nobody has used since last year.

Removal is the fix that never needs maintaining. Trial tools, a previous helpdesk, an old marketing platform: each one deleted returns its lookups permanently with no ongoing cost.

Subdomain delegation is the next best. Send marketing from news.yourdomain.com with its own SPF record, and that sender's lookups leave your organizational domain's budget entirely.

Flattening comes last because it trades a limit for a maintenance obligation. Replacing includes with the IP ranges they resolve to costs zero lookups and breaks silently when a provider changes its ranges, so it needs re-resolving on a schedule or a service that does it for you.

Say your record reads v=spf1 include:_spf.google.com include:helpdesk.example include:mailer.example include:crm.example mx a ~all. It looks short. Count it anyway.

Google's include costs one lookup, and the three records nested inside it bring it to four. The mx and a terms cost one each, so you're at six. Suppose the helpdesk's record nests two more includes, which makes three for that vendor. The mailing tool is a single lookup. Your CRM's record nests one more, for two. Add them up: 4 + 1 + 1 + 3 + 1 + 2 is twelve. That's two over the limit, from a record that fits on one line.

The nested counts change when vendors edit their own records, so you can pass in March and fail in June without touching anything. Here the quick win is mx and a. If your web server and mail host don't send mail under your domain, dropping both terms saves two lookups and lands you on ten.

The ten-lookup rule has a lesser-known cousin. That same standard allows only two void lookups, meaning lookups that return nothing. An include that points at a vendor domain which no longer exists counts as one. Two of those and the record fails, even if you're far under ten.

Length causes trouble as well. A single text string in DNS can hold 255 characters, so a long flattened record has to be split into several quoted strings inside one record. Some DNS dashboards do that for you and some cut the record off without warning.

Check the ending while you're in there. Both ~all and -all are reasonable. A +all ending tells the world that any server may send as you, and it still turns up in records copied from old forum posts.

After any change, send yourself a message and read the header. You want spf=pass next to your domain. A header that still shows permerror means the record has another problem.