You add Google Workspace to your SPF record. Then you integrate with SendGrid. Later you set up Mailchimp. Before long, your SPF record looks like this:
v=spf1 include:_spf.google.com include:sendgrid.net include:servers.mcsv.net include:spf.protection.outlook.com include:_spf.salesforce.com ~all
Everything appears to work fine until email deliverability mysteriously degrades. Messages end up in spam folders. Some recipients report not receiving your email at all. Investigation reveals your SPF record exceeds the 10-lookup limit, causing SPF authentication to fail.
Understanding how SPF lookups accumulate and learning to optimize records without breaking authentication keeps email delivery reliable as your infrastructure grows.
How SPF Lookups Work
SPF (Sender Policy Framework) records specify which mail servers can send email on behalf of your domain. When receiving mail servers validate SPF, they process the record according to strict rules defined in RFC 7208.
The SPF specification imposes a hard limit of 10 DNS lookups during SPF evaluation. This limit exists to prevent SPF processing from creating excessive DNS query load and to limit the time spent on SPF validation.
Each SPF mechanism that requires a DNS query counts toward the limit:
- include:domain.com - Counts as 1 lookup, plus all lookups in the included record
- a:domain.com - Counts as 1 lookup
- mx:domain.com - Counts as 1 lookup (plus 1 for each MX record found, if multiple MX records exist)
- exists:domain.com - Counts as 1 lookup
- redirect=domain.com - Counts as 1 lookup, plus all lookups in the redirected record
- ip4:192.0.2.1 - No lookup required, just a direct IP match
- ip6:2001:db8::1 - No lookup required
- all mechanism - No lookup required
- The initial record itself - Doesn't count toward the limit
When you include another domain's SPF record, you're including all of its lookups too. If you include Google Workspace and Google's SPF record itself includes three other domains, you've consumed 4 lookups (1 for the include, plus 3 from Google's internal includes).
Counting Your Lookups
Before optimizing, you need to know where you stand. Count every mechanism that triggers DNS queries, following the chain through included records.
v=spf1 include:_spf.google.com include:sendgrid.net a:mail.example.com mx ~all
- include:_spf.google.com - 1 lookup
- Google's SPF includes multiple domains internally: approximately 3 lookups
- include:sendgrid.net - 1 lookup
- SendGrid's SPF includes one other domain: approximately 1 lookup
- a:mail.example.com - 1 lookup
- mx - 1 lookup (assumes one MX record; multiple MX records count individually)
This record approaches the limit with only three services. Adding one more third-party service likely pushes beyond 10 lookups.
Several online SPF validators automatically count lookups and show the include chain. These tools reveal exactly how each service's SPF record contributes to your total. Services like mxtoolbox.com, kitterman.com/spf/validate.html, and others provide detailed breakdowns.
Services sometimes change their SPF records, adding includes or mechanisms that increase lookup counts. Your SPF might be under the limit today but exceed it tomorrow if a service you include modifies their SPF structure. Regular monitoring catches these changes before they cause problems.
Why the Limit Exists and What Happens When You Exceed It
The reasoning behind 10 lookups:
Each DNS lookup adds latency to email processing. Receiving mail servers handle thousands or millions of messages. Without limits, malicious or poorly configured SPF records could cause denial-of-service conditions by forcing mail servers to perform hundreds of DNS lookups per message.
The 10-lookup limit represents a compromise between SPF's power and practical performance constraints.
What happens at 11 lookups:
When SPF evaluation exceeds 10 lookups, the specification requires the receiver to return a "PermError" (permanent error) result. This means SPF fails, not because your servers aren't authorized, but because the record is too complex to evaluate.
Impact on email delivery:
Different receiving servers handle SPF PermError differently:
- Strict servers reject the message entirely with a permanent error
- Moderate servers accept the message but mark it suspiciously, often sending to spam
- Lenient servers might ignore SPF entirely and rely on other authentication
The problem is unpredictability. Your email might deliver fine to some recipients while bouncing or going to spam for others, creating inconsistent and hard-to-diagnose delivery issues.
DMARC amplifies the problem:
If your domain has a DMARC policy set to p=quarantine or p=reject, and SPF fails due to exceeding lookup limits, DMARC enforcement can cause widespread email delivery failures even if DKIM passes.
Strategy 1: Replace Include with IP Ranges
The most effective optimization replaces include mechanisms with direct IP addresses or IP ranges.
Instead of include:service.com (which triggers DNS lookups), use ip4:192.0.2.0/24 (which triggers no lookups). This requires knowing the IP addresses or ranges the service uses for sending email.
v=spf1 include:mailprovider.com ~all
v=spf1 ip4:192.0.2.0/24 ip4:198.51.100.0/24 ~all
This reduces lookups from potentially 2-3 (depending on mailprovider.com's SPF) to zero.
Query the service's SPF record to discover their IP ranges:
Look for ip4 and ip6 mechanisms in their record. These are the ranges you can copy directly into your SPF record.
Example with Google Workspace:
Google's SPF includes several IP ranges. Instead of include:_spf.google.com, you could list their IP ranges directly. However, Google explicitly recommends against this because their IPs change. This illustrates a key tradeoff.
The tradeoff: Maintenance vs lookups:
Direct IP ranges save lookups but require maintenance. When services add or change IP addresses, your SPF record becomes outdated. Include mechanisms automatically pick up changes the service makes to their SPF.
Best candidates for IP replacement:
- Rarely change their sending infrastructure
- Document their IP ranges officially
- Send low-volume email on your behalf (so impact is limited if they do change IPs)
Major email providers like Google, Microsoft, or large sending services that frequently adjust their infrastructure. These services change IPs often enough that maintaining direct IP lists becomes burdensome and error-prone.
Strategy 2: Use Subdomain SPF Records
Breaking your SPF record across subdomains reduces lookups in the primary record while maintaining functionality.
Instead of including multiple services in your main domain's SPF record, create subdomain SPF records for specific use cases.
Main domain sends from your primary email provider:
example.com. TXT "v=spf1 include:_spf.google.com ~all"
Marketing subdomain sends from email marketing platform:
marketing.example.com. TXT "v=spf1 include:servers.mcsv.net ~all"
Notifications subdomain sends from transactional email service:
notify.example.com. TXT "v=spf1 include:sendgrid.net ~all"
Each subdomain has its own independent 10-lookup limit. The main domain's record stays simple and well under the limit while subdomains handle specific sending scenarios.
Implementation requirements:
User experience considerations:
Sending from subdomains affects how recipients see your email. "[email protected]" looks less clean than "[email protected]". Balance technical requirements with user experience and brand consistency. Subdomains inherit their parent domain's DMARC policy by default unless they have their own DMARC record. If your main domain has a strict DMARC policy, ensure subdomain SPF records are correctly configured or create subdomain-specific DMARC policies.
Strategy 3: Consolidate Email Services
The simplest way to stay under 10 lookups is sending all email through fewer services.
List every service currently authorized to send email on your behalf:
- Primary email provider (Google Workspace, Microsoft 365)
- Marketing platforms (Mailchimp, SendGrid, Constant Contact)
- CRM systems (Salesforce, HubSpot)
- Notification services (Twilio, Amazon SES)
- Support ticket systems (Zendesk, Intercom)
Identify consolidation opportunities:
Can multiple use cases be served by a single platform? Many services offer both transactional and marketing email capabilities. Your CRM might include email sending that duplicates your separate email marketing service.
Route through a primary service:
Instead of having five services send directly, route some through your primary email service:
- Send marketing email through your email provider's SMTP relay rather than directly through the marketing platform
- Configure applications to send via your email provider rather than their own delivery infrastructure
Consolidation simplifies SPF but might sacrifice features or convenience specific services provide. Evaluate whether reducing SPF complexity is worth giving up specialized sending capabilities.
Strategy 4: Remove Unnecessary Includes
SPF records often contain includes for services no longer in use.
Common accumulation scenario:
You evaluate several email providers. Each one requires adding their SPF include during trial. You settle on one but forget to remove the others from SPF. Over time, SPF records accumulate includes for defunct services, test systems, and abandoned projects.
For each include in your SPF record, verify:
- Is this service currently active?
- Does it send email on your behalf?
- When was the last time it sent email?
- Is there documentation explaining why it's included?
Don't delete includes immediately. Follow a staged approach:
- Document the include and its suspected purpose
- Set up monitoring for email from that source
- Wait 30 days to confirm no email originates from there
- Monitor for delivery problems for another 30 days
- If no issues arise, removal was successful
Keep records of removed includes so you can quickly restore them if unexpected email sources surface.
Strategy 5: Optimize MX and A Mechanisms
If your SPF uses mx or a mechanisms, these can often be replaced with direct IP addresses.
This tells receiving servers "accept mail from any server listed in my MX records." The SPF validator queries your MX records (1 lookup), then queries the A record for each MX hostname (1 lookup per MX record).
If you have 3 MX records, this consumes 4 lookups (1 for the MX query, 3 for the A records).
Replace mx with the specific IP addresses:
v=spf1 ip4:192.0.2.1 ip4:192.0.2.2 ip4:192.0.2.3 ~all
This reduces lookups from 4 to 0.
v=spf1 a:mail.example.com ~all
This queries the A record for mail.example.com (1 lookup). Replace with the IP:
v=spf1 ip4:192.0.2.1 ~all
If your mail server IPs are static and unlikely to change, replacing mx and a mechanisms with IPs is low-maintenance. If your mail infrastructure is dynamic or you regularly change hosting, the maintenance burden might outweigh the lookup savings.
What About SPF Flattening Services?
SPF flattening services promise to solve the lookup limit by converting your SPF record to pure IP ranges, eliminating includes entirely. While this works technically, it creates significant maintenance and reliability concerns.
- Resolves all your includes to find all IP addresses
- Creates a new SPF record with just ip4/ip6 mechanisms
- You publish this flattened record
When included services change their IPs (which happens regularly), your flattened SPF becomes outdated. The flattening service must detect these changes and update your SPF record automatically.
- The flattening service must have write access to your DNS
- If the service fails to detect changes, your SPF breaks silently
- If the service goes out of business, your SPF maintenance falls to you
- Automated DNS updates can be hijacked or compromised
- You lose visibility into what's actually in your SPF record
When flattening might make sense:
Large organizations with complex email infrastructure and dedicated email deliverability teams might justify flattening services. They have monitoring and processes to detect issues. For most organizations, the operational risk outweighs the benefit.
Alternative: Manual periodic flattening:
Instead of automated flattening, manually flatten your SPF record quarterly or when adding services. This gives you control while reducing lookups. The maintenance burden is manageable if you document the process and set reminders.
Testing Your Optimized SPF
After optimizing, verify SPF still functions correctly.
Confirm the record matches your intended configuration.
Online SPF checking tools verify:
- Record follows best practices
- Include chains resolve properly
Send messages from each service authorized in your SPF to test addresses at major providers (Gmail, Outlook, etc.). Check headers to confirm SPF passes.
After making SPF changes, watch for:
- Bounce messages indicating SPF failures
- Increased spam complaints
- Authentication-related issues in email headers
Gradual rollout for high-stakes changes:
For critical email infrastructure, test changes on a subdomain first. Set up test.example.com with the new SPF record, send test traffic, verify everything works, then apply the same changes to your main domain.
Maintaining SPF Over Time
SPF optimization isn't one-time. Maintenance prevents the record from accumulating lookups again.
Document your SPF strategy:
Record why each include or IP range exists in your SPF record. Note when it was added, for which service, and what email it authorizes. This documentation guides future decisions about modifications.
Quarterly SPF audits catch accumulation before it causes problems. Review:
- Each included service's continued relevance
- Changes in included services' SPF records (which might increase your lookups)
- Opportunities to consolidate or optimize further
Monitor included services:
Services you include can change their SPF structure, potentially pushing your total over 10 lookups. Some SPF monitoring tools alert when included services make changes that affect your lookup count.
Change management process:
Before adding new email services:
- Check current SPF lookup count
- Determine how many lookups the new service adds
- If adding it exceeds 10 lookups, identify optimization opportunities first
- Document the change and its impact
Maintain a history of SPF record changes. If a modification causes delivery problems, quick rollback to a known-good configuration minimizes impact.
Common SPF Optimization Mistakes
Mistake 1: Breaking sender authentication entirely
Over-aggressive optimization can remove legitimate senders. Carefully verify each change maintains authorization for actual email sources.
Mistake 2: Hardcoding IPs that frequently change
Replacing includes with IPs for services that regularly change infrastructure creates maintenance nightmares. Only hardcode IPs for stable infrastructure.
Mistake 3: Not testing after changes
Assuming SPF works after optimization without testing leads to discovered problems only when customers report missing email.
Mistake 4: Forgetting about DMARC
SPF changes affect DMARC authentication. If DMARC requires SPF alignment and you modify SPF incorrectly, DMARC enforcement might cause widespread delivery failures.
Mistake 5: Using SPF flattening without understanding the risks
Automated flattening services create dependencies and single points of failure. Understand the operational model before implementing.
Working with Email Hosting Providers
Most email providers publish recommended SPF configurations and explain their IP ranges. Follow these recommendations rather than guessing.
IP stability commitments:
Ask providers whether their sending IPs are stable enough to hardcode. Some providers explicitly support this and guarantee advance notice of changes. Others change IPs frequently and require using includes.
Multiple provider coordination:
If you use multiple email services, explain SPF lookup limits to each provider's support. They might offer suggestions for optimizing their portion of your SPF or alternative sending configurations that reduce lookup counts.
Some email providers offer managed SPF where they help optimize your record and coordinate with your other services to stay under limits. This can be valuable for complex setups.
The Long-term SPF Strategy
SPF optimization requires balancing several concerns: staying under lookup limits, maintaining correct authorization, minimizing maintenance burden, and preserving reliability.
The optimal approach varies:
Small organizations with simple email infrastructure might use pure includes and never approach lookup limits. Large organizations with dozens of sending sources require active optimization and regular maintenance.
Begin with include mechanisms from service providers. Only optimize to IP ranges when lookup limits force it or when you've verified IP stability justifies the maintenance burden.
As lookup counts grow, tackle the easiest optimizations first, removing obsolete includes, replacing stable mx/a mechanisms with IPs. Save harder optimizations like subdomain splitting for when simpler approaches don't suffice.
SPF's 10-lookup limit is arbitrary and frequently causes problems. Accept that managing SPF for complex email infrastructure requires ongoing attention. Build processes and documentation that make this attention manageable rather than seeking a perfect one-time solution.
The goal isn't eliminating all includes or achieving the absolute minimum lookup count. The goal is reliable email authentication that stays well under 10 lookups while remaining maintainable as your infrastructure evolves.
.png&w=2048&q=75)
.png&w=3840&q=75)
.png&w=3840&q=75)
.png&w=3840&q=75)