SPF's 10-lookup limit: why SPF breaks and how to fix it

An SPF record can cost a receiving server at most ten DNS lookups to evaluate. Go over that and the check does not partially pass: it returns a permanent error, which most receivers treat the same as an SPF failure. The limit comes from the SPF specification itself (RFC 7208, section 4.6.4), so every major mailbox provider enforces it.

It is also the most common way a record that used to work stops working. Nobody edits SPF to break it; they add one more include for a new helpdesk, billing or marketing tool, and the total quietly crosses ten.

What counts toward the ten

Only the parts of a record that make the receiver query DNS count. Everything else is free.

• Counts: include:, a, mx, ptr, exists: and the redirect= modifier. Each costs one lookup.
• Counts recursively: an include: pulls in another SPF record, and every lookup inside that record counts toward your ten as well.
• Free: ip4:, ip6: and all. They are evaluated without asking DNS anything.

The recursion is what catches people out. A single include for a large provider can cost several lookups on its own, because that provider’s record includes further records. You cannot see this by reading your own TXT record; you have to follow the chain.

v=spf1 include:_spf.google.com include:mail.zendesk.com include:servers.mcsv.net mx a ~all

# Five terms that cost lookups on the surface. Each include may cost more
# underneath, so the real total is usually higher than it looks.

The domain health checker follows every include and reports the real total, so you can see how close to ten you are before a new tool pushes you over.

The other rule that fails SPF outright

A domain may publish only one SPF record. Two TXT records that both start with v=spf1 is also a permanent error, even if each would pass on its own. It usually happens when a new service’s setup guide says “add this TXT record” and someone adds it next to the existing one instead of merging the two.

How to get back under the limit

Work through these in order. The first two are free and carry no risk; the last two trade convenience for maintenance.

1. 1Remove includes for services that no longer send as your domain. Old marketing tools and trial accounts are the usual culprits. If a service stopped sending months ago, its include is pure cost.
2. 2Drop mechanisms you do not need. The mx and a mechanisms authorise your own mail servers and web host, which often do not send mail at all. ptr is deprecated by the specification and should not be used.
3. 3Move a service to a subdomain. Bulk or third-party mail can be sent from something like news.example.com, which has its own SPF record and its own budget of ten. It also keeps that service’s reputation separate from your main domain.
4. 4Flatten carefully. Replacing an include with the ip4:/ip6: ranges it resolves to costs no lookups, but when the provider changes its ranges your record is silently wrong. Only flatten a provider whose ranges you are prepared to monitor, or use a service that re-flattens automatically.

~all or -all?

The ending says what a receiver should do with mail from a server not listed. -all (fail) is stricter than ~all (softfail), but once DMARC is in place the difference matters much less: DMARC decides the outcome from whether SPF or DKIM passed and aligned, not from which of the two endings you chose. Never use +all, which authorises every server on the internet to send as you.

What SPF does not do

SPF checks the envelope sender (the Return-Path), not the From address people see, and it breaks when mail is forwarded because the forwarding server is not in your record. That is why SPF on its own is not enough, and why DKIM and DMARC exist. DMARC alignment explains how the three fit together.