SPF Too Many DNS Lookups: The 10-Lookup Limit Explained

Your email deliverability lives or dies by a single number: ten. If a receiving mail server has to perform more than 10 DNS lookups to validate your SPF record, it stops. It doesn't matter if your IP address is valid or if you are a legitimate sender. The server returns an "SPF PermError: too many DNS lookups," treats your authentication as a failure, and likely shunts your message into the spam folder or rejects it entirely.

This 10-lookup limit is a hard-coded restriction in the SPF protocol (RFC 7208). It is the most common reason high-volume senders experience sudden, unexplained drops in inbox placement. As modern businesses stack more SaaS tools—marketing platforms, CRM systems, helpdesks, and HR portals—their SPF records bloat, quickly exceeding this invisible ceiling.

The Short Answer: What is the 10-Lookup Limit?

The SPF 10-lookup limit is a security mechanism that prevents a mail server from making more than 10 recursive DNS requests during a single SPF check. Mechanisms like include, a, mx, ptr, exists, and redirect each trigger at least one lookup. If the total count across all nested records exceeds 10, the validation fails with a Permanent Error (PermError).

Why the Limit Exists: Preventing DNS Amplification

The 10-lookup limit is not an arbitrary annoyance; it is a defense against Distributed Denial of Service (DDoS) attacks. Specifically, it prevents DNS amplification.

Without this limit, an attacker could create a malicious SPF record containing dozens of include statements pointing to other complex records. By sending a single email to a target server, the attacker would force that server to generate hundreds of DNS queries to verify the sender. This would effectively turn legitimate mail servers into "amplifiers" that could be used to overwhelm DNS infrastructure across the internet.

By enforcing a strict limit of 10, the protocol ensures that the computational and network cost of verifying an email remains low. While this protects the global DNS ecosystem, it places the burden of optimization squarely on the domain owner.

Which Mechanisms Count Toward the Limit?

To fix a "too many DNS lookups" error, you must distinguish between mechanisms that require a DNS query and those that are "free." You can verify your current count using our SPF record checker.

include

Label: This is the most common source of bloat. Every include statement triggers a lookup for the specified domain's SPF record. Crucially, if the included record contains its own include statements, those count toward your 10-lookup limit as well.

a

Label: This mechanism directs the mail server to look up the A (IPv4) or AAAA (IPv6) record for a specific domain. Each instance counts as one lookup.

mx

Label: This tells the server to find the Mail Exchange records for a domain and then resolve the IP addresses for those servers. Even if a domain has multiple MX records, the initial query for the list counts as one lookup. For a deeper dive into mail routing, see our guide on what is an MX record.

ptr

Label: This performs a reverse DNS lookup to match an IP address to a hostname. It is slow, unreliable, and deprecated by RFC 7208. It still counts toward the limit and should be removed from all modern records.

exists

Label: This is used for advanced, dynamic SPF configurations. It performs a DNS query to check for the existence of a specific host, counting as one lookup per use.

redirect

Label: This modifier points to a different domain to handle the SPF check entirely. The initial redirection to that new domain counts as one lookup.

Mechanisms That Are "Free"

The following mechanisms do not require additional DNS queries and are the key to staying under the limit:

ip4 and ip6

Label: These provide the literal IP address or CIDR range (e.g., ip4:192.0.2.1). Since the server already has the address, no DNS query is needed.

all

Label: This is a qualifier (usually -all or ~all) that determines the final result if no other mechanisms match. It never triggers a lookup.

The Math of Failure: How Lookups Multiply

The 10-lookup limit is recursive. This is where most administrators get caught. A record might look short on the surface but fail in practice because of what is hidden inside the third-party includes.

Consider a company using Google Workspace, Zendesk, and Mailchimp. Their record might look like this: v=spf1 include:_spf.google.com include:support.zendesk.com include:servers.mcsv.net -all

At first glance, that is only 3 lookups. However, the reality is different:

1. _spf.google.com resolves and contains three more includes: _netblocks.google.com, _netblocks2.google.com, and _netblocks3.google.com. That is 4 lookups total for Google alone.
2. support.zendesk.com might include another domain for its mail infrastructure, adding 2 more lookups.
3. servers.mcsv.net might include additional records, adding 2 more lookups.

In this scenario, three simple include statements have actually consumed 8 of the 10 available lookups. If the company adds one more service—like a CRM or a transactional email provider—they will likely hit 11 or 12 lookups, triggering a PermError.

Strategies to Resolve "Too Many DNS Lookups"

When you exceed the limit, you have four primary ways to fix the record. The right choice depends on your technical infrastructure and how often your third-party providers change their IP addresses.

1. The Audit and Purge

The simplest fix is often the most overlooked. Companies frequently switch from one marketing tool to another but forget to remove the old include from their DNS.

1. List every service currently in your SPF record.
2. Cross-reference this list with your current billing or IT stack.
3. Remove any include, a, or mx mechanisms for services no longer in use.
4. Consolidate multiple records if you find redundant entries.

2. Subdomain Delegation

This is the most professional and scalable solution. Instead of trying to fit every service into the SPF record of your root domain, delegate specific functions to subdomains.

1. Use marketing.best-tempmail.com for newsletters via Mailchimp.
2. Use support.best-tempmail.com for Zendesk.
3. Use the root domain only for primary corporate email (e.g., Google Workspace).

Each subdomain gets its own SPF record and its own 10-lookup limit. This isolates your mail streams and ensures that a change in your marketing stack cannot break your corporate email deliverability.

3. SPF Flattening

SPF flattening is the process of replacing include, a, and mx mechanisms with their literal ip4 and ip6 addresses.

1. Query the DNS for every domain in your include list.
2. Extract all the IP addresses used by those services.
3. Replace the include:example.com with ip4:1.2.3.4 ip4:5.6.7.8 ....

The Risk: SaaS providers like Microsoft and Google change their IP ranges frequently. If you "flatten" your record manually, your SPF will break the moment the provider moves to a new IP range. If you use flattening, you must use an automated service that monitors these providers and updates your DNS record in real-time.

4. Converting MX and A to IP Addresses

If your SPF record contains mx or a mechanisms pointing to your own servers, replace them with static IP addresses.

1. Identify the static IP of your web server or local mail server.
2. Replace a with ip4:your.static.ip.
3. Replace mx with the specific ip4 ranges of your mail servers. This saves at least one lookup per mechanism and is a "set it and forget it" fix for infrastructure you control.

The Relationship Between SPF, DKIM, and DMARC

The 10-lookup limit is strictly an SPF constraint. It does not apply to DKIM or DMARC records. However, because DMARC requires either SPF or DKIM to pass and align, an SPF PermError can lead to a DMARC failure.

If your SPF record is failing due to the lookup limit, your email can still pass DMARC if it has a valid DKIM signature. This is why modern email security relies on a "belt and braces" approach. You should never rely on SPF alone. For a complete setup guide, see our article on how to build a DMARC record.

Limitations of the SPF Protocol

Even with a perfectly optimized record, SPF has inherent flaws. It only validates the "Return-Path" address, which is the address used for bounce messages, not the "From" address visible to the user. This makes it easy for attackers to spoof the visible "From" header while still passing SPF.

Furthermore, SPF is notoriously fragile when it comes to email forwarding. When an email is forwarded, the forwarding server’s IP address will not be in the original sender's SPF record, causing a failure. These weaknesses are why the industry has shifted toward DMARC, which uses SPF and DKIM together to provide a more robust authentication framework.

Infrastructure Management at Best-TempMail

At Best-TempMail, we maintain a rigorous standard for email infrastructure. Whether you are using a disposable email for testing or utilizing our email tools for domain health checks, we ensure our own records are optimized.

Our internal systems use subdomain delegation to keep lookup counts low and deliverability high. For developers building their own platforms, we recommend monitoring SPF health as part of your standard CI/CD pipeline. A single added include from a new vendor can silently break your entire communication chain if not caught by an automated check.

Frequently Asked Questions

Does the "v=spf1" tag count as a lookup?

No. The version prefix is a string identifier and does not trigger a DNS query. Similarly, the all mechanism and IP-based mechanisms (ip4, ip6) are processed locally by the receiving server and do not count toward the 10-lookup limit.

What happens if I have exactly 10 lookups?

Your record will pass. The limit is "more than 10." However, running at exactly 10 is dangerous. If one of the services you include (like Google or Microsoft) updates their own SPF record to include an additional nested lookup, your record will instantly jump to 11 and start failing. Always aim for a buffer of at least 2-3 lookups.

Can I use multiple SPF records to get more lookups?

No. Publishing more than one SPF record for a single domain is a violation of the protocol. If a receiving server finds two TXT records starting with v=spf1, it will return a PermError immediately without checking either of them. You must consolidate all rules into one record.

Why did my SPF record start failing without me changing anything?

This is usually caused by "recursive bloat." You might include a third-party service that was previously using 2 lookups, but they updated their infrastructure and now use 4. Because their lookups count toward your total, their change can push you over the limit. This is the primary argument for using subdomains or automated flattening.

How do I check my current lookup count?

You should use a specialized SPF record checker. These tools simulate the recursive process of a mail server, "walking" through every include and providing a final tally of the DNS queries required to validate your domain.

Is the 10-lookup limit likely to increase in the future?

It is unlikely. The limit has been a standard part of the SPF specification for years. Increasing it would increase the risk of DNS amplification attacks globally. Instead of waiting for the protocol to change, the industry has moved toward DKIM and DMARC to handle the complexities that SPF cannot.

For a comprehensive look at your domain's health, refer to our check-spf-dkim-dmarc-2026-guide to ensure your authentication stack is fully optimized and compliant with modern standards.