What Is an SPF Record? SPF Syntax Explained
An SPF TXT record states which infrastructure may send mail for a domain's SMTP envelope identity.
How it works
SPF begins with v=spf1 and can use ip4, ip6, a, mx, include, exists, ptr, all, redirect, and exp. Qualifiers +, -, ~, and ? request pass, fail, soft-fail, and neutral handling. SPF does not by itself protect the visible From address; DMARC adds alignment.
What SPF checks
Sender Policy Framework (SPF) is a DNS TXT policy that says which systems may send mail for a domain used in the SMTP envelope sender, often visible as Return-Path. A receiving server evaluates the connecting IP address against that policy. SPF does not simply authenticate the address displayed in a mail client's visible From field.
An SPF record begins with v=spf1. Its mechanisms describe allowed or evaluated sources. Common examples are ip4:192.0.2.0/24, ip6:2001:db8::/32, a, mx, include:sender.example, exists:..., ptr, and all. The a and mx mechanisms use DNS-derived addresses; include evaluates another domain's policy. ptr is generally discouraged because it is expensive and unreliable.
Each mechanism may have a qualifier: + pass, - fail, ~ softfail, or ? neutral. A bare mechanism is equivalent to +. The final all is commonly used to state the policy for sources that did not match an earlier mechanism. -all is a firm failure request, ~all is softfail, ?all is neutral, and +all would match every sender, so it is usually a mistake.
Examples, modifiers, and DNS limits
A simple policy could be v=spf1 ip4:198.51.100.25 include:_spf.examplemail.com -all. It allows one address and the provider policy, then requests failure for everything else. A policy such as v=spf1 a mx ~all can authorize the domain's current A and MX hosts, but it must be reviewed whenever those records change.
redirect= sends evaluation to another SPF policy only when no earlier mechanism matches. exp= names a DNS record that can provide an explanatory message for failures, though support varies. These modifiers have different purposes from include and should not be used as interchangeable aliases.
Several mechanisms can cause DNS lookups, including a, mx, include, exists, redirect, and sometimes ptr. SPF evaluation has a commonly cited limit of ten DNS-query-causing terms per evaluation path. A long chain of includes can exceed that limit even when the visible record is short. Our checker reports direct lookup-causing mechanisms in the record; it does not recursively evaluate the complete dependency tree or claim full RFC validation.
Multiple records, forwarding, and DMARC
Publish exactly one SPF record for a domain. Two TXT strings both beginning v=spf1 are a configuration problem, not policies to merge; receivers can return a permanent SPF error. Keep unrelated verification TXT records separate, and make sure a provider has not accidentally created a second SPF entry.
SPF can fail during ordinary forwarding because the forwarding server's IP is not in the original sender's policy. Forwarding services may use techniques such as SRS, but the point is that an SPF failure is not automatically evidence of forgery. Diagnose the envelope domain, connecting server, and forwarding path before editing a policy.
SPF alone does not protect the visible From domain people see in an inbox. DMARC adds alignment rules: an SPF pass needs to align with the visible From domain to satisfy DMARC through SPF. DKIM can independently satisfy DMARC when its aligned signing domain passes. Use SPF, DKIM, and DMARC as complementary controls.
Troubleshooting an SPF failure
List every legitimate sender first: workplace mail, transactional services, support platforms, and marketing tools. Prefer the provider's documented include domain or stable sending IP range. Remove obsolete senders only after confirming no mail flow depends on them. Then test the published TXT record for syntax, duplicates, qualifiers, and direct DNS mechanisms.
Do not switch blindly from ~all to -all merely to look stricter. A hard fail is appropriate only after legitimate sources are known and authenticated. Pair the review with DMARC monitoring so you can assess alignment and legitimate third-party senders without treating the checker as a delivery simulator.
A typical failure investigation starts with the message's Return-Path and the connecting sender IP, not the From name alone. Compare those details with the one published SPF record and the provider documentation. If a service sends on behalf of a subdomain, decide whether that subdomain needs its own policy or aligned authentication. Record changes should be tested after DNS caches refresh, and every include should have a clear owner; blindly pasting several includes is a common way to create an unmaintainable policy or an evaluation that exceeds DNS lookup limits.
Practical guidance
- Publish one v=spf1 TXT record, not several competing records.
- Review direct include, a, mx, exists, and redirect DNS mechanisms whenever a sender changes.
- Use DMARC to add visible-From alignment on top of SPF and DKIM.
Common question
Does this checker fully validate SPF? No. It parses the record and reports direct DNS-lookup mechanisms without recursively evaluating its dependency tree.