SPF Too Many DNS Lookups: Why It Happens and How to Fix It
Your SPF record can look correct and still fail during evaluation. Learn how the 10-lookup limit works, why nested includes matter, and how to fix the problem safely.
You add the SPF record your email provider recommends. Later, you connect a newsletter platform, a support desk, and a service that sends transactional emails.
Each service asks you to add another include. Eventually, an email test reports:
SPF permerror: too many DNS lookups.
The record may look perfectly reasonable. The problem is how much work the receiving server must do to evaluate it.
What is the SPF DNS lookup limit?
SPF lets a domain publish which servers may send email on its behalf. Some parts of an SPF record require the recipient to retrieve additional DNS information.
SPF limits evaluation to 10 DNS-querying mechanisms and modifiers, including those reached through nested records. Exceeding that limit produces a permerror, meaning a permanent SPF evaluation error. :chatgpt-content-reference{index="0"}
“10 DNS lookups” is the common shorthand. It does not mean 10 providers or exactly 10 individual DNS packets.
Why a short record can exceed the limit
Consider this illustrative SPF record:
v=spf1 include:_spf.mail.example include:_spf.news.example include:_spf.support.example -all
There are only three visible include entries. However, each included record can reference more records.
Your newsletter provider might use several additional includes to cover different sending systems. Your support platform may do the same.
Those nested entries contribute to the same evaluation budget. Counting only the includes visible in your own DNS record can therefore underestimate the total.
Evaluation also stops when a mechanism matches. Different sending IP addresses can follow different paths through the same record, which helps explain why one sender passes while another encounters an error.
What counts toward the limit?
These mechanisms and modifiers count when evaluated:
includeamxptrexistsredirect
The ip4, ip6, and all mechanisms do not consume this lookup budget. Nested evaluation through include and redirect shares the overall limit. :chatgpt-content-reference{index="1"}
How to fix the problem
1. List every service that actually sends email
Start with an inventory:
- Your business mailbox provider
- Website contact forms and application emails
- Newsletter and marketing platforms
- Support and ticketing software
- Billing systems and monitoring tools
Check the sending configuration of each service. A tool that displays your domain in the visible From address does not necessarily require an entry in your main domain’s SPF record.
For example, a website sending through your existing mailbox provider may already use the authorization that provider requires.
2. Remove obsolete authorizations
Old providers often remain in SPF long after a migration.
Before removing an entry, confirm that the service no longer sends email. Check scheduled campaigns, password resets, invoices, and less frequently used applications.
Removing unused entries reduces complexity and avoids continuing to authorize a provider you no longer use.
3. Check the full include chain
Inspect each included record and its dependencies.
Look for repeated providers, unnecessary layers, and outdated configuration. Use the provider’s current instructions instead of copying an SPF example from an old tutorial.
Do not assume that adding a second include for the same provider improves coverage.
4. Review unnecessary a and mx mechanisms
An a mechanism authorizes addresses associated with the specified hostname. An mx mechanism authorizes addresses associated with its mail exchangers.
Neither belongs in a record automatically.
If your website server does not send email directly, authorizing its address may be unnecessary. Likewise, receiving email through a server does not automatically mean that server handles your outbound mail.
Keep mechanisms that reflect your actual sending setup.
5. Be careful with SPF flattening
Flattening replaces DNS-based authorizations with explicit IP ranges.
It can reduce lookup usage, but those addresses must stay current. If a provider changes its infrastructure, a manually flattened record can become outdated.
Avoid replacing a provider’s include with a one-time list of IP addresses unless you have a reliable process for maintaining it.
What will not solve it?
Publishing a second SPF record does not provide another lookup budget. A domain should publish one applicable SPF policy.
Changing -all to ~all does not fix an evaluation that already exceeds the limit.
Moving an include earlier may help a particular sending IP match sooner, but it does not remove the complexity that later senders may still encounter.
Test real messages after making changes
A DNS check helps you inspect the published policy. A real-message test shows what happened for a particular sending system.
After updating SPF, send a test from each service you use. Check the connecting IP, the envelope sender domain, and the reported SPF result.
You can use MXValidation to inspect a test email’s authentication results. Repeat the test for your mailbox provider, website, and newsletter platform: a successful message from one does not validate the others.
The goal is a maintainable SPF policy that authorizes every legitimate sender and stays within the evaluation limit.
