What the SPF 10 DNS lookup limit actually means
SPF (Sender Policy Framework) lets you publish, in DNS, which servers are allowed to send email on behalf of a domain. When a receiving mail server checks SPF for an incoming message, it fetches your domain’s SPF record and then performs additional DNS queries to evaluate the mechanisms inside that record.
A key technical constraint is easy to miss: during SPF evaluation, a receiver can perform a maximum of 10 DNS lookups. If SPF evaluation requires more than 10, the check typically results in a PermError (permanent error). PermError doesn’t necessarily mean your SPF record is “wrong”; it often means the receiver cannot evaluate it safely within SPF’s required limits. In practice, that can hurt deliverability: some systems may reject the message, while others may increase spam scoring or treat the authentication result as unreliable.
This issue is common in organizations that send mail from multiple sources—cloud email, marketing platforms, ticketing tools, CRMs, billing systems, website servers, and so on. Each tool often adds an include to SPF, and include chains can quickly push you over the lookup budget.
Which SPF mechanisms count toward the limit?
Not everything inside an SPF record consumes a lookup. The 10-lookup limit applies to specific mechanisms that require DNS queries during evaluation, most notably:
- include: Pulls in another domain’s SPF policy. Each include typically costs at least one DNS lookup—and the included policy may contain more includes.
- a and mx: Resolve A records or MX records and can consume lookups.
- exists: Performs a DNS-based conditional check, consuming a lookup.
- redirect=: Redirects evaluation to another domain’s SPF record, consuming a lookup.
Mechanisms like ip4 and ip6 do not require DNS queries because the IP ranges are explicitly listed. That’s why many SPF simplification efforts aim to reduce lookups (includes, mx, a, redirect, exists) and rely more on direct IP entries where appropriate.
What happens when you exceed 10 lookups?
When the receiver hits the lookup limit, SPF evaluation can’t complete. Common real-world symptoms include:
- Bounce messages or mail logs mentioning PermError
- Errors like “too many DNS lookups” or similar wording
- Inconsistent results across recipients (delivered to some providers, spammed or rejected by others)
- A sudden deliverability drop after adding a new sending service
At this point, the problem is less about authorization and more about evaluation reliability. The fix is to restructure SPF so it stays within SPF’s technical constraints.
Why include chains get out of hand
Most companies grow their SPF record incrementally. A marketing tool asks you to add an include. A support platform asks for another include. A cloud service adds yet another. Meanwhile, those vendors’ SPF records may include additional domains. You may see only three includes in your own record, but the total evaluation can trigger a dozen lookups once the chain is expanded.
Typical causes of avoidable SPF bloat:
- Adding multiple includes for the same service due to outdated internal notes or changing vendor documentation
- Leaving legacy providers in SPF after migrations
- Using mx or a “just in case,” even when you don’t send from those hosts
- Publishing multiple SPF TXT records (SPF should be a single record; multiple records can break evaluation)
A practical SPF audit workflow
1) Inventory every outbound mail source
Start by listing where your organization sends email from. This usually includes user mailboxes via authenticated SMTP submission, website/application servers, marketing platforms, monitoring systems, and devices like multifunction printers.
Your goal is to identify what is actually sending as your domain today. Removing unused sources from SPF is often the fastest win.
2) Read your current SPF record like a policy document
Most SPF records look like “v=spf1 … -all”. Write down every lookup-consuming mechanism: include, a, mx, exists, and redirect. Also note the all-mechanism qualifier:
- -all is strict (unauthorized sources fail)
- ~all is softer (softfail)
This article isn’t about choosing -all vs ~all; the key point is that your record must be evaluatable under the lookup limit.
3) Estimate your real lookup budget
Counting includes in your SPF record is not enough. You must account for what those includes pull in. A single include can expand into several additional lookups depending on how that provider structures their SPF. The “real” lookup count is the total across the entire expanded chain.
What SPF flattening is—and when it’s worth considering
SPF flattening is the practice of resolving include chains and publishing the resulting IP ranges directly in your SPF record (using ip4/ip6). The goal is to reduce DNS lookups by replacing lookup-heavy includes with explicit IP entries.
Flattening is usually considered when:
- You are already exceeding, or are very close to, the 10-lookup limit
- You must support multiple sending services and cannot reduce includes enough
- You see SPF PermError-related deliverability problems
However, flattening is not a “set it and forget it” solution. It introduces ongoing operational responsibilities.
Pros of flattening
- Fewer lookups, lower risk of SPF PermError
- More deterministic SPF evaluation
- Less dependence on long include chains that change outside your control
Cons and operational risks
- Vendor IP ranges can change, and your flattened SPF can become outdated
- Missing or incorrect IP ranges can cause legitimate mail to fail SPF
- Your SPF record can become very long (be mindful of DNS TXT size limits and splitting behavior)
Because of these risks, many teams treat flattening as a managed process with periodic review, rather than a one-time cleanup.
Simpler fixes to try before flattening
In many environments, you can get under the lookup limit without flattening:
- Remove unused includes: Old platforms frequently linger in SPF long after they’re retired.
- Deduplicate providers: If the same vendor appears multiple times, you may only need one include.
- Question mx/a mechanisms: If you do not send mail directly from your MX hosts or A-record hosts, these may be unnecessary.
- Split sending domains: Using a subdomain for marketing or automated traffic can simplify the main domain’s SPF and reduce blast radius when changes are needed.
Change management: avoiding disruption
SPF changes are DNS changes, so propagation takes time. A few practical habits make updates safer:
- DNS TTL planning: Lower TTL ahead of major edits, then raise it again once stable, so you can roll adjustments out more predictably.
- Validate critical flows: Test the most important senders (executives, billing, support, automated systems) after changes.
- Document intent: Keep an internal note stating why each include or IP block exists and which system depends on it.
Don’t treat SPF in isolation: SPF, DKIM, and DMARC
SPF is only one part of modern email authentication. If you use DMARC, alignment and DKIM signatures matter as well. When SPF produces a PermError, a correctly configured and aligned DKIM signature may still allow DMARC to pass in some scenarios. The practical takeaway is that SPF cleanup should be coordinated with DKIM/DMARC governance rather than handled as a standalone tweak.
Quick checklist
- Do you have exactly one SPF TXT record?
- Have you removed obsolete includes and unnecessary mx/a mechanisms?
- Is the total DNS lookup count under 10 when the chain is expanded?
- Did you test the key outbound mail streams after the update?
- Is the SPF record documented so future changes don’t reintroduce bloat?
A practical note for MX1Mail customers
Most SPF lookup-limit incidents are caused by gradual complexity rather than a single bad change. If you’re managing business email on MX1Mail, it’s worth building a routine around sender inventory, controlled DNS changes, and periodic authentication review. That discipline helps keep SPF evaluatable, reduces the chance of PermError surprises, and supports stable long-term deliverability as your organization adds new tools and workflows.