SPF permerror: “too many DNS lookups”, and how to get back under ten

A validator, a report or a bounce told you your SPF record produces permerror — usually with the words too many DNS lookups or maximum lookup limit exceeded. Your record is not malformed and nothing is misspelt. It costs a receiving mail server more DNS queries than the standard allows, so some receivers stop evaluating it and treat your domain as though it published no SPF at all. This page explains where the cost comes from and how to get back under the limit, in full and for free.

Why the record still looks perfect

This is the part that makes the failure expensive. Your DNS console shows one line of text, and that line is correct — correct syntax, correct providers, correct -all at the end. The cost is not in your record. It is in the records your record points at, which belong to other companies and change without telling you. A domain that counted eight lookups last year can count eleven this year because a provider added an include inside its own record.

So there is no moment where anything appears to break. The mail simply starts failing authentication, and every place you would look to explain it shows a valid SPF record.

What we measured

We counted the true recursive lookup cost of every SPF record published by the 83 independent small-business domains behind our published study. 69 of them publish an SPF record we could count all the way through. 1 is over the ten-lookup limit — 1.4% — and 1 sits at nine or ten, which is to say one added service away from it.

The fix, in the order worth trying

1. Count what you actually spend, recursively. Not the number of include: mechanisms in your record — the total after every nested record is expanded. This is the number nothing in a DNS console shows you, and the reason this fault is normally found only after mail has already failed.
2. Delete senders you no longer use. This is the fix that works most often and costs nothing. SPF records accumulate: a mail provider you migrated off, a marketing tool from a campaign three years ago, a form plugin that was replaced. Each dead include: is still charging you one lookup, and frequently several.
3. Move bulk senders to a subdomain. Send newsletters from mail.yourcompany.com or news.yourcompany.com, with its own SPF record and its own ten-lookup budget. The subdomain is a separate domain as far as SPF is concerned, so its cost is charged separately — and DMARC alignment still holds under the default relaxed mode, because the organisational domain is the same.
4. Replace an include: with the IP ranges it publishes — “flattening” — only as a last resort, and only for a provider that publishes stable addresses.

   Flattening moves the failure rather than removing it. The whole point of an include: is that the provider maintains the address list. Write those addresses into your own record and you have taken on that job silently and permanently: the day the provider adds a sending IP, your mail from it fails SPF and nothing anywhere will say why. If you flatten, put a calendar reminder on it. A flattened record is a maintenance commitment, not a fix.

5. Lean on DKIM. DKIM costs no SPF lookups at all, and a DKIM signature survives forwarding, which SPF alignment does not. A domain whose mail is properly DKIM-signed keeps passing DMARC even when SPF is having a bad day.

What a corrected record looks like

One record, one all, only the senders still in use. Never publish two SPF records for the same name — two records is itself a permerror, and a different one:

Type   TXT
Name   @
Value  v=spf1 include:_spf.google.com include:servers.mcsv.net -all

Then the bulk sender on its own name, with its own budget:

Type   TXT
Name   news
Value  v=spf1 include:sendgrid.net -all

Count yours

Our free check resolves your SPF record the way a receiver does, walks every nested record, and reports the total against the limit — both when you are over it and when you are one service away from it. It takes a few seconds, needs no account, and the number comes back whether or not anything is wrong.

What it cannot do, said plainly: it reads what your domain publishes right now. It cannot tell you which of your senders you have stopped using — only you know that — and a provider can change the cost of its own record tomorrow without touching yours. That last point is the entire argument for checking it on a schedule rather than once.

Every figure on this page is generated from the stored raw measurement files behind our 604-domain study (522 agency-built sites measured 2026-08-20, 83 independent domains measured 2026-08-01), and the quoted finding wording is read out of the running checker at build time. An automated control re-asserts both against this live page on every operating cycle; if either changed and this page did not, it fails. Generated 2026-09-05T23:34:13Z.