SPF Record Optimization for Complex Infrastructure

Why SPF Breaks at Scale

Every new SaaS tool you connect wants an SPF include. As part of your DNS configuration, Google Workspace, SendGrid, Mailgun, HubSpot, your helpdesk, your CRM — each adds one or more DNS lookups. Hit 11 and SPF returns permerror. Every email from your domain fails SPF authentication.

This isn't theoretical. I see it weekly in deliverability audits. The root domain's SPF record has 14 lookups because nobody audited it after adding the fifth SaaS integration.

Count Your Lookups First

These SPF mechanisms cost a DNS lookup each: include, a, mx, exists, redirect. These are free: ip4, ip6, all.

The catch: lookups are recursive. If include:sendgrid.net resolves to a record with 3 more includes, that's 4 total lookups from one mechanism.

v=spf1 include:_spf.google.com include:sendgrid.net include:mailgun.org include:spf.protection.outlook.com ~all

This looks like 4 lookups, but _spf.google.com alone nests 3-4 more includes. You're likely at 12+ already.

Run a count with MXToolbox or dmarcian's SPF surveyor. Know your exact number before changing anything.

Optimization Strategies

1. Remove Dead Includes

The fastest win. Audit every include mechanism:

• Do you still use that ESP?
• Is that SaaS tool still sending email on your behalf?
• Did you switch from Mailchimp to Klaviyo six months ago but leave the Mailchimp include?

Remove anything you're no longer actively using. Most domains I audit have 1-3 dead includes.

2. Use Subdomains to Split SPF Scope

Each subdomain gets its own 10-lookup budget. This is the cleanest long-term solution — see our full subdomain strategy guide.

# Root domain — corporate email only
domain.com TXT "v=spf1 include:_spf.google.com -all"

# Marketing subdomain
marketing.domain.com TXT "v=spf1 include:sendgrid.net -all"

# Transactional subdomain
mail.domain.com TXT "v=spf1 include:mailgun.org -all"

Three SPF records, each with 1-2 includes. Clean, maintainable, and you get stream separation as a bonus.

3. Flatten Includes to IP Ranges

Replace include:esp.example.com with the actual IP addresses it resolves to:

# Before (1 lookup + nested lookups)
include:sendgrid.net

# After (0 lookups)
ip4:149.72.0.0/16 ip4:159.183.0.0/16 ip4:167.89.0.0/17

The risk: ESPs change their IP ranges. If SendGrid adds new IPs and your flattened record doesn't include them, email from those IPs fails SPF. Use an automated flattening tool that monitors and updates.

Practitioner note: I only flatten as a last resort. Subdomain splitting is almost always the better answer. Flattening creates a maintenance burden that most teams forget about within two months.

4. Replace a and mx with ip4

The a and mx mechanisms each cost a lookup. If your server IPs rarely change, replace them:

# Before (2 lookups)
v=spf1 a mx include:sendgrid.net ~all

# After (0 extra lookups)
v=spf1 ip4:203.0.113.5 ip4:203.0.113.10 include:sendgrid.net ~all

5. Consolidate ESPs

Do you really need three ESPs? Consolidating from three sending services to two saves 3-5 lookups from nested includes. This is often the right business decision anyway — fewer ESPs means simpler infrastructure monitoring.

Practitioner note: The most over-engineered SPF record I've seen had 8 includes, 4 of which were for services the company no longer used. Removing the dead includes fixed their permerror instantly. Always audit before you optimize.

The SPF Optimization Checklist

1. Count current lookups (use dmarcian SPF surveyor)
2. Identify and remove unused includes
3. Move sending services to subdomains where possible
4. Replace a and mx with ip4/ip6 for static IPs
5. Flatten remaining includes only if still over 10
6. Set up monitoring to alert on SPF permerror
7. Document which include serves which purpose

When to Use SPF Flattening Tools

If subdomain splitting isn't possible (legacy systems, organizational constraints), automated flattening tools handle the maintenance:

• AutoSPF — resolves and flattens on a schedule
• dmarcian — SPF management as part of DMARC monitoring
• EasyDMARC — includes SPF flattening in their platform

These tools re-resolve your includes periodically and update the flattened record. They solve the stale-IP problem but add another dependency to your infrastructure.

Practitioner note: For agencies managing 20+ client domains, subdomain splitting plus a standard include template is the only scalable approach. You can't manually flatten 20 SPF records every time an ESP updates their IP ranges.

If your SPF record is a mess and you're not sure what's safe to remove, schedule a consultation — I'll audit your DNS, identify every sending source, and build an optimized SPF architecture that stays under the lookup limit.

Sources

• RFC 7208: Sender Policy Framework (SPF)
• dmarcian: SPF Surveyor Tool
• Google: SPF Record Requirements
• MXToolbox: SPF Record Check

---

v1.0 · April 2026