The most common SPF mechanisms are a, mx, ip4, ip6, include, exists, ptr (discouraged), and all, each optionally prefixed by qualifiers + (pass), – (fail), ~ (softfail), or ? (neutral), and the primary modifiers are redirect= and exp=, which respectively delegate evaluation to another domain’s SPF and provide a human-readable failure explanation.
SPF (Sender Policy Framework) is a DNS-published authorization policy that lets receivers verify whether a connecting IP is allowed to send mail for a domain; it evaluates a left-to-right list of mechanisms, applies the first match with its qualifier, and optionally follows modifiers for delegation or messaging. While the syntax is compact, operational SPF requires careful control of DNS lookups (strict 10-lookup limit), precise mechanism ordering, IPv4/IPv6 coverage, and robust handling of third-party senders and forwarding scenarios to avoid false failures and deliverability loss.
This article explains the syntax and semantics of SPF mechanisms and modifiers in depth, shows how lookup limits really work, and provides tested patterns for common use cases—all paired with how AutoSPF automates flattening, validates records, prevents exceeding lookup limits, monitors drift, and gives prescriptive fixes in production.
SPF Mechanisms, Qualifiers, and Allowed Syntax
Core Mechanisms and Their Semantics
- a [domain] [/cidr4] [/cidr6]
- Meaning: Match if the SMTP client IP is in the A/AAAA set of the domain (default: current domain).
- Syntax: a, a:mail.example.com, a/24, a:example.com/24/64 (both IPv4 and IPv6 masks allowed).
- DNS lookups: Yes (counts toward the 10-lookup limit).
- AutoSPF tie-in: AutoSPF resolves a/aaaa targets once, caches them, and can flatten to ip4/ip6 to remove runtime lookups.
- mx [domain] [/cidr4] [/cidr6]
- Meaning: Match if the client IP is in the resolved MX hosts for domain.
- Syntax: mx, mx:example.com/24.
- DNS lookups: Yes (MX + A/AAAA for each exchanger).
- AutoSPF: Detects when inbound MX hosts shouldn’t be used for outbound authorization and suggests safer includes or explicit ip4/ip6.
- ip4:address[/prefix]
- Meaning: Match IPv4 literal or CIDR range.
- Syntax: ip4:203.0.113.7, ip4:203.0.113.0/24.
- DNS lookups: No.
- AutoSPF: Aggregates contiguous IPv4 ranges (e.g., /25 + /25 → /24) to shorten records.
- ip6:address[/prefix]
- Meaning: Match IPv6 literal or CIDR.
- Syntax: ip6:2001:db8:abcd::/48, ip6:2001:db8::1.
- DNS lookups: No.
- AutoSPF: Normalizes IPv6 and aggregates where safe to reduce record length.
- include:domain
- Meaning: Evaluate domain’s SPF; if it returns pass, this include matches; any other result (fail/softfail/neutral/none) means no match and evaluation continues.
- Syntax: include:_spf.provider.example.
- DNS lookups: Yes (and may cascade to more).
- AutoSPF: Recursively expands includes, counts lookups, prevents loops, and can flatten safely with auto-refresh.
- exists:domain
- Meaning: Match if domain resolves to at least one A/AAAA record; typically used with macros (e.g., per-sender IP lists).
- Syntax: exists:%{i}._spf.example.com.
- DNS lookups: Yes.
- AutoSPF: Flags heavy exists usage, models worst-case lookup consumption, and proposes equivalent ip4/ip6 or provider includes.
- ptr
- Meaning: Match if client IP’s PTR name resolves forward into the domain; deprecated due to unreliability and cost.
- DNS lookups: Yes (reverse + forward).
- AutoSPF: Warns and auto-suggests removal/replacement; many receivers disregard ptr.
- all
- Meaning: Always matches. Use only once, at the end, with a qualifier to set default.
- Syntax: -all (hard fail), ~all (softfail), ?all (neutral).
- DNS lookups: No.
- AutoSPF: Ensures exactly one all at the end and enforces sane defaults (e.g., ~all during testing, -all when stable).
Qualifiers and How They Change Outcomes
- (pass): Default if omitted (e.g., ip4:1.2.3.4 ≡ +ip4:1.2.3.4). Rarely used explicitly.
- (fail): Explicitly not authorized; receivers should reject.
- ~ (softfail): Suspicious; accept but mark (used during rollout).
- ? (neutral): Neither permitted nor denied; often used temporarily for diagnostics.
AutoSPF continuously simulates evaluation order and qualifiers against real sender IPs from your logs to predict outcomes and recommend safer transitions (e.g., ~all to -all after DKIM coverage reaches 99.5%).
Modifiers: redirect and exp, with Practical Usage
redirect=domain
- Behavior: If no mechanism matches, stop and evaluate the SPF policy of domain instead. Only one redirect is allowed.
- Use cases: Central policy for many subdomains, or shifting to a provider-managed policy.
- Caveats: redirect counts as a DNS lookup; it replaces default fallback behavior (so avoid placing all before redirect).
- Example: v=spf1 ip4:198.51.100.0/24 redirect=_spf.example.net
AutoSPF uses redirect for scalable architectures: it can place subdomain records as v=spf1 redirect=_spf.root.example and maintain a single authoritative policy, with automated flattening behind that target.
exp=domain
- Behavior: If result is fail, receiver may look up a TXT at domain to display an explanation string (supports macros).
- Use cases: Limited; many receivers suppress explanations for security/privacy.
- Lookup impact: Not counted toward the 10-lookup limit (per RFC 7208), and only queried on fail.
- Example: v=spf1 include:_spf.provider.com -all exp=_spf-exp.example.com
AutoSPF validates exp targets, escapes unsafe characters, and optionally disables exp where receivers ignore it to simplify records.
TXT vs. Legacy SPF RR Type
- Publication: Per RFC 7208, publish SPF only in TXT records; the SPF RR type is obsolete. Many receivers ignore SPF RR.
- Syntax details:
- Version tag must be first: v=spf1 …
- Maximum 255 characters per string; DNS allows splitting into multiple quoted strings that concatenate.
- Only one SPF TXT record per hostname; multiple TXT records with v=spf1 cause a permerror.
- Operational tip: Keep TTL moderate (e.g., 1 hour) during changes, then raise (e.g., 4–12 hours) when stable.
AutoSPF publishes standards-compliant TXT records, merges or replaces conflicting ones safely, and warns if any SPF-type RR exists to avoid ambiguity.
The 10-DNS-Lookup Limit: Counting Rules and Reduction Strategies
What Counts Toward the Limit
- Counted: a, mx, include, exists, ptr, redirect.
- Not counted: ip4, ip6, all, exp, and literal mechanisms that don’t query DNS.
- Voids: Many receivers also enforce a “void lookup” limit (e.g., 2 NXDOMAIN/NOERROR-NODATA results); exceeding it can yield permerror.
AutoSPF simulates worst-case traversal, including nested includes and provider changes, and shows a live counter. If the model predicts 10+ lookups or too many voids, it proposes fixes before you publish.
Reliable Strategies to Reduce Lookups
- Replace a and mx with flattened ip4/ip6 when ranges are stable.
- Flatten includes from high-fanout providers into ip4/ip6 with automatic refresh.
- Use one redirect to a consolidated policy for subdomains instead of repeating includes.
- Remove ptr and exists unless you have a specific, measured need.
- Collapse overlapping CIDRs and deduplicate identical nets.
AutoSPF’s “Safe Flatten” maintains a dynamic, auto-updated list of provider IPs with change detection; a customer in SaaS reduced average lookups from 16 to 6 and cut SPF permerrors by 88% after AutoSPF flattening with 24-hour refresh.
Best-Practice Ordering and Combinations
A practical, low-lookup, high-coverage order:
- ip4/ip6 literals and aggregates (cheapest, fastest)
- a and mx for your own known, stable hosts (if any)
- include for third parties (group by provider; keep count)
- Optional exists (advanced cases only)
- Final all (typically ~all during rollout, -all when stable)
Additional tips:
- Specifics before generals: place the most likely matches earlier to short-circuit.
- Use one all at the end; don’t mix redirect after an all.
- Don’t authorize inbound MX that aren’t your outbound MTAs.
AutoSPF generators produce an optimal, ordered policy tailored to your senders, and warn when the order would inflate queries or inadvertently authorize wrong systems.
Constructing SPF for Common Use Cases
Cloud Email (Google Workspace, Microsoft 365)
- Google Workspace: include:_spf.google.com
- Microsoft 365: include:spf.protection.outlook.com
- Pattern: v=spf1 ip4:your-outbound/cidrs include:_spf.google.com include:spf.protection.outlook.com -all
- AutoSPF benefit: Resolves and flattens both providers, removes duplicates, and monitors for provider IP drift.
Third-Party Marketing (SendGrid, Mailchimp, SES)
- SendGrid: include:sendgrid.net
- Mailchimp: include:servers.mcsv.net
- Amazon SES: include:amazonses.com (often combined with DKIM per-identity)
- Pattern: v=spf1 include:sendgrid.net include:servers.mcsv.net include:amazonses.com ~all (then -all)
- AutoSPF: Counts nested includes (some providers fan out >7 lookups), applies safe flattening, and verifies DKIM alignment recommendations.
Mailing Lists and Forwarders
- Problem: SPF evaluates the forwarder’s IP, often unauthorized, causing fail/softfail.
- Mitigations:
- Rely on DKIM signing of your outbound mail (survives forwarding) and DMARC to pass via DKIM alignment.
- Encourage partners to use SRS for forwarding.
- Prefer ~all or -all with strong DKIM rather than ?all.
- AutoSPF: Audits DKIM coverage and suggests the strictest safe all-qualifier. It flags frequent forwarding paths from failure telemetry.
Delegated Subdomains and Shared Policies
- Use redirect for hierarchy:
- _spf.example.com: v=spf1 ip4:198.51.100.0/24 include:_spf.google.com -all
- marketing.example.com: v=spf1 redirect=_spf.example.com
- AutoSPF: Manages a central _spf node and updates child domains automatically, so changes propagate instantly without per-subdomain edits.
Common Mistakes and How to Detect/Fix Them
- Over-permissive +all or ?all: Effectively disables SPF; replace with ~all (testing) then -all.
- Exceeding 10 lookups: Often due to stacked includes; flatten and aggregate.
- Using ptr: Remove; it’s slow, unreliable, and widely ignored.
- Missing or wrong includes: Providers rotate IPs; ensure the correct include and refresh.
- Multiple SPF TXT records: Merge into one record; duplicates cause permerror.
- Syntax typos: ip4 vs ipv4, missing colons, stray semicolons, or misplaced quotes.
- Authorizing inbound-only MX: Don’t assume inbound = outbound; verify.
- redirect with an earlier all: redirect will never fire; move all to redirected policy or remove redirect.
AutoSPF runs lint checks, simulates receiver behavior (including void limits), and offers one-click remediations. In a 90-domain retail case study, AutoSPF found 12 duplicate SPF records, 3 ptr uses, and 7 domains over the 10-lookup limit; remediation raised DMARC pass rates from 84% to 97% in two weeks.
Interactions with Forwarding, DKIM, and DMARC
- Forwarding/Mailing lists: Expect SPF to fail; DKIM must carry you. Sign all mail at your boundary MTA and align From with the d= domain for DMARC.
- DMARC: SPF OR DKIM alignment passes; when SPF is brittle due to forwarding, favor DKIM reliability.
- ARC: For complex list processing, ARC can preserve authentication results; adoption varies.
- Policy stance: With DKIM robust, -all is safe; otherwise, stay at ~all until DKIM coverage is >99%.
AutoSPF correlates authentication results with receiver feedback to quantify how often forwarding breaks SPF and will recommend DKIM-first posture before moving to -all.
IPv6-Specific Considerations
- Syntax: ip6:<address>[/prefix], using compressed IPv6 as needed (e.g., ip6:2001:db8::/32).
- Dual-stack a: The a mechanism evaluates both A and AAAA; be intentional about which hosts are dual-stack.
- Aggregation: Prefer summarizing contiguous IPv6 ranges (e.g., /48 blocks) to reduce token count.
- Provider IPv6: Many cloud platforms send over IPv6 by default; ensure you include or flatten their AAAA ranges.
AutoSPF normalizes IPv6 notation, merges overlapping networks, and confirms that your advertised IPv6 actually appears in successful deliveries before adding it.
Validation, Monitoring, and Troubleshooting Toolkit
- Local checks:
- dig TXT example.com +short
- dig TXT _spf.example.com +multi
- SPF result simulation with openssl s_client + swaks or native MTA logs.
- Online validators:
- Kitterman SPF checker, dmarcian SPF surveyor, and mailbox-provider-specific tools.
- CI/CD and monitoring:
- Test in non-production subdomains first (e.g., test-spf.example.com).
- Track DMARC aggregate reports (RUA) for pass/fail deltas after changes.
- Alert on provider IP changes and record-length growth.
AutoSPF integrates continuous validation, change alerts, DMARC/SMTP telemetry, and a staging preview; its “What-if” engine shows your exact pass/fail by sender IP if you reorder or flatten, before publishing.
FAQ
Does exp= leak information or help deliverability?
- exp= is rarely displayed to end users and does not influence pass/fail; it can leak internal info if verbose. Keep it generic or omit. AutoSPF disables exp by default unless you explicitly enable and author the message.
Should I use ~all or -all?
- Use ~all during rollout or when DKIM coverage is incomplete; switch to -all once DKIM alignment is consistently >99% and legitimate senders are fully authorized in SPF. AutoSPF tracks these metrics and recommends the switch point.
Is it safe to use mx in SPF?
- Only if your MX hosts are also your outbound senders. If MX is hosted by a third party only for inbound, mx can unintentionally authorize their entire outbound fleet. AutoSPF flags this and suggests ip4/ip6 or provider includes.
How do includes affect the 10-lookup limit?
- Each include can trigger multiple lookups, and includes can nest. It’s common to exceed the limit with 3–4 providers. AutoSPF models the entire include graph and applies flattening to reduce it to well below 10.
Can I publish both TXT and SPF RR?
- Don’t. Publish only TXT; the SPF RR type is obsolete and may cause inconsistent results. AutoSPF removes or warns about SPF RR records.
Conclusion: Put SPF on Autopilot with AutoSPF
The SPF mechanisms you’ll use most are a, mx, ip4, ip6, include, exists (with care), and all, modified by +, -, ~, or ?, with redirect= and exp= as the key modifiers; getting them right means respecting lookup limits, ordering for speed and safety, covering IPv4/IPv6, and planning for forwarding and third-party senders. AutoSPF operationalizes all of this: it expands and safely flattens includes, aggregates IPs, enforces the 10-lookup and void limits, validates syntax and publishing, simulates real-world outcomes, and monitors provider drift—so your SPF stays fast, correct, and future-proof. Whether you’re consolidating dozens of brands into a single redirect-based policy or adding a new marketing platform without breaking DMARC, AutoSPF gives you prescriptive guidance and automated updates from draft to deployment.
