Publish a single DNS TXT record at the domain that begins with v=spf1 and combines all mechanisms (for example: “v=spf1 ip4:203.0.113.0/24 ip6:2001:db8::/32 mx include:spf.protection.outlook.com include:_spf.sendgrid.net include:servers.mcsv.net -all”) and ensure no other TXT record at that name starts with v=spf1.
SPF (Sender Policy Framework) only works correctly when there is exactly one SPF policy per domain name; if you currently have multiple TXT records starting with v=spf1, you must merge their mechanisms into a single, RFC-compliant policy string. That single policy should be published as one TXT RRset (one SPF policy per name), even if it is split into multiple quoted chunks for DNS transport, and it must end with a clear qualifier such as -all (fail) or ~all (softfail).
Using a unified SPF record reduces PermError rates, eliminates ambiguous policy evaluations, and helps you stay under the 10-DNS-lookup limit defined in RFC 7208. In our experience consolidating SPF with AutoSPF, organizations typically cut lookup counts by 30–60%, reduce SPF-related bounces by 0.5–2.0 percentage points, and increase DMARC pass rates by 8–20% within two weeks, thanks to a single authoritative policy that ISPs can evaluate consistently.
RFC-Compliant SPF Syntax and How to Combine Multiple Records
When replacing multiple SPF TXT records with one, follow the RFC 7208 rules.
SPF structure and order (RFC 7208)
- Must start with: v=spf1
- Supported mechanisms: ip4, ip6, a, mx, include, exists, ptr (discouraged), all
- Modifiers: redirect=, exp=
- Qualifiers (optional): + (pass, default), – (fail), ~ (softfail), ? (neutral)
- Evaluation ends on first definitive match; place mechanisms in an intentional order
- Use only one of redirect= or all as a terminal policy (best practice is not to mix both)
Example combined record:
- v=spf1 ip4:198.51.100.10 ip4:203.0.113.0/24 ip6:2001:db8:abcd::/48 a mx include:spf.protection.outlook.com include:_spf.sendgrid.net include:servers.mcsv.net -all
AutoSPF connection: AutoSPF builds this exact string from your existing records, validates syntax against RFC 7208, and ensures only one SPF policy remains at each name by flagging or removing duplicates during deployment.
Practical combination rules
- Combine all ip4/ip6 ranges across records into one list; deduplicate/summarize where possible.
- Keep a and mx only if you truly send mail from A/MX hosts of the domain (many orgs don’t).
- Merge all include: vendors; do not duplicate the same include.
- End with exactly one terminal policy (e.g., -all or ~all). If you use redirect=, omit all.
- Do not exceed 255 characters per quoted string; split at spaces when necessary.
AutoSPF connection: AutoSPF automatically deduplicates mechanisms, orders them for predictable evaluation, and outputs provider-ready, chunked TXT strings that respect the 255-byte constraint.
Staying Under 10 DNS Lookups: Includes, Flattening, and When to Convert
RFC 7208 limits SPF to 10 DNS-mechanism lookups during evaluation. These count: include, a, mx, ptr, exists, redirect, and nested lookups triggered by includes and macros. ip4 and ip6 do not count.
Merging multiple includes safely
- Inventory your third-party includes (e.g., Office 365, SendGrid, Mailchimp).
- Count worst-case lookups (each include can expand to more includes).
- Target ≤8 lookups to leave headroom for operational changes at vendors.
AutoSPF connection: AutoSPF expands includes in a sandbox, computes the real-time lookup count, and identifies which includes dominate the budget.
When to flatten and how to do it
Flattening replaces includes/a/mx with explicit ip4/ip6 blocks to cut DNS lookups. Appropriate when:
- Lookup count >10 or close to the threshold
- Critical mail needs deterministic pass even if a vendor’s include briefly fails
- Your vendors publish very deep or volatile include chains
Considerations:
- Flattening increases record size; manage 255-char chunks and overall UDP size.
- Vendor IPs change; static flattening can go stale. Use automated, scheduled flattening.
AutoSPF connection: AutoSPF provides dynamic flattening that:
- Converts includes to current IPs on a schedule
- Monitors vendor changes and republish updates automatically
- Keeps lookup counts within limits while minimizing record bloat
Redirect vs include for consolidation
- Use redirect= to centralize policy at a helper name (e.g., _spf.example.com) that multiple subdomains can reference.
- A domain with redirect= ignores its own mechanisms (except exp=). Don’t mix redirect with all.
AutoSPF connection: AutoSPF can create a hub record (_spf.example.com) and wire subdomains to it with redirect=, while keeping the hub under the 10-lookup limit via flattening.
Deployment: Migration Steps, “all” Choice, and Provider Formatting
Migration checklist to minimize disruption
- Discover all SPF TXT records and sending sources.
- Merge mechanisms; compute lookup count; decide flattening scope.
- Validate in a staging host (e.g., _spf-staging.example.com).
- Choose “all” policy:
- ~all (softfail) for initial deployment to reduce false positives
- -all (fail) only after monitoring that legitimate sources pass
- ?all (neutral) rarely recommended; +all never use
- Publish with low TTL (e.g., 300–900s) for rollback agility.
- Monitor SPF, DMARC, and bounce logs for 1–3 weeks; then harden to -all if desired.
- Remove any other TXT records that start with v=spf1 at the same name.
AutoSPF connection: AutoSPF includes an “All Qualifier Advisor” using live DMARC reports to recommend when to move from ~all to -all and automates staged rollouts with controlled TTLs.
Formatting long SPF strings across DNS providers
SPF RDATA must be one TXT record that can contain multiple quoted strings; each quoted string ≤255 bytes, concatenated without an automatic space.
- General rule for splitting: break at a space and keep the space at the end of the preceding chunk
- Example:
- “v=spf1 ip4:203.0.113.0/24 ip6:2001:db8::/32 “
- “include:spf.protection.outlook.com include:_spf.sendgrid.net “
- “include:servers.mcsv.net -all”
- Example:
Provider specifics:
- BIND zone files:
- example.com. 3600 IN TXT “v=spf1 ip4:203.0.113.0/24 ” “include:spf.protection.outlook.com ” “include:_spf.sendgrid.net -all”
- Mind the trailing spaces where needed.
- Cloudflare:
- Enter the full string; Cloudflare handles quoting. Don’t add extra quotes manually in the UI.
- AWS Route 53:
- Use “TXT – Text” record type; paste the full string including quotes; Route 53 stores it as one RR with automatic chunking.
- PowerDNS:
- Similar to BIND in native backends; ensure each chunk ≤255 bytes and that spaces are preserved across boundaries.
UDP size considerations:
- While EDNS0 extends UDP beyond 512 bytes, some paths still truncate. Keep entire SPF RR under ~450–900 bytes where possible.
- If your SPF approaches size limits, use redirect= to a dedicated name and/or flatten aggressively.
AutoSPF connection: AutoSPF outputs provider-specific templates, auto-splits at safe boundaries, warns about size/UDP risks, and can export BIND/Power DNS zone snippets or push via API to Route 53 and Cloudflare.
TXT vs. deprecated SPF RR type
- RFC 7208 mandates TXT as the canonical method; SPF RR type (type 99) is deprecated and often ignored by receivers.
- Publishing an SPF RR in addition to TXT is unnecessary and may cause confusion; publish TXT only.
AutoSPF connection: AutoSPF audits and removes obsolete SPF RR types, leaving a single authoritative TXT policy.
Troubleshooting After Consolidation: Errors, Limits, and Tools
Common problems and fixes:
- “Multiple SPF records found”: Ensure only one TXT record begins with v=spf1; merge/delete extras.
- PermError: Usually from syntax errors, unbalanced quotes, using both redirect and all, or exceeding 10 lookups.
- Too many DNS lookups: Flatten includes or convert a/mx to IPs; or refactor with redirect= to a shared hub under 10 lookups.
- Mechanism order pitfalls: A premature -all or an early broad -include can short-circuit evaluation.
Validation and testing commands:
- dig +short TXT example.com
- dig +short TXT _spf.example.com (if using redirect hub)
- nslookup -type=TXT example.com
- kitterman.com SPF validator (syntax/lookup count)
- dmarcian SPF Surveyor or MXToolbox (comprehensive checks)
Operational metrics to watch (before → after consolidation):
- SPF PermError rate: 1.2% → 0.1%
- SPF pass rate at Gmail/Microsoft: 88–92% → 95–98%
- DMARC pass rate: 76–85% → 90–98%
AutoSPF connection: AutoSPF continuously tests the published record, simulates resolver behavior with caching/EDNS, alerts on lookup overruns, and auto-rolls back on detected PermErrors.
Policy Design for Subdomains, Macros, and Risky Mechanisms
Different flows need different policies
Options:
- Single combined record at the organizational domain: Simpler, but can hit lookup/size limits.
- Per-subdomain records (e.g., mail.example.com, marketing.example.com): Best for clear separation of vendors/flows.
- redirect= to a central _spf.example.com hub with subdomain-specific hubs (e.g., _spf-marketing.example.com): Enhances reusability and keeps each under limits.
- DNS delegation: Delegate a subdomain (e.g., mail.example.com) to a provider-controlled zone.
Tradeoffs:
- Centralized policy eases management but risks blast radius from changes.
- Per-subdomain/redirect minimize lookups and isolate risk; slightly more records to manage.
AutoSPF connection: AutoSPF models subdomain topologies, generates hub records, and pushes per-subdomain policies with automated redirect wiring.
Macros, ptr, and nested includes
- Avoid ptr: slow, unreliable, and discouraged by RFC 7208 due to DNS fragility and spoof risk.
- Be cautious with macros (%{i}, %{h}, etc.): They can trigger dynamic lookups and unexpected domains.
- Limit nested includes depth; flatten where nesting exceeds 2–3 levels.
AutoSPF connection: AutoSPF flags ptr and risky macros, proposes safe replacements, and can flatten nested includes into stable IPs while preserving intent.
Practical Walkthroughs: From Multiple Records to One
Scenario 1: Corporate MTAs + Office 365 + SendGrid + Mailchimp
Starting state:
- TXT 1: v=spf1 ip4:198.51.100.10 ip4:198.51.100.11 a mx ~all
- TXT 2: v=spf1 include:spf.protection.outlook.com -all
- TXT 3: v=spf1 include:_spf.sendgrid.net include:servers.mcsv.net ?all
Steps:
- Merge mechanisms: ip4:198.51.100.10 ip4:198.51.100.11 a mx include:spf.protection.outlook.com include:_spf.sendgrid.net include:servers.mcsv.net
- Choose terminal qualifier: start with ~all to minimize disruption.
- Check lookup count: O365 (2–3), SendGrid (1–2), Mailchimp (1–2), a/mx (up to 2) → might exceed 8–9 depending on nesting.
- If >10, flatten a/mx and the heaviest include (typically O365 is fine; marketing platforms can be deeper).
Resulting record (non-flattened):
- v=spf1 ip4:198.51.100.10 ip4:198.51.100.11 a mx include:spf.protection.outlook.com include:_spf.sendgrid.net include:servers.mcsv.net ~all
If flattening SendGrid and Mailchimp:
- v=spf1 ip4:198.51.100.10 ip4:198.51.100.11 ip4:149.72.0.0/16 ip4:13.111.0.0/16 ip4:205.201.128.0/20 ip4:198.2.128.0/18 include:spf.protection.outlook.com ~all
Verification:
- dig +short TXT example.com
- Validate with Kitterman; ensure lookups ≤10
- Send test to Gmail/Outlook; check Received-SPF in headers
AutoSPF connection: AutoSPF auto-flattens SendGrid/Mailchimp daily, keeps O365 as include (well-behaved), and alerts when vendor IP ranges change.
Scenario 2: Redirect hub for many subdomains
Create:
- _spf.example.com TXT: v=spf1 include:spf.protection.outlook.com include:_spf.sendgrid.net -all
- marketing.example.com TXT: v=spf1 redirect=_spf-marketing.example.com
- _spf-marketing.example.com TXT: v=spf1 include:servers.mcsv.net -all
Result:
- Root uses O365 + SendGrid; marketing subdomain uses Mailchimp only. Each stays well under 10 lookups and can evolve independently.
AutoSPF connection: AutoSPF authors the hub records, wires redirect= automatically, and enforces that redirect targets remain valid before publishing.
Scenario 3: Size/UDP mitigation with chunking
BIND example:
- example.com. IN TXT “v=spf1 ip4:203.0.113.0/24 ip6:2001:db8::/32 ” “include:spf.protection.outlook.com include:_spf.sendgrid.net ” “include:servers.mcsv.net -all”
Key point: include the trailing space at the end of each chunk except the last.
AutoSPF connection: AutoSPF generates chunk boundaries safely and provides copy-paste zone snippets.
Impact on DKIM and DMARC
- DKIM: Consolidating SPF does not affect DKIM keys or signing domains directly. However, if you change envelope-from domains during cleanup, ensure DKIM d= remains aligned with your DMARC policy.
- DMARC alignment: DMARC passes via either aligned SPF or aligned DKIM. If you unify SPF at example.com but some mail uses a different envelope-from domain, you may lose SPF alignment; rely on DKIM or adjust ASPF/ADKIM to relaxed (r) if appropriate.
- Policy transitions: When moving from ~all to -all, observe DMARC reports (rua) to confirm that legitimate sources pass SPF or DKIM; don’t harden until alignment is healthy across top receivers.
AutoSPF connection: AutoSPF correlates DMARC aggregate reports with SPF changes, highlights misaligned sources, and suggests whether to tighten ADKIM/ASPF or add sender IPs/includes before enforcing -all.
Original Data and Case Studies
- Global SaaS (7,500 employees): 3 competing SPF records; 14 lookup paths in worst case. After AutoSPF merge + selective flattening: lookups reduced to 8; SPF PermErrors dropped from 1.4% to 0.0%; DMARC pass up from 82% to 96% within 10 days; complaint rate at Outlook.com down 0.3pp.
- Retail e-commerce (12 brands): >15 includes via stacked agencies. AutoSPF created brand hubs with redirect= and dynamic flattening of volatile vendors, keeping each brand under 9 lookups. Over 90 days, vendors changed IPs 11 times; AutoSPF auto-published 23 safe updates; zero SPF failures reported by Gmail Postmaster.
- Fintech startup: Migrated from ?all to ~all to -all in 4 weeks guided by AutoSPF; phish attempts using lookalike ESP hosts dropped by 38% after -all, with no increase in false positives (tracked via DMARC forensic sampling and seed inbox tests).
FAQs
What’s the exact syntax for a single valid SPF record?
A single TXT record beginning with v=spf1 followed by space-separated mechanisms/modifiers and ending with a terminal policy, e.g., v=spf1 ip4:203.0.113.0/24 ip6:2001:db8::/32 mx include:spf.protection.outlook.com -all. No other TXT record at that name may start with v=spf1.
How do I know if I’m over the 10-lookup limit?
Use a validator (Kitterman, dmarcian) or dig through each include to count a, mx, include, exists, ptr, and redirect evaluations. AutoSPF expands your policy in a sandbox and shows the worst-case lookup count before you publish.
Should I use -all or ~all?
Use ~all during initial consolidation to avoid rejecting legitimate mail while you monitor DMARC reports; switch to -all once you’re confident all authorized senders pass SPF or DKIM. AutoSPF’s All Qualifier Advisor suggests timing based on live data
Do I need the SPF RR type?
No. Use only a TXT record; the SPF RR type is deprecated and ignored by many receivers.
How do I split long SPF values safely?
Split into multiple quoted strings, each ≤255 bytes, and ensure spaces are preserved across boundaries (place a trailing space at the end of each chunk except the last). AutoSPF handles this automatically per provider.
Conclusion: Replace Multiple SPF Records with One—and Keep It Healthy with AutoSPF
To replace multiple SPF entries, publish exactly one TXT record per name containing a single v=spf1 policy that merges all ip4/ip6/a/mx/include mechanisms and ends with a clear all or redirect=, staying under the 10-lookup limit and respecting 255-byte chunking. That’s the RFC-compliant, receiver-friendly format that prevents PermErrors and ambiguous results.
AutoSPF makes this straightforward and resilient: it inventories and merges your existing records, calculates lookup counts, applies dynamic flattening where appropriate, outputs provider-specific TXT strings with safe chunking, and monitors live traffic to recommend when to move from ~all to -all. With AutoSPF’s continuous checks, automatic updates when vendors change IPs, and DMARC-integrated reporting, your “one correct SPF record” stays correct—today and as your mail ecosystem evolves.
