Validating an SPF record means checking it against the rules receiving mail servers actually enforce - the Sender Policy Framework specification (RFC 7208). A record can look correct and still be rejected, so here is what "valid" means and how to fix the faults this validator finds.
What "Valid" Means Under RFC 7208
A valid SPF record satisfies every one of these conditions at once: it is the only v=spf1 TXT record on the domain, it starts with the v=spf1 tag, it uses only recognized mechanisms and qualifiers, it resolves in ten or fewer DNS lookups, it produces no more than two void lookups, and it ends with an all qualifier. Miss any one and receivers may return a PermError and treat the record as if it were never published.
Syntax Rules the Validator Enforces
- One record only. RFC 7208 permits exactly one
v=spf1record per domain. A second one is an automatic PermError - both are ignored. - Correct order. The
v=spf1version tag must come first and theallmechanism must come last. - Valid mechanisms and qualifiers only. Allowed mechanisms are
include,a,mx,ip4,ip6,exists, andall; each may carry a+,-,~, or?qualifier. Typos likeip:orincludes:fail. - String length. Any single character-string in the TXT record must stay within 255 characters, and the whole record within 512 bytes, or DNS truncates it.
The 10-Lookup and 2-Void-Lookup Limits
Two numeric limits catch most "valid syntax, still failing" records. The first is the well-known cap of ten DNS-querying mechanisms per evaluation - every include, a, mx, ptr, and exists counts, and nested includes count recursively. The second, less familiar limit is void lookups: no more than two mechanisms may resolve to an empty DNS answer. Blow past either and the result is a PermError. If your record is over the ten-lookup limit, AutoSPF flattens the includes into a compact record that validates cleanly and re-scans every 15 minutes - see too many DNS lookups for the details.
Deprecated and Risky Mechanisms
The validator warns on two things that are technically parseable but should be avoided. The ptr mechanism is deprecated by RFC 7208 (§5.5) because it is slow and unreliable - replace it with ip4/ip6 or an include. And +all authorizes the entire internet to send as your domain, defeating the purpose of SPF entirely; a valid record should end in -all or ~all.
How to Fix an Invalid SPF Record
Most validation failures map to one of four fixes:
- Two SPF records? Merge every sender into a single
v=spf1record. - Over 10 lookups? Replace lookup-heavy includes with
ip4/ip6entries, or flatten the record automatically with AutoSPF. - Deprecated
ptr? Remove it and authorize those hosts by IP or include instead. - Missing or wrong qualifier? Ensure the record starts with
v=spf1and ends with-all(or~allwhile you test).
Rebuilding from scratch is often easier than patching - the free SPF record generator produces a syntactically clean record you can validate here in one step.
Where SPF Sits Alongside DKIM and DMARC
A valid SPF record is necessary but not sufficient. DKIM signs the message body and DMARC ties SPF and DKIM to the visible From domain and sets the enforcement policy. After your SPF record validates, confirm the other two with the free DMARC checker and DKIM lookup. Re-validate SPF whenever you add or remove a sending service, and audit it at least once a quarter - and remember each sending subdomain needs its own valid record.