Fixing too many DNS lookups: the SPF 10-lookup limit

If your SPF record uses more than ten DNS lookups, SPF stops working. Not “works a bit worse”, but returns an error that most receivers treat as an outright failure, which can drag your legitimate mail down with it. The limit is part of the SPF standard, RFC 7208, and it catches growing businesses constantly. Here is what the limits are, what breaks when you cross them, and how to fix it without cutting off real senders.

The limits, in plain numbers

SPF (Sender Policy Framework) is the DNS record listing which mail servers are allowed to send for your domain. To keep a single check from hammering DNS, RFC 7208 sets hard ceilings:

• 10 DNS lookups. Every include, a, mx, ptr and exists mechanism, and every redirect, costs one lookup. Ten is the total for the whole evaluation, including the lookups your providers’ records trigger inside their own records.
• 2 void lookups. A void lookup is one that comes back empty (no such record). More than two of these and the check fails, which usually points at a typo or a decommissioned provider still listed in your record.
• 255 characters for a single string. A DNS text record is built from strings capped at 255 characters each.
• About 450 bytes for a single UDP response. DNS answers that are sent over plain UDP need to fit in a modest packet, and an oversized SPF answer can be truncated or dropped.

The lookup limit is the one that bites in practice, because it is invisible until you trip it.

Why ten is easy to hit

The trap is that include mechanisms nest. When you write include:_spf.google.com, that record itself contains more includes, and every one of those counts against your ten. So a record that looks like it uses four includes can quietly cost eight or nine lookups once the providers’ own records are counted.

A typical small business stacks up mail providers over time: one for email, one for the newsletter, one for invoicing, one for the support desk, one for the CRM. Each looks harmless. Together they sail past ten, and nothing warns you, because you added them one at a time and mail kept flowing until the day it did not.

What actually breaks

When SPF evaluation exceeds the lookup limit, it returns a result called permerror, short for permanent error. The standard says a permerror means the record could not be evaluated, and most receivers treat that as SPF simply not passing.

The knock-on effect depends on the rest of your setup. If a message still has a valid, aligned DKIM signature, DMARC can pass on DKIM alone and the mail gets through. But if you were leaning on SPF for a particular sending system, that mail now fails authentication, and under an enforced DMARC policy it can be sent to spam or refused. The failure is also intermittent-looking from the outside, which makes it maddening to diagnose: the record did not change, but a provider quietly added a lookup inside their own record and pushed you over the edge.

How to fix it

The goal is to get the total back under ten while keeping every real sender working. In rough order of preference:

Remove what you no longer use

Start here, because it is free. Old providers you have stopped using are often still sitting in the record, each costing a lookup (and sometimes a void lookup). Cut them. This alone frequently solves the problem.

Consolidate senders

If two tools can send through the same provider, route them that way rather than adding a second include. Fewer distinct sending platforms means fewer lookups.

Flatten the stable ones

Flattening means replacing an include with the actual IP ranges it resolves to, written directly into your record with ip4 and ip6 mechanisms. Those cost no DNS lookups, so flattening a couple of includes can bring you back under the limit.

Flattening has a real and important tradeoff, and getting it wrong causes exactly the outage you were trying to avoid. When you flatten, you freeze a provider’s IP list into your own record. If the provider changes their sending IPs, your record is now wrong and their mail fails, and you get no warning.

So the rule is: flatten small, stable senders whose IP ranges rarely move, and never flatten the big platforms. Keep a live include: for Microsoft 365 and for Google Workspace in particular. Both change and add sending IP ranges regularly, and the whole point of their include is that they update it and you do not have to. Flattening those is how you end up silently blocking your own primary email months later.

Consider a subdomain

If different sending systems can live on different subdomains, each subdomain gets its own SPF record and its own budget of ten lookups. Sending your marketing mail from news.yourbusiness.com keeps its providers out of your main domain’s SPF count.

Do not paper over it with more strings

It can be tempting to fix a size complaint by splitting the record into more strings, but that does nothing for the lookup limit, which is what usually fails first. Watch the character and byte caps too: keep the record lean enough that a single string stays under 255 characters and the whole answer stays around 450 bytes, so it is not truncated in transit.

The bigger picture

SPF is only one of the two things DMARC can pass on, and it is the more fragile one, since it breaks on forwarding and on limits like these. A healthy setup does not depend on SPF alone. Making sure DKIM is signing and aligned as well gives you a second, sturdier path to a DMARC pass, which we cover in how to align SPF and DKIM.

If you want to know whether your SPF record is close to the limit right now, run the free DMARC checker. It analyzes your live records and flags the lookup count before it becomes an outage. The limits are fixed and unforgiving, but the fix is almost always tidying up rather than adding more.