How to Validate Your SPF Record Doesn't Exceed the 10-Lookup Limit

Validating your Sender Policy Framework (SPF) record to ensure it does not exceed the mandatory 10-lookup limit is critical for preventing your outbound emails from landing in spam folders. When a receiving mail server processes an incoming message, it evaluates the domain's SPF record to verify that the sending IP address is authorized; however, if your record triggers more than 10 DNS lookup mechanisms, the evaluation fails due to a built-in recursion limit. To catch these issues before they impact your deliverability, you can use the Domain Checker to quickly audit your DNS infrastructure and review your active records.

Understanding the SPF 10-Lookup Limit

The SPF specification (RFC 7208) restricts receivers to a maximum of 10 DNS lookups during the evaluation of a single SPF record. This restriction exists to protect receiving mail transfer agents (MTAs) from denial-of-service (DoS) amplification attacks, such as recursive loops or excessively heavy database queries.

Every time your SPF record references an external mechanism that requires a separate DNS query, your lookup counter increases by one. If the counter reaches 11, the evaluation immediately terminates with a PermError (Permanent Error). When a PermError occurs, the receiving mail server usually treats your message as unauthenticated, severely damaging your domain reputation and sender score.

Which Mechanisms Count Toward the Limit?

Not all SPF mechanisms consume a lookup. You must understand the difference between mechanisms that require network queries and those that evaluate locally.

• Mechanisms that count (1 lookup each): include, a, mx, ptr (deprecated but counts if used), and exists.
• Mechanisms that do not count (0 lookups): ip4, ip6, all, and the record modifiers redirect and exp.

It is vital to note that nested includes compound the problem. If your main record has an include:spf.example.com, and that secondary record contains three more include statements, you have already consumed 4 lookups from your total allowance.

How to Count and Validate Your SPF Lookups

Manual counting is prone to human error, especially when third-party services like email marketing platforms, customer support software, and transactional delivery tools constantly update their own underlying SPF infrastructure. You should use a combination of command-line tools and web-based verification to audit your domain.

Step 1: Retrieve Your Current TXT Record

First, query your DNS provider to view your exact SPF TXT record string. Open your terminal or command prompt and run a standard DNS query using dig or nslookup.

dig +short TXT example.com

Sample output:

"v=spf1 include:_spf.google.com include:mail.zendesk.com ip4:192.0.2.0/24 ~all"

In this sample output, we see:

1. include:_spf.google.com (1 lookup)
2. include:mail.zendesk.com (1 lookup)
3. ip4:192.0.2.0/24 (0 lookups)
4. all (0 lookups) Total explicit lookups in the root record = 2. However, to truly validate your configuration, you must also expand _spf.google.com and mail.zendesk.com to check how many nested lookups they contain.

Step 2: Use PowerShell on Windows (Alternative)

If you are using Windows and do not have dig installed, you can use PowerShell to query your TXT records.

Resolve-DnsName -Name example.com -Type TXT

Step 3: Recursively Expand Includes

To ensure you do not exceed the 10-lookup limit, perform a lookup on each included domain separately. For instance, check Google's SPF record:

dig +short TXT _spf.google.com

Sample output:

"v=spf1 include:_netblocks.google.com include:_netblocks2.google.com include:_netblocks3.google.com ~all"

Notice that Google's record contains three more include mechanisms. You must continue tracing every branch until you reach only IP addresses (ip4 or ip6) and terminal directives (all). If the cumulative tree exceeds 10, your record is invalid.

Common Mistakes and How to Fix Them

Even experienced system administrators make mistakes when structuring enterprise DNS records. Recognizing these pitfalls saves hours of troubleshooting.

Mistake 1: Excessive Use of the mx and a Mechanisms

Using mx causes the receiving server to look up all mail exchanger records associated with your domain and then perform a forward lookup on every single one of those IP addresses. If you have five backup mail servers, mx can quickly consume multiple lookups.

• The Fix: Replace mx and a mechanisms with explicit ip4 or ip6 ranges whenever your mail server IPs are static.

Mistake 2: Leaving Stale Third-Party Includes

When you stop using an email marketing platform or CRM, administrators often forget to remove that platform's include statement from their SPF record. Over time, these stale entries accumulate and push you past the 10-lookup limit.

• The Fix: Conduct a quarterly audit of all SaaS tools connected to your domain. Remove any provider you no longer actively use for sending mail.

Mistake 3: Creating Nested Macro Loops

Some advanced administrators attempt to bypass the limit by using redirect modifiers chained across multiple domains. If Domain A redirects to Domain B, and Domain B includes Domain C, tracking becomes opaque and prone to lookup termination errors.

• The Fix: Flatten your SPF record. SPF flattening is the process of resolving all nested includes down to their ultimate IP address blocks and publishing them as a single static list of ip4 and ip6 entries.

Step-by-Step SPF Flattening Example

If your organization relies heavily on multiple SaaS vendors, exceeding the 10-lookup limit is almost guaranteed. Flattening solves this by removing all include statements and replacing them with the actual IP blocks.

1. Audit all vendors: List every service that sends email on your behalf (e.g., Google Workspace, Zendesk, Salesforce).
2. Resolve IPs: Query each vendor's include chain to extract their current CIDR blocks (e.g., 192.0.2.0/24, 2001:db8::/32).
3. Build a flat record: Combine these IP blocks into a single comprehensive TXT record.

v=spf1 ip4:192.0.2.0/24 ip4:198.51.100.0/24 ip6:2001:db8::/32 ~all

Warning: When you flatten an SPF record, you lose the benefit of automatic IP updates by vendors. If Google or Zendesk changes their IP infrastructure, your flattened record will not update automatically. You must set up automated monitoring to refresh your flat SPF records periodically.

Quick Checklist for SPF Validation

• Query your domain's root TXT record using dig or an online lookup tool.
• Count all include, a, mx, and exists mechanisms in the root record.
• Recursively query every nested include domain to count its child mechanisms.
• Ensure the total sum of all DNS lookups across the entire evaluation tree is strictly 10 or fewer.
• Replace dynamic mx mechanisms with static ip4/ip6 blocks if you are close to the limit.
• Test your outbound mail delivery using mail-tester tools to confirm zero PermError statuses.