SPF "Too Many DNS Lookups": How to Fix the 10-Lookup Limit

SPF allows a receiving server to perform at most 10 DNS lookups while evaluating your record. Go over that and the check returns permerror, which DMARC treats as an SPF failure for every message. The fix is to count your lookups, remove dead includes, move bulk senders to subdomains, lean on DKIM, and flatten only as a last resort.

Why the limit exists, and what a permerror really does

SPF (Sender Policy Framework) is defined in RFC 7208. When a receiving server gets a message, it takes the envelope sender domain (the Return-Path), fetches that domain’s SPF record and walks through it to decide whether the connecting IP address is authorised. Some mechanisms in that record force the receiver to make further DNS queries. Left unchecked, a single record could trigger hundreds of queries, which would make SPF a convenient amplification tool for denial-of-service attacks. The RFC therefore caps the number of DNS-querying terms at 10 per evaluation.

Exceed the cap and the result is not “softfail” or “neutral”. It is permerror, a permanent error meaning the record cannot be evaluated. Receivers vary in how they treat that on its own, but DMARC is unambiguous: an SPF permerror is not an SPF pass, so SPF cannot contribute an aligned pass for any message from that domain. If DKIM is properly signed and aligned, mail still passes DMARC. If any sender relies on SPF alone, its mail now fails DMARC, and once you move to p=quarantine or p=reject that mail goes to spam or is refused.

The dangerous part is that nobody notices the moment it happens. A colleague adds a new marketing platform, the vendor’s setup guide says “add our include to your SPF record”, and the eleventh lookup quietly breaks SPF for everything, including your main mailbox platform.

What counts as a lookup (and what does not)

The limit applies to terms that require DNS resolution. Literal IP addresses do not. This table is the mental model to keep next to you when reading any SPF record.

The recursion is what catches people out. A single include: for a large email platform might itself contain three or four further includes. Your record may show five terms on its face and still consume eleven lookups once the nested records are expanded.

Void lookups: the second, lesser-known limit

RFC 7208 also recommends a limit of 2 void lookups: queries that return no answer or a “domain does not exist” response. These usually come from includes pointing at vendors you stopped using, whose SPF host has since been removed, or from a and mx mechanisms on hostnames that no longer resolve. Exceed two and many receivers return permerror as well. Dead includes are therefore doubly expensive: they waste budget and they can break the record on their own.

Auditing your record properly

Before changing anything, establish the facts. A good audit answers four questions.

1. What is the true lookup count? Expand every include recursively and count. Our free DMARC checker reports SPF status, and dedicated SPF tools will show the full expansion tree.
2. Which terms map to a sender you actually use today? List every include against a named service and a named owner inside the business. Anything nobody can explain is a candidate for removal.
3. Which senders actually rely on SPF for DMARC? This is where DMARC aggregate reports earn their keep. They show, per sending source, whether SPF and DKIM passed and aligned. A platform that already signs with aligned DKIM may not need to be in your SPF record at all for DMARC purposes.
4. Is there more than one SPF record? Two TXT records starting with v=spf1 on the same domain is also a permerror. It happens more than you would think when a new provider is set up without checking what already exists.

If you are not yet collecting aggregate reports, publish a DMARC record at p=none with a reporting address first. Our article on how to read a DMARC report explains what the data shows.

Fixes, in order of preference

There is a sensible order to work through. Each step is lower risk and lower maintenance than the one after it.

1. Remove what is dead or redundant

Delete includes for platforms you no longer use, remove ptr, and drop a or mx unless your web server or mail server genuinely sends mail directly. On many small business domains, a and mx were added years ago “just in case” and now authorise nothing that sends. This alone often brings a record back under the limit.

2. Replace includes with IP ranges where they are genuinely static

If an on-premises server or a firewall relay sends from a fixed address you control, an ip4: entry costs nothing. Do not do this for cloud platforms whose ranges you do not control; their published includes exist precisely because their addresses change.

3. Move bulk and third-party senders to subdomains

This is the structural fix and usually the best one. Send newsletters from news.yourcompany.co.za, transactional mail from mail.yourcompany.co.za, and so on. Each subdomain has its own SPF record with its own 10-lookup budget, and a problem with one platform no longer threatens your primary domain’s reputation. Many marketing and transactional platforms also set their own return-path on a subdomain you delegate to them, which takes them out of your root SPF record entirely.

4. Rely on aligned DKIM for platforms that support it

DMARC passes if either SPF or DKIM passes and aligns. Where a platform signs with a custom DKIM key on your domain, it does not need to consume your SPF budget for DMARC to pass. SPF still has value for some receivers’ filtering, so do not strip it blindly, but DKIM is the more robust mechanism and survives forwarding. See DKIM explained for the detail.

5. Flatten, carefully, as a last resort

Only once the first four steps are exhausted should you consider flattening.

Flattening: what it is, and its real trade-offs

Flattening means resolving includes into their underlying ip4: and ip6: ranges and publishing those addresses directly, so the record needs far fewer lookups. It works, but it trades a visible problem for a hidden one.

Flattening is safe only when something re-resolves the source includes on a schedule and updates the record when ranges change. A one-off manual flatten pasted into DNS is a time bomb. If you flatten, flatten selectively: keep the includes for the providers whose ranges change most often and flatten only the stable ones.

~all versus -all once DMARC is enforced

The final term of your record tells receivers what to do with mail from unlisted sources. -all (fail) is the strict option; ~all (softfail) is the lenient one. ?all (neutral) says almost nothing, and +all authorises the entire internet and should never appear. Our guide SPF explained covers the qualifiers in more depth.

The intuitive answer is that -all is always better. In practice, once DMARC is at p=reject, DMARC is doing the enforcement and it evaluates SPF and DKIM together. Some receivers act on an SPF hard fail before DMARC is considered, which can reject a forwarded or mailing-list message that would otherwise have passed DMARC through aligned DKIM. For that reason, many practitioners keep ~all on sending domains with an enforced DMARC policy and reserve -all for domains that never send. Either is defensible; what matters is that the choice is deliberate and the record is accurate.

A maintenance checklist that keeps you under 10

• Every include in the record maps to a named service and a named internal owner.
• No ptr, no +all, no duplicate v=spf1 records.
• a and mx appear only if those hosts genuinely send.
• Total recursive lookup count is checked after every change, with headroom of two or three lookups left for the next platform.
• Void lookups are zero, not merely under two.
• Bulk and marketing senders sit on subdomains with their own records.
• Every platform that supports custom DKIM is signing aligned with your domain.
• Any flattening is automated and re-checked, never a static paste.
• New vendors are added through one process, not by whoever has DNS access that day.

That last point is the real cure. Lookup limits are rarely a technical problem; they are a change-control problem that shows up in DNS.

MailMarq reviews SPF lookups as part of every engagement, removes dead weight, moves senders where it makes sense, and applies flattening only where it is needed and maintained. We then watch the domain all year so a new vendor does not quietly push you back over the limit. Start with a free assessment through our contact page, or see the annual packages.

Frequently asked questions

MailMarq
MailMarq is a managed DMARC service run from Johannesburg. Our team has built and managed business websites, hosting and email infrastructure for South African companies since 2016, and writes these guides from work on real domains.