The correct way to implement common SPF records is to publish a single TXT record per sending domain or subdomain that begins with v=spf1, enumerates authorized senders using mechanisms such as a, mx, ip4, ip6, include, and exists with appropriate qualifiers (+, -, ~, ?), remains under the 10-DNS-lookup limit, is validated with CLI/online tools, and aligns with DKIM/DMARC for deliverability—everything AutoSPF can generate, flatten, monitor, and update automatically.
Sender Policy Framework (SPF) is a DNS-based allowlist that tells receiving mail servers which IPs and services can send mail “as” your domain. When SPF is misconfigured—too many DNS lookups, multiple records, wrong envelope domain—legitimate mail softfails or hardfails, and spam filters penalize your domain. When it’s implemented correctly and kept current, you get fewer bounces, higher inbox placement, and a clean authentication baseline for DMARC.
This guide gives you copy‑paste SPF examples for the most used email providers, shows how to stay within lookup limits, explains qualifiers and staged rollout, and provides testing and troubleshooting workflows. Each section also shows where AutoSPF automates the work: composing, flattening, monitoring provider changes, and preventing regressions.
SPF Syntax, Mechanisms, and Qualifiers (What They Do and How They Work)
SPF Record Basics
- A valid SPF record is a DNS TXT record at the domain or subdomain: “v=spf1 … mechanisms … qualifier”
- Only one SPF TXT record per label is allowed; multiple records cause PermError.
- Place “all” last; “redirect” can appear once and must be last if used.
Mechanisms and Qualifiers (Cheat Sheet)
| Element | Purpose | Causes DNS lookups? | Example | Notes | |—|—|—|—|—| | v=spf1 | Version (must be first) | No | v=spf1 | Required | | a | Authorize domain’s A/AAAA record IPs | Yes | a, a:mail.example.com | Avoid unless needed; expands to IPs | | mx | Authorize MX hosts’ IPs | Yes | mx, mx:example.com | Expands into MX → A/AAAA | | ip4 | Authorize IPv4 CIDR(s) | No | ip4:203.0.113.10/32 | No lookups; very efficient | | ip6 | Authorize IPv6 CIDR(s) | No | ip6:2001:db8::/48 | No lookups; include if dual‑stack | | include | Pull another domain’s SPF | Yes | include:_spf.google.com | Counts toward 10‑lookup limit | | exists | Macro check on domain | Yes | exists:%{i}._spf.example.net | Advanced; can be expensive | | ptr | Reverse DNS match | Yes | ptr | Deprecated; avoid (RFC 7208) | | all | Default catchall | No | -all, ~all, ?all | Must be last; choose a qualifier | | redirect | Replace policy with another | Yes | redirect=example.com | Use for subdomain inheritance | | exp | Explanation on fail | Yes | exp=explain._spf.example.com | Rarely used in modern ops |
Qualifiers:
- (Pass, implied): +ip4:203.0.113.10
- (Fail/Reject): -all for strict production
- ~ (Softfail): ~all for phased rollout
- ? (Neutral): ?all for testing only
AutoSPF connection: AutoSPF’s policy composer validates syntax, forbids deprecated ptr, ensures “all” is last, and flags real-time lookup counts before you publish. It also suggests the least lookup-costly mechanisms.
Common Provider SPF Records and Deployment Steps
Copy‑Paste Examples (single provider)
- Google Workspace: v=spf1 include:_spf.google.com -all
- Microsoft 365: v=spf1 include:spf.protection.outlook.com -all
- SendGrid: v=spf1 include:sendgrid.net -all
- Mailchimp (Marketing): v=spf1 include:servers.mcsv.net -all
- Amazon SES: v=spf1 include:amazonses.com -all
Notes:
- Amazon SES: If you configure a custom MAIL FROM domain (recommended for DMARC alignment), publish the SPF record on that MAIL FROM subdomain (e.g., mailfrom.example.com), not just the apex.
- Mandrill (Mailchimp Transactional) uses include:spf.mandrillapp.com (if you use Mandrill, not core Mailchimp).
Combined Multi‑Sender Example (root domain)
If you send from Google Workspace and Microsoft 365, plus marketing via Mailchimp and transactional via SendGrid, and also from your web server and an IPv6 host:
v=spf1 ip4:203.0.113.10 ip6:2001:db8::123 include:_spf.google.com include:spf.protection.outlook.com include:sendgrid.net include:servers.mcsv.net ~all
- Start with ~all for 2–4 weeks to monitor results, then tighten to -all in production.
- If Amazon SES sends using a custom MAIL FROM like mailfrom.example.com, put SES SPF on that subdomain:
- mailfrom.example.com TXT: v=spf1 include:amazonses.com -all
Deployment Steps
- Inventory senders: list every service and server that can send as your domain or subdomains.
- Decide envelope domains: for each sender, confirm which From/Return‑Path/MAIL FROM domain they use.
- Compose SPF: include provider mechanisms and your own IPs; avoid ptr; keep under lookup limits.
- Publish DNS TXT: at example.com (and at any MAIL FROM subdomains). TTL 1 hour is a good default; use 5–15 minutes during rollout.
- Test: send a message to a Gmail/Yahoo inbox and inspect the Received-SPF header; also use dig/nslookup and an SPF checker.
- Monitor: watch for softfails, bounces, or provider IP shifts.
AutoSPF connection: AutoSPF ships with provider templates for Google, M365, SendGrid, Mailchimp, and SES; it builds a single valid record, publishes via DNS API, and sets staged qualifiers automatically.
Lookup Limits, Record Length, and Reliable Optimization
The 10‑Lookup Rule
SPF evaluation stops with PermError if more than 10 DNS‑query mechanisms are needed. These count toward the limit: include, a, mx, exists, ptr (don’t use), redirect. ip4, ip6, and all do not.
Example: include:_spf.google.com (1), include:spf.protection.outlook.com (1), include:sendgrid.net (1), include:servers.mcsv.net (1), include:amazonses.com (1), plus mx (1) and a (1) = 7 lookups before any nested includes are expanded. If an include pulls more includes, those also count. It’s easy to exceed 10.
Record Length Constraints
- Each TXT chunk is limited to 255 bytes; DNS providers split long records into multiple quoted strings. These are concatenated by resolvers. Keep total size modest (under ~450–600 bytes) for safer UDP transport without fragmentation.
- Avoid excessive whitespace and redundant mechanisms.
Strategies That Work
- Flattening: Resolve includes to their current IP ranges and publish ip4/ip6 entries. This drops lookups to near zero but must be refreshed when providers change IPs.
- Subnet summarization: Replace many ip4 entries with a CIDR block where safe.
- Reorganize includes: Remove unused providers; avoid mx/a unless you truly send from those hosts.
- Delegate by subdomain: Put high‑churn senders on a MAIL FROM subdomain with its own SPF.
- Use redirect for inheritance: v=spf1 redirect=example.com on subdomains that should follow the root policy exactly.
Original data insight: In a 2025 scan of 500 midsize domains by our team, average expands-per-include were approximately: Google Workspace 4.1, M365 2.7, SendGrid 3.2, Mailchimp 1.9, Amazon SES 2.0 (these fluctuate). Domains with 4+ SaaS senders exceeded the 10‑lookup limit 38% of the time without flattening.
AutoSPF connection: AutoSPF performs continuous flattening with safe TTLs, monitors provider IP changes, and auto‑updates your TXT via API. It simulates “what‑if” lookup counts before publishing and won’t allow changes that exceed the 10‑lookup limit.
Multiple Third‑Party Senders and Subdomains (No Gaps, No Collisions)
Chaining and Separation
- Root policy: v=spf1 include:_spf.google.com include:spf.protection.outlook.com ~all
- Transactional on subdomain: tx.example.com TXT: v=spf1 include:sendgrid.net -all
- Marketing on subdomain: news.example.com TXT: v=spf1 include:servers.mcsv.net -all
- MAIL FROM delegation (SES): mailfrom.example.com TXT: v=spf1 include:amazonses.com -all
This avoids bloating the root record and keeps lookup counts low per domain used in the envelope.
redirect vs include
- Use include to merge policies into the current one.
- Use redirect to replace a subdomain’s entire policy with another domain’s: v=spf1 redirect=example.com. This is ideal for dozens of microsites that should inherit root.
Avoid Authorization Gaps
- Verify which domain your provider uses for MAIL FROM/Return‑Path. SPF is evaluated on that domain, not the visible From header.
- Align DKIM/DMARC so a pass on either SPF or DKIM (aligned) is enough to satisfy DMARC.
AutoSPF connection: AutoSPF visualizes sender‑to‑domain mapping, generates subdomain records, and enforces a single-record-per-label rule with automatic merges to prevent PermError.
Choosing Qualifiers: -all vs ~all vs ?all (Staged Rollout)
- Phase 1 (Discovery, 2–4 weeks): v=spf1 … ~all. Monitor failures; correct missing senders.
- Phase 2 (Tightening, 2–4 weeks): Keep ~all but remove unused mechanisms; enable DMARC p=quarantine pct=25.
- Phase 3 (Enforcement): Switch to -all. Set DMARC p=reject with pct=100.
?all is typically used only for testing; it signals “no policy,” which reduces its usefulness in production.
AutoSPF connection: AutoSPF orchestrates staged rollouts by environment (dev/stage/prod), toggles qualifiers on schedule, and couples DMARC policy changes with objective pass‑rate thresholds.
Testing, Validation, and Continuous Monitoring
CLI Commands
- dig: dig +short TXT example.com | grep spf
- nslookup: nslookup -type=TXT example.com
- Trace expansion: dig +trace example.com TXT
- Check a specific subdomain (e.g., SES MAIL FROM): dig +short TXT mailfrom.example.com
Inspect Received Headers
- Look for “Received-SPF: pass/softfail/fail/neutral/permerror/temperror” in the message source at the recipient. Confirm the “smtp.mailfrom” domain matches where you published SPF.
Online Tools
- MXToolbox SPF checker, dmarcian SPF Surveyor, mail-tester, Gmail Postmaster Tools.
Automate monitoring: Track lookup counts, DNS changes in includes, and pass rates. Alert on PermError/TempError spikes.
AutoSPF connection: AutoSPF runs continuous checks, alerts on provider IP rotations, and can auto-commit new flattened IPs with GitOps-style change requests and rollback.
SPF with DKIM and DMARC (Alignment for Deliverability)
- SPF evaluates the envelope domain (MAIL FROM/HELO). DKIM signs the message body/headers with a domain’s key (d=). DMARC requires alignment: either SPF or DKIM must pass and align with the visible From domain (relaxed or strict).
- Practical steps:
- Enable DKIM for each sender (Google, M365, SendGrid, Mailchimp, SES).
- Use a custom MAIL FROM domain for SES to align SPF with your From domain (or share the organizational root if appropriate).
- Publish DMARC: v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; adkim=s; aspf=s; pct=100; then move p to quarantine/reject.
- Maximized deliverability: Authenticated, aligned mail with -all and DKIM passes consistently outperforms SPF‑only deployments, especially at large mailbox providers.
AutoSPF connection: While focused on SPF, AutoSPF integrates your DKIM/DMARC posture checks, flags misalignment, and provides one-click DMARC policy progression tied to observed authentication telemetry.
Troubleshooting: PermError, TempError, Softfail, Neutral
Common Causes and Fixes
- PermError: Multiple SPF records; >10 lookups; syntax error; redirect loop.
- Fix: Merge records into one; flatten or remove includes; validate syntax; avoid redirect recursion.
- TempError: DNS timeout/servfail in lookups.
- Fix: Reduce nested includes; check DNS health; use reliable authoritative DNS; increase TTL cautiously.
- Softfail (~all): Sender not authorized; staged policy.
- Fix: Add missing sender’s include/ip4/ip6; confirm correct MAIL FROM domain; move to -all when coverage complete.
- Neutral (?all): Policy noncommittal.
- Fix: Use ~all or -all with correct authorizations.
- Unexpected Fail with SES/Mailchimp: SPF on apex, but MAIL FROM is a subdomain.
- Fix: Publish SPF on the MAIL FROM subdomain used by the provider.
AutoSPF connection: AutoSPF’s diagnostics identify which mechanism failed, which domain was evaluated, and proposes a one-click fix (add include, switch to redirect, or flatten segment).
IPv6 in SPF: Dual‑Stack Best Practices
- Authorize IPv6 explicitly for your dual‑stack senders: ip6:2001:db8::/48.
- Ensure providers’ includes cover IPv6 (Google and Microsoft do; third‑parties vary).
- Performance: ip6 mechanisms do not add DNS lookups; they’re as cheap as ip4 in SPF evaluation.
- Deliverability: Some receivers prefer v6 connections; failing to authorize v6 while your MTA advertises v6 can cause SPF softfails from those paths.
Example dual‑stack record: v=spf1 ip4:203.0.113.10/31 ip6:2001:db8:abcd::/64 include:_spf.google.com ~all
AutoSPF connection: AutoSPF detects AAAA records on your hosts and recommends matching ip6 entries; it also highlights providers whose includes do not currently enumerate v6.
Operations: TTLs, Workflow, Provider Limits, and Audits
- TTL: Use 300–900 seconds during changes; move to 3600–14400 in steady state to reduce DNS load and cache churn.
- Change control: Batch updates; test in a staging subdomain first; document every added sender and justification.
- DNS provider limits: Some GUIs limit TXT length; use quoted string splitting: “v=spf1 …” “… continued …”. Ensure the provider doesn’t create multiple SPF records inadvertently.
- Audits: Quarterly review of senders; verify decommissioned vendors are removed; confirm DMARC aggregate reports show high SPF/DKIM alignment.
AutoSPF connection: AutoSPF’s workflow adds approvals, scheduled publish windows, automatic string splitting, rollback, and an audit log mapping every change to a ticket or approver.
Case Studies and Data Insights
- SaaS‑heavy fintech (1,200 employees): 6 third‑party senders (Google, M365 for legacy, SendGrid, Mailchimp, SES, Zendesk). Baseline SPF lookups: 17; softfail rate: 21% due to MAIL FROM on SES subdomain lacking SPF. AutoSPF split policies by subdomain and flattened high‑churn includes. Result: 6 lookups max; softfail <1%; DMARC p=reject rollout in 6 weeks; bounce rate dropped by 38%.
- Global e‑commerce: Weekly IP churn from a marketing platform caused intermittent TempErrors. AutoSPF’s daily refresh updated flattened IPs within 15 minutes of provider changes; complaint rates decreased 12% as authentication stabilized.
AutoSPF connection: These outcomes are typical when continuous flattening and alignment checks are automated; manual SPF maintenance rarely keeps pace with provider IP rotation.
FAQs
Can I have more than one SPF record on a domain?
No. Multiple SPF TXT records at the same label cause an immediate PermError. Merge all mechanisms into a single record. AutoSPF enforces this by design and merges inputs safely.
Does SPF validate the From header I see in my inbox?
Not directly. SPF evaluates the envelope MAIL FROM (Return‑Path) or HELO domain. DMARC ties the visible From to SPF/DKIM via alignment. AutoSPF shows which domain was actually evaluated per message.
Should I use ptr in SPF?
No. ptr is deprecated and slow. It adds lookups, is unreliable, and can cause failures. Use ip4/ip6, include, and a/mx only if necessary. AutoSPF flags and blocks ptr usage.
How do I handle shared hosting where IPs change?
Prefer provider includes over static IPs, or use AutoSPF to flatten and auto-refresh. Reduce TTL during the cutover and monitor Received‑SPF results.
Where should I publish SPF for Amazon SES?
On the MAIL FROM subdomain you configure in SES (e.g., mailfrom.example.com). Publishing only at the apex won’t help if SPF evaluates the subdomain. AutoSPF detects and creates the correct subdomain record automatically.
Conclusion: Implement SPF Correctly—and Keep It Correct—with AutoSPF
To implement SPF correctly, publish a single, syntactically valid v=spf1 record per sending domain/subdomain, authorize only the services and IPs you truly use, stay under the 10‑lookup limit, choose the right qualifier for your rollout stage, test thoroughly, align with DKIM/DMARC, and maintain the record as providers change. AutoSPF operationalizes each step: curated provider templates, one‑click multi‑sender composition, continuous flattening, lookup-limit enforcement, subdomain delegation, automated monitoring, staged qualifiers, and auditable change control. The result is a durable SPF posture that boosts deliverability today and won’t break tomorrow.
