Why the 10-Lookup Limit Exists: Protecting DNS Infrastructure
You've added all your email sources to SPF—Google Workspace, SendGrid, Mailchimp, your own web server, maybe a few others. Everything seems fine. Then you discover that some of your legitimate emails are failing SPF with a "PermError" (permanent error).
You've hit the SPF 10-DNS-lookup limit—one of the most common and frustrating SPF errors.
The limit is defined in RFC 7208, the official SPF specification. It states that the total number of DNS lookups required to evaluate an SPF record must not exceed 10. This includes lookups triggered by include, a, mx, exists, and redirect mechanisms.
Why Did the RFC Creators Impose This Limit?
The 10-lookup limit exists for two critical reasons:
- Denial of Service (DoS) Protection: Without a limit, an attacker could create a malicious SPF record with dozens of nested
includestatements. Each time a receiving server processed an email from that domain, it would be forced to perform dozens (or hundreds) of DNS lookups, potentially overwhelming DNS infrastructure. - Email Processing Performance: Large email providers like Gmail process billions of emails daily. If each email required 50+ DNS lookups, the computational and network cost would be astronomical. The 10-lookup limit ensures SPF evaluation remains efficient.
Unfortunately, the limit hasn't kept pace with modern email complexity. Many organizations now use 5-10 different email services, making it easy to exceed the limit even with legitimate configurations.
Which Mechanisms Count Toward the 10-Lookup Limit?
Not all SPF mechanisms consume DNS lookups. Understanding which do helps you design more efficient records.
Mechanisms That DO Count (Each Adds 1 Lookup)
include:Each include statement adds the DNS lookups from the included domain's SPF record. If the included record itself has 3 lookups, that include adds 3 lookups to your total.a:Performs a DNS lookup for the domain's A record. Counts as 1 lookup.mx:Performs DNS lookups for all MX records for the domain. Counts as 1 lookup per MX record (up to the MX record count).ptr:(Deprecated) Performs a reverse DNS lookup. Counts as 1 lookup.exists:Performs a DNS lookup for the specified domain. Counts as 1 lookup.redirect=Redirects evaluation to another domain's SPF record. Counts as 1 lookup plus the lookups in the redirected record.
Mechanisms That DO NOT Count (0 Lookups)
ip4:Direct IP address or CIDR range. No DNS lookup required.ip6:Direct IPv6 address or CIDR range. No DNS lookup required.allThe catch-all mechanism. No lookup.
The "Cascading Include" Problem
Here's where most organizations exceed the limit. Consider this scenario:
v=spf1 include:google.com include:sendgrid.net include:mailchimp.com include:zendesk.com ~all
At first glance, this looks like only 4 lookups. But each include triggers additional lookups:
include:google.commight resolve to 2 lookups internallyinclude:sendgrid.netmight add 2-3 lookupsinclude:mailchimp.commight add 2-3 lookupsinclude:zendesk.commight add 1-2 lookups
Total actual lookups: 7-10+. You've exceeded the limit without realizing it.
How to Check Your Current SPF Lookup Count
Before you can fix the limit violation, you need to know exactly how many lookups your current SPF record is consuming.
Method 1: Use Our SPF Checker (Recommended)
Our SPF Checker automatically:
- Fetches your domain's SPF record
- Resolves every include recursively
- Counts total DNS lookups
- Identifies which mechanisms are consuming lookups
- Highlights any lookups exceeding 10
- Provides specific recommendations for reducing lookups
Method 2: Manual Calculation (For Advanced Users)
You can manually calculate lookups using command-line tools:
# Query your SPF record
dig yourdomain.com TXT +short
# Then recursively query each include
dig _spf.google.com TXT +short
dig sendgrid.net TXT +short
Count 1 lookup for each include, a, mx, exists, or redirect mechanism encountered across all records.
Understanding the Output
When you use our tool, you'll see output like:
SPF Record: v=spf1 include:_spf.google.com include:sendgrid.net include:mailchimp.com ~all
Lookup Breakdown:
- include:_spf.google.com → 2 lookups
- include:sendgrid.net → 2 lookups
- include:mailchimp.com → 3 lookups
Total Lookups: 7/10 (within limit)
- OR -
Total Lookups: 12/10 (EXCEEDED LIMIT - PermError will occur)
How to Flatten and Solve the 10-Lookup Limit: Practical Strategies
Once you've confirmed you're exceeding the limit, use these strategies to reduce your lookup count. Start with the easiest fixes and escalate as needed.
Strategy 1: Remove Unused Includes (Easiest)
Review all the includes in your SPF record. Are all of them still necessary?
- Do you still use that email marketing platform you cancelled 6 months ago?
- Is that development server still sending email?
- Did you migrate from one provider to another but keep both includes?
Remove any includes for services you no longer use. This is the simplest way to reduce lookups.
Strategy 2: Replace Includes with IP4 Mechanisms Where Possible
Every include statement consumes at least 1 lookup. If you can replace an include with a direct IP address or CIDR range, you eliminate those lookups entirely.
Before (consumes 3 lookups):
include:mailgun.org (Mailgun's SPF includes multiple lookups)
After (0 lookups):
ip4:192.168.0.0/16 (If you know Mailgun's sending IP ranges)
Challenges with this approach:
- You need to know the provider's IP ranges (available in their documentation).
- Providers may change IP ranges without notice, breaking your SPF.
- Large providers use many IP ranges, making this impractical.
Strategy 3: Use SPF Macros for Subdomain Segmentation
Instead of one monolithic SPF record for your root domain, delegate SPF authority to subdomains.
Example:
# Root domain SPF (simple)
v=spf1 include:root.yourdomain.com -all
# marketing.yourdomain.com SPF
v=spf1 include:servers.mcsv.net include:sparkpost.com -all
# transactional.yourdomain.com SPF
v=spf1 include:sendgrid.net include:amazonses.com -all
# internal.yourdomain.com SPF
v=spf1 ip4:10.0.0.0/8 -all
Then, when sending email, use different subdomains in the MAIL FROM address for different purposes. This distributes the lookup load across multiple SPF records, none of which exceed the limit.
Strategy 4: Use SPF Flattening Services/Tools (Most Powerful)
SPF flattening (also called macro or expansion) is the process of resolving all includes recursively and generating a static list of IP addresses and ranges. This flat SPF record contains only ip4 and ip6 mechanisms—no includes, a, mx, or exists lookups.
How flattening works:
- A tool fetches your current SPF record.
- It resolves every include recursively.
- It collects all IP addresses and CIDR ranges from those includes.
- It generates a new SPF record containing only ip4 and ip6 mechanisms.
- You replace your existing SPF record with the flattened version.
Example flattened record:
v=spf1 ip4:64.233.160.0/19 ip4:66.102.0.0/20 ip4:74.125.0.0/16 ip4:108.177.8.0/21 ip4:173.194.0.0/16 ip4:209.85.128.0/17 ip4:216.58.192.0/19 ip4:192.178.0.0/15 ip6:2001:4860:4000::/36 ip6:2404:6800:4000::/36 ip6:2607:f8b0:4000::/36 ip6:2800:3f0:4000::/36 ip6:2a00:1450:4000::/36 ip6:2c0f:fb50:4000::/36 ~all
Flattening services include:
- AutoSPF: Free, simple tool for one-time flattening.
- SPF Toolbox's flattening tool: More advanced with validation.
- DMARC reporting services (e.g., Dmarcian, Postmark): Often include SPF flattening as a feature.
Advanced Solutions for Complex SPF Needs
For large enterprises with dozens of email sources, even flattening may not be sufficient. These advanced solutions address extreme cases.
Solution 1: Subdomain Per Service (The Scalable Architecture)
Instead of sending all email from yourdomain.com, use different subdomains for different purposes:
marketing.yourdomain.comfor marketing emailstransactional.yourdomain.comfor receipts/notificationssupport.yourdomain.comfor customer supportinternal.yourdomain.comfor employee emails
Each subdomain can have its own SPF record optimized for its specific services. This completely bypasses the 10-lookup limit because each subdomain's record is evaluated independently.
Implementation:
- Set up subdomains in your DNS (e.g.,
marketing). - Configure each subdomain's SPF record independently.
- Configure your email services to use the appropriate subdomain in their MAIL FROM address.
- Set up DKIM and DMARC for each subdomain.
The tradeoff: managing multiple subdomains adds complexity. However, for organizations sending email from 10+ services, this is often the only sustainable solution.
Solution 2: Cloud-Based SPF Hosting (Managed Flattening)
Several services offer dynamic SPF flattening. Instead of publishing includes in your SPF record, you publish a CNAME or TXT record that points to the service. The service maintains the flattened IP list and updates it automatically when providers change IP ranges.
How it works:
# Your DNS (simple)
yourdomain.com. IN TXT "v=spf1 include:spf.dmarcservice.com -all"
The service's SPF record (spf.dmarcservice.com) contains the flattened IP list and is updated automatically.
Solution 3: Transition to Subdomain Branding with DKIM Alignment
For the most complex scenarios, accept that SPF has limits and rely more heavily on DKIM. DMARC requires either SPF OR DKIM to pass. If DKIM passes and aligns, SPF failures don't matter.
This strategy:
- Set up DKIM signing for all your email sources (with your domain or subdomain).
- Create a DMARC policy that requires DKIM alignment but is lenient on SPF alignment.
- Keep a simple SPF record with only your most critical sending sources.
Preventing Future SPF Lookup Limit Violations
Once you've fixed your SPF record, implement these practices to avoid hitting the limit again.
1. Monitor Your Lookup Count Regularly
Set a calendar reminder to check your SPF lookup count every 3-6 months using our SPF Checker. Email providers change their IP ranges and include structures over time, which can increase your lookup count without any action on your part.
2. Audit Email Services Quarterly
Marketing departments love to sign up for new email tools. Maintain a spreadsheet of every service authorized to send email from your domain. Quarterly, ask each department if they still use each service. Remove includes for services no longer in use.
3. Use Subdomain Strategy for New Services
When adding a new email service, consider whether it should go on the root domain's SPF or on a dedicated subdomain. If your root domain's lookup count is already high (7+), default to a subdomain-based approach.
4. Prefer Providers with Efficient SPF Records
When evaluating email providers, check their SPF record complexity. Some providers use efficient 1-2 lookup records; others use nested includes that consume 3-5 lookups. Choose efficiently designed providers when possible.
