- The SPF specification (RFC 7208) limits SPF evaluation to a maximum of 10 DNS-querying lookups. Exceeding this limit causes an SPF PermError, which most mailbox providers treat as an SPF failure.
- Each
include:,a:,mx:,redirect=, andexists:mechanism counts as one DNS lookup. Nested includes within those mechanisms also count toward the limit. - The
ip4:,ip6:, andallmechanisms do NOT count toward the 10 lookup limit because they do not trigger DNS queries. - SPF flattening (replacing include mechanisms with direct IP addresses) is the most common fix, but it requires ongoing maintenance as provider IPs change.
- Subdomain delegation (moving different sending services to separate subdomains) is the most scalable long-term solution for organizations using many email services.
If you are seeing "SPF PermError: too many DNS lookups" in your email headers or authentication reports, your SPF record has exceeded the 10 DNS lookup limit defined in the SPF specification. This is not a warning; it is a failure. When SPF returns a PermError, most receiving mail servers treat it the same as an SPF fail, which means your emails may be rejected or routed to spam.
This problem has become increasingly common as businesses adopt more SaaS tools that send email: your ESP, CRM, helpdesk, marketing automation, transactional email provider, and billing system each add one or more include: entries to your SPF record. Three or four services can easily push you over the limit once you account for nested lookups.
This guide explains exactly how SPF lookups work, how to count yours, and five proven methods to get back under the limit without breaking email delivery.
Why the 10 Lookup Limit Exists
The 10 lookup limit was defined in RFC 7208 Section 4.6.4 for two practical reasons:
- DNS performance: Each SPF lookup requires a DNS query. When a receiving server processes incoming email, it evaluates the sender's SPF record in real time. Too many lookups slow down mail processing and put unnecessary load on DNS infrastructure.
- Denial of service prevention: Without a limit, an attacker could craft SPF records with circular references or deeply nested includes that overwhelm DNS servers. The 10 lookup cap prevents this abuse vector.
The limit was set when organizations used far fewer email services. Today, it is common for companies to use 10, 15, or even 20+ platforms that send email on their behalf, making the limit a real operational constraint.
What Counts Toward the 10 Lookup Limit
Not all SPF mechanisms consume DNS lookups. Understanding which mechanisms count and which do not is essential for optimizing your record.
Mechanisms That DO Count (DNS-Querying)
| Mechanism | Lookups Used | Example |
|---|---|---|
include: | 1 + any nested lookups in the included record | include:_spf.google.com |
a or a: | 1 | a:mail.example.com |
mx or mx: | 1 (plus 1 per MX record returned for A lookups) | mx |
redirect= | 1 | redirect=_spf.example.com |
exists: | 1 | exists:%{i}.spf.example.com |
Mechanisms That Do NOT Count
| Mechanism | Why It Does Not Count | Example |
|---|---|---|
ip4: | Specifies an IP address directly; no DNS query needed | ip4:192.168.1.0/24 |
ip6: | Specifies an IPv6 address directly; no DNS query needed | ip6:2001:db8::/32 |
all | A catch-all directive; no DNS query needed | ~all or -all |
Important: Nested lookups count toward the total. If include:_spf.google.com itself contains 3 more include: statements, those all count against your 10 lookup budget. A single top-level include from a major provider can consume 3-5 lookups from your total. Always check the full chain, not just your top-level record.
How to Count Your SPF Lookups
The easiest way to check your current lookup count is to use an SPF checker tool that recursively resolves your entire SPF record chain and reports the total number of DNS lookups.
For a manual count, follow this process:
- Look up your domain's SPF TXT record using
dig TXT yourdomain.comor an online DNS tool. - Count every
include:,a:,mx:,redirect=, andexists:mechanism. Each is 1 lookup. - For each
include:, look up THAT domain's SPF record and repeat the counting process. - Add up all lookups across the entire chain. If the total exceeds 10, you have a PermError.
Example: Counting a Real SPF Record
v=spf1 include:_spf.google.com include:sendgrid.net include:servers.mcsv.net include:spf.mandrillapp.com include:mail.zendesk.com mx ~allAt first glance, this has 5 include: statements plus 1 mx mechanism = 6 top-level lookups. But the nested lookups change the picture dramatically:
_spf.google.comchains to 3 additional includes = 4 total lookupssendgrid.net= 1 lookup (just IP addresses inside)servers.mcsv.netchains to 1 additional include = 2 total lookupsspf.mandrillapp.com= 1 lookupmail.zendesk.comchains to 1 additional include = 2 total lookupsmx= 1 lookup (plus A record lookups for each MX)
Total: approximately 11-13 lookups, which exceeds the limit and triggers a PermError.
What Happens When You Exceed the Limit
When a receiving mail server evaluates your SPF record and the lookup count exceeds 10, the evaluation stops immediately and returns a PermError result. This has cascading consequences:
- SPF fails: The PermError is treated as an SPF failure by most mailbox providers.
- DMARC interprets it as a fail: DMARC treats an SPF PermError as an SPF failure for alignment purposes. If DKIM also fails or is not configured, DMARC fails entirely.
- Emails get blocked or filtered: With both SPF and potentially DMARC failing, your messages may be rejected with a 550 error or silently routed to spam.
- The failure is random and partial: Because SPF evaluation stops at the 10th lookup, any services authorized AFTER the 10th lookup will fail even though they are legitimately listed in your record. This creates intermittent, hard-to-diagnose delivery failures.
Warning: If you have enforced DMARC (p=quarantine or p=reject) and your SPF record exceeds the 10 lookup limit, legitimate business email can be blocked even though the sending service is technically listed in your SPF record. The PermError causes SPF to fail before the evaluation reaches that service.
Five Ways to Fix SPF Too Many Lookups
1. Remove Unused or Redundant Includes
The simplest first step is auditing your SPF record for services you no longer use. It is common to find includes for ESPs you switched away from, tools you cancelled, or test services that were never removed from DNS.
How to do it: List every include: in your SPF record. For each one, verify whether that service still actively sends email for your domain. Remove any that are no longer in use. Also check if multiple includes overlap (some ESPs share IP ranges).
2. SPF Flattening (Replace Includes with IP Addresses)
SPF flattening is the process of resolving each include: mechanism to its underlying IP addresses and replacing the include with direct ip4: and ip6: entries. Since IP mechanisms do not count toward the lookup limit, this dramatically reduces your lookup count.
Before flattening:
v=spf1 include:_spf.google.com include:sendgrid.net ~all
(Uses 5+ lookups)After flattening:
v=spf1 ip4:209.85.128.0/17 ip4:74.125.0.0/16 ip4:167.89.0.0/17 ~all
(Uses 0 lookups)SPF flattening has a critical downside: IP addresses change. If your ESP adds or changes their sending IP ranges and you have hardcoded the old IPs, your SPF will silently stop authorizing their new servers. You must monitor for IP changes and update your flattened record regularly, or use an automated flattening service that handles this for you.
3. Subdomain Delegation
Instead of cramming all your sending services into a single domain's SPF record, delegate different email streams to separate subdomains. Each subdomain gets its own independent SPF record with its own 10 lookup budget.
Example:
example.com: v=spf1 include:_spf.google.com ~all (corporate email)
mail.example.com: v=spf1 include:sendgrid.net ~all (transactional)
news.example.com: v=spf1 include:servers.mcsv.net ~all (marketing)
help.example.com: v=spf1 include:mail.zendesk.com ~all (support)This approach aligns perfectly with an email subdomain strategy that isolates reputation across different email streams. Each subdomain stays well under the 10 lookup limit while authorizing only the services it actually uses.
4. Use SPF Macros
SPF macros are an advanced feature defined in the SPF specification that allows dynamic SPF evaluation. Instead of listing all authorized IPs statically, macros can construct DNS queries on the fly based on variables like the sender's IP address.
For example, the exists: mechanism with macros can check whether a sending IP is authorized by querying a specially structured DNS zone you control:
v=spf1 exists:%{i}._spf.example.com ~allThis uses only 1 DNS lookup regardless of how many IPs you authorize, because the exists check returns a simple pass/fail per IP.
Caution: SPF macros are technically complex to implement and manage. They require you to maintain DNS zones with A records for every authorized IP. This approach is best suited for organizations with dedicated DNS infrastructure and the expertise to manage it.
5. Optimize the Include Chain
Some services offer multiple include options. Check if a provider has a single, consolidated include that covers all their sending IPs rather than multiple includes for different products. Also check whether any of your services handle SPF authentication through their own subdomain (via a custom Return-Path), which would mean you do not need to include their SPF at all on your root domain.
Example: Many transactional email services (like SendGrid, Mailgun, Postmark) authenticate SPF using a custom Return-Path subdomain. If your service sends email with a Return-Path like bounce.yourdomain.com and that subdomain has its own SPF record, the SPF check happens against that subdomain, not your root domain. In this case, you can remove the service's include from your root domain's SPF record.
SPF checks are evaluated against the domain in the Return-Path (envelope sender), not the From header domain. Many ESPs use their own subdomain or a custom subdomain for the Return-Path, which means SPF for your root domain may not even be relevant for those sends. Always check the Return-Path in your email headers to understand which domain is being evaluated for SPF.
Which Fix Should You Use?
| Method | Complexity | Scalability | Maintenance | Best For |
|---|---|---|---|---|
| Remove unused includes | Low | Limited | None | Quick wins; any organization |
| SPF flattening | Medium | Moderate | High (IPs change) | Small-medium organizations with 4-8 services |
| Subdomain delegation | Medium | High | Low | Organizations with distinct email streams |
| SPF macros | High | Very High | Medium | Enterprise with dedicated DNS infrastructure |
| Optimize include chain | Low-Medium | Moderate | Low | Quick optimization alongside other methods |
For most organizations, the recommended approach is a combination: first remove unused includes (immediate relief), then implement subdomain delegation for long-term scalability, and flatten any remaining includes that cannot be moved to subdomains.
Common Mistakes to Avoid
Publishing Multiple SPF Records
A domain must have exactly one SPF TXT record. If you have two v=spf1 records on the same domain, SPF evaluation returns a PermError regardless of lookup count. Consolidate all your mechanisms into a single record.
Using the mx Mechanism Carelessly
The mx mechanism costs at least 1 lookup, plus additional A record lookups for each MX record returned. If your domain has 3 MX records, the mx mechanism could consume 4 lookups by itself. Replace it with direct ip4: entries for your mail server IPs when possible.
Forgetting About the "void lookup" Limit
RFC 7208 also defines a limit of 2 "void lookups" (DNS queries that return no records). Exceeding this causes a PermError. This can happen when an include points to a domain that has been decommissioned or has no SPF record published.
Frequently Asked Questions
The SPF specification (RFC 7208) mandates that during SPF evaluation, no more than 10 DNS-querying mechanisms can be processed. This includes all include:, a:, mx:, redirect=, and exists: mechanisms, including those nested within included records. Exceeding this limit causes the evaluation to abort with a PermError, which is treated as an authentication failure.
No. The ip4: and ip6: mechanisms do not count toward the 10 DNS lookup limit because they specify IP addresses directly and do not require any DNS queries to evaluate. This is why SPF flattening (replacing include mechanisms with direct IP addresses) is an effective way to reduce lookup count.
DMARC interprets an SPF PermError as an SPF failure. If your DMARC policy relies on SPF alignment and SPF returns PermError, DMARC will consider SPF as "fail" for that message. If DKIM also fails or is not configured, the overall DMARC result will be a fail, potentially causing your email to be quarantined or rejected depending on your DMARC policy.
SPF flattening is technically effective, but it requires ongoing maintenance. When you replace dynamic include mechanisms with static IP addresses, you lose the ability to automatically pick up IP changes from your email service providers. If a provider changes their sending IPs and you do not update your flattened record, legitimate email from that provider will fail SPF. Automated flattening services that monitor for changes and update records automatically mitigate this risk.
Not in a single domain's SPF record using include mechanisms alone. However, you can authorize virtually unlimited services by combining strategies: use subdomain delegation to spread services across multiple subdomains (each with their own 10 lookup budget), flatten some includes to ip4/ip6 entries, or use SPF macros. The subdomain approach is the most scalable and maintainable option for organizations with many sending services.