SPF "too many DNS lookups": what it means and how to fix it

SPF is the record in your domain's DNS that lists which servers may send email for you. A receiving server reads it each time a message arrives. Some parts of the record are written out in full, such as ip4: and ip6: addresses, and cost nothing to read. Others make the receiving server go and look something up: include:, a, mx, ptr and exists, and the redirect= modifier.

The SPF standard, RFC 7208, caps those lookups at ten for one check. Past ten, the receiving server stops and returns permerror, a permanent error. The same standard says a server should also give up after two lookups that find nothing at all ("void lookups"), which is what an include: pointing at a service you no longer use can produce.

Every service that sends email as your domain, from your newsletter tool to your invoicing package, asks you to add its include:. Each one is reasonable on its own. The record fails on the day one more is added, and nothing in your own inbox tells you.

It can also break without anybody touching it. A provider can add an include: inside its own record, and your count goes up with it. Google's set-up page puts the rule as up to ten include: tags, which is the simple version of the same limit.

Microsoft adds a detail that makes the fault hard to spot. A receiving server reads the record left to right and stops at the first match, so mail from the service listed first can pass while mail from one near the end fails. The same record works for some messages and not others.

Microsoft says the receiving system can refuse a message that fails this way, with a bounce that reads "The message required too many lookups" or "The message exceeded the hop count".

It also weakens DMARC, the policy that tells receivers to refuse email forged in your name. DMARC passes when either SPF or DKIM passes and lines up with your domain. With SPF in error, everything rests on DKIM: if a service sends unsigned mail, or signs it as itself, that mail now fails DMARC, and at p=reject it is refused. Our guide to SPF, DKIM and DMARC explains how the three fit together.

Counting by hand means following every include: to its own record and counting again, all the way down. The free email security check does that from public DNS and tells you the total, along with whether you have one SPF record or several, and what your DMARC policy says.

Two records is a fault of its own: the standard allows one per domain, and a receiver that finds two returns permerror whatever they contain.

In the order to try them, cheapest first.

Change one thing at a time and check the result before the next. Before you remove an include:, read your DMARC reports or ask the service whether it still sends for you: a service you forgot about is exactly the one a lookup was paying for.

Leave the end of the record as it is while you work. Microsoft recommends -all for Microsoft 365 domains, because it also recommends DKIM and DMARC alongside it. Google recommends ~all for Google Workspace. Either way, the setting that decides whether forged mail is refused is your DMARC policy, not this one.

If you would rather not do it yourself, our email protection job counts the record, fixes it, sets DKIM and moves DMARC to enforce, then scans again to show it from outside.