How do you fix an SPF record that exceeds the DNS lookup limit?

To fix an SPF record that exceeds the DNS lookup limit, you need to reduce the number of mechanisms that trigger DNS lookups — either by removing unused include statements, consolidating sending sources, or using SPF flattening to replace lookup-heavy mechanisms with their resolved IP addresses. The 10-lookup limit is a hard constraint defined in the SPF specification, and exceeding it causes authentication to fail regardless of how well the rest of your email setup is configured. The sections below walk through why the limit exists, what breaks when you exceed it, and the most effective ways to bring your record back into compliance.

Why does the SPF 10-lookup limit exist?

The SPF 10-lookup limit exists to protect the DNS infrastructure from abuse. When a receiving mail server checks an SPF record, it must resolve each mechanism that references an external domain — such as include, a, mx, and redirect — by making additional DNS queries. Without a cap, a maliciously crafted or poorly maintained SPF record could force receiving servers to make dozens or hundreds of DNS queries, creating a vector for denial-of-service attacks and slowing down mail processing globally.

The limit is defined in RFC 7208, the authoritative specification for SPF. It sets the maximum number of DNS-querying mechanisms at 10 per SPF evaluation. This is not a soft recommendation — it is a strict rule. If a receiving server encounters more than 10 lookups while evaluating your record, it is permitted (and often required) to return a PermError, which effectively means your SPF check fails permanently rather than temporarily.

The limit has remained at 10 for many years, but the complexity of modern email sending environments has made it increasingly easy to hit. Organizations now routinely send through multiple third-party services — marketing platforms, transactional email providers, CRM tools, and support systems — each of which adds its own include statement and associated lookups to the SPF record.

What happens when an SPF record exceeds 10 DNS lookups?

When your SPF record exceeds 10 DNS lookups, receiving mail servers return a PermError result for SPF evaluation. This is treated as an authentication failure, meaning email sent from your domain does not pass SPF. Depending on your DMARC policy and the receiving server’s configuration, this can lead to messages being rejected, quarantined, or delivered without authentication alignment.

The practical consequences vary depending on how aggressively receiving servers enforce the limit, but the risks are significant:

• SPF authentication failures across a portion or all of your outbound email
• DMARC misalignment if SPF was your primary alignment mechanism and it now fails
• Increased spam folder placement as mailbox providers lose confidence in your sender identity
• Deliverability degradation that can be difficult to diagnose because the failure happens silently at the receiving end
• Rejection at strict receivers that treat PermError as a hard fail

One of the more frustrating aspects of this problem is that it often develops gradually. You add a new email service, which adds one more include, and the record tips over the limit without anyone noticing until deliverability metrics start declining.

How do you count the DNS lookups in your SPF record?

To count the DNS lookups in your SPF record, retrieve your current SPF TXT record from DNS and count every mechanism that requires a DNS query to resolve: include, a, mx, ptr, exists, and redirect. Each one counts as one lookup, and each include may itself contain additional nested lookups that also count toward your total.

Here is the process step by step:

1. Retrieve your SPF record using a DNS lookup tool or by running nslookup -type=TXT yourdomain.com in a terminal.
2. Identify all lookup-triggering mechanisms in the top-level record: count each include:, a, mx, ptr, exists, and redirect=.
3. Follow each include to its referenced domain and count the mechanisms within that record too — these nested lookups all count toward your total of 10.
4. Repeat recursively for any further nested includes until you have a full picture of the lookup chain.
5. Sum the total across all levels. If the number exceeds 10, your record is over the limit.

Mechanisms that do not trigger DNS lookups include ip4: and ip6: — these reference IP addresses directly and do not count toward the limit. Using these mechanisms is one of the key strategies for reducing your lookup count.

Several free online SPF analysis tools can automate this counting process and visualize the full lookup tree, which is especially useful when your record includes multiple nested includes from third-party services.

What are the main methods for fixing an SPF record over the limit?

The main methods for fixing an SPF record that exceeds 10 DNS lookups are: removing unused include statements, consolidating sending sources, replacing lookup-heavy mechanisms with direct IP references, and using SPF flattening. Most organizations need a combination of these approaches rather than a single fix.

Remove unused or redundant includes

Start by auditing every include in your SPF record and confirming that each one represents an active sending source. Over time, organizations accumulate includes from services they no longer use — old ESPs, deprecated integrations, or platforms that were replaced. Removing these is the simplest and most immediate fix. Check your email headers and sending logs to verify which services are actively sending on your behalf before removing anything.

Replace includes with direct IP addresses

For sending sources whose IP ranges are stable and well-documented, you can replace the include: mechanism with direct ip4: or ip6: entries. These do not count toward the 10-lookup limit. The trade-off is that you must keep these IP entries updated manually if the sending service changes its infrastructure — something that include mechanisms handle automatically.

Consolidate sending through fewer services

If your organization sends through many different platforms, consolidating to fewer services reduces the number of includes needed. This is a longer-term operational change but often has benefits beyond SPF compliance, including simpler email infrastructure and a more consistent sending reputation.

What is SPF flattening and when should you use it?

SPF flattening is the process of resolving all the nested DNS lookups in an SPF record into their final IP addresses and rewriting the record using only ip4: and ip6: entries. Because IP address mechanisms do not count toward the 10-lookup limit, a fully flattened SPF record will always pass the lookup count check regardless of how many sending sources it covers.

Flattening is most useful when you genuinely need many sending services and cannot reduce the number of includes through auditing or consolidation. It is a practical solution for large enterprises, high-volume senders, or organizations using many specialized email tools simultaneously.

However, SPF flattening comes with an important maintenance requirement. When a third-party sending service changes its IP addresses — which happens routinely as providers update their infrastructure — your flattened record becomes outdated. If those new IPs are not in your SPF record, email sent from them will fail authentication. This means a flattened SPF record requires ongoing monitoring and updates, either manually or through an automated SPF management tool.

Use SPF flattening when you have exhausted simpler options and need a reliable way to stay within the lookup limit at scale. Treat it as a solution that requires maintenance, not a one-time fix.

How do SPF, DKIM, and DMARC work together after fixing the record?

After fixing your SPF record, SPF works alongside DKIM and DMARC to provide layered email authentication. SPF verifies that the sending server’s IP address is authorized to send on behalf of your domain. DKIM adds a cryptographic signature to the message itself. DMARC ties both together by requiring at least one of them to align with the From header domain before a message passes authentication.

Fixing your SPF record is an important step, but it is most effective when all three protocols are properly configured and aligned:

• SPF alignment requires the domain in the Return-Path (envelope sender) to match the From domain. A correctly structured SPF record that stays within the lookup limit enables this alignment to pass consistently.
• DKIM alignment requires the d= domain in the DKIM signature to match the From domain. DKIM is not affected by the SPF lookup limit, making it a valuable independent authentication layer.
• DMARC policy enforcement depends on at least one of SPF or DKIM passing alignment. If your SPF record was exceeding the lookup limit and failing, your DMARC pass rate would have suffered — fixing SPF directly improves DMARC compliance.

A common best practice is to ensure DKIM is configured correctly for all major sending sources so that even if SPF encounters edge cases, DMARC can still pass via DKIM alignment. This redundancy makes your overall authentication setup more resilient. Once your SPF record is back within the 10-lookup limit, monitoring your DMARC aggregate reports will quickly confirm whether alignment is improving across your sending streams.

How Email Industries can help you fix your SPF configuration

Diagnosing and resolving SPF lookup issues requires a clear picture of your entire sending infrastructure, and that is exactly the kind of work we specialize in at Email Industries. We help organizations untangle complex authentication problems, from over-limit SPF records to broken DMARC alignment, so that email reaches the inbox reliably. When we work with a client on SPF configuration, we typically cover:

• A full audit of the existing SPF record, including all nested includes and their lookup counts
• Identification of unused or redundant sending sources that can be safely removed
• Recommendations on whether flattening, consolidation, or direct IP replacement is the right approach for the specific environment
• Validation that the corrected SPF record aligns with DKIM and DMARC configuration
• Ongoing monitoring to catch future lookup creep before it becomes a deliverability problem

Our Deliverability Assurance Packages include authentication review and remediation as part of a broader deliverability strategy, and our full range of expertise is outlined on our Services page. If your SPF record is over the limit or you are not sure where your authentication stands, we would be glad to take a look — feel free to contact us and we can walk through it together.

Related Articles

• How do you troubleshoot a failed BIMI implementation?
• How do you get your brand logo displayed in email inboxes?
• How do you set up a DMARC policy for your domain?
• What happens if your DKIM setup is misconfigured?
• How do you add multiple senders to a single SPF record?
• What is DMARC and why do I need it?
• How do email advertising agencies handle underperforming campaigns?
• What data do you need to transfer during an email platform migration?
• When should you use a new domain for email migration?
• How does email volume ramp-up work during IP warming?
• How long does it take to see results from an email marketing services agency?
• Can email marketing services agencies integrate with existing CRM systems?
• How do email marketing agencies create campaign strategies?
• How do deliverability agencies differ from ESP support teams?
• How do delivery agencies handle international email regulations?