SPF: Sender Policy Framework
SPF publishes the list of servers allowed to send mail using your domain in the envelope sender.
What SPF is
SPF, specified in RFC 7208, is a TXT record on the domain itself listing which servers may send mail using that domain in the envelope sender — the address used in the SMTP exchange, not the From header a reader sees.
A domain must publish at most one SPF record. Two is a permanent error, and receivers are expected to treat the result as unusable rather than choosing one.
Reading the mechanisms
Mechanisms are evaluated left to right and the first match wins. "ip4:" and "ip6:" authorise addresses directly. "a" and "mx" authorise the domain's own address and mail-exchanger hosts. "include:" brings in another domain's policy, which is how hosted providers are authorised.
"include:" imports a policy for evaluation; it does not delegate the whole result. A failure inside an included policy does not by itself fail the check.
The all qualifiers
The final term decides what happens when nothing matched. "-all" is a hard fail, "~all" is a soft fail asking receivers to accept but mark the message, and "?all" expresses no opinion.
"+all" authorises every server on the internet. It appears occasionally in real zones and is almost always a mistake.
What an SPF record looks like
SPF is published as a TXT record at the domain itself, holding a single quoted string that opens with the version tag: example.com. 3600 IN TXT "v=spf1 include:_spf.example.net ip4:192.0.2.25 ~all".
Everything between the version tag and the final all is a list of mechanisms, read left to right. The first one that matches decides the result, so order is not decoration.
There is no SPF record type. A dedicated type existed and was retired, and RFC 7208 leaves TXT as the only place SPF is published.
Checking a domain’s SPF record
dig TXT example.com +short returns every TXT record at the name, SPF among them. The one that matters is whichever string begins with v=spf1.
A domain must publish exactly one. Two records starting with v=spf1 is a permanent error under RFC 7208, and the usual cause is a second provider adding its own record rather than adding an include to the existing one. The fix is to merge them into a single string.
A record that looks right can still fail on the ten-lookup limit below, which no amount of reading the text will reveal. That is what the checker is for.
The ten-lookup limit
SPF evaluation is capped at ten mechanisms that require DNS lookups — include, a, mx, ptr, exists and redirect all count against it. Exceeding the limit is a permanent error, and the check fails rather than passing on what was evaluated so far.
Nested includes are the usual cause. Each provider added pulls in its own includes, so the count grows faster than the record looks.
What SPF does not do
SPF authenticates the envelope sender, not the From header. A message can pass SPF while displaying any From address, which is why SPF alone does not stop spoofing.
SPF also breaks on forwarding: a forwarded message arrives from the forwarder's server, which the original domain never authorised. DKIM survives forwarding where SPF does not, and DMARC accepts either.