SPF Records Explained

Email was designed decades before spam and spoofing were a serious problem, and nothing in the original protocol stops a sender from writing whatever they like in the from address. SPF, short for Sender Policy Framework, is one of the fixes that came later. It lets a domain publish a public list of servers that are allowed to send mail claiming to be from it, so a receiving mail server has something concrete to check the message against.

SPF is published as a TXT record on the domain, which is why Frabs' SPF Checker and DNS Lookup tools both find it the same way, by looking up TXT records and picking out the one that starts with v=spf1.

v=spf1 ip4:203.0.113.0/24 include:_spf.google.com -all

• v=spf1 marks this as an SPF record and must come first.
• ip4 (and ip6) list specific IP addresses or ranges allowed to send for this domain.
• include points at another domain's SPF record and pulls its allowed senders in too, which is how a business using Google Workspace or a marketing platform authorizes that provider without listing raw IP addresses itself.
• a and mx, less common today, authorize the domain's own A record or mail servers directly.
• all sits at the end and defines what happens for anything not matched by the rules above it.

The qualifier in front of all controls how strictly a receiving server should treat mail from an unlisted source. A minus sign, -all, is a hard fail and tells receivers this list is complete, reject anything else outright. A tilde, ~all, is a soft fail, asking receivers to treat unlisted mail with suspicion without necessarily rejecting it. A question mark, ?all, is neutral and barely worth publishing at all, since it makes no real recommendation either way. Most domains that are serious about stopping spoofing end up at -all once they are confident every legitimate sending source is actually listed.

SPF checking is only allowed to perform ten DNS lookups in total while evaluating a record, counting every include, a and mx mechanism, including ones nested inside another include. A domain that has accumulated includes for several different email tools over the years, a CRM here, a support platform there, a marketing tool after that, can quietly exceed this limit without anyone noticing, at which point receiving servers are required to treat the entire check as a failure regardless of whether the actual sending server was legitimate. This is one of the more common reasons a technically present SPF record still fails to protect a domain properly.

• Publishing two separate SPF records instead of merging them into one. Only a single SPF record is valid, and having more than one causes the check to fail entirely.
• Forgetting to add a new provider's include after switching email or marketing platforms, so genuine mail from the new provider starts failing SPF.
• Leaving the record at ~all indefinitely rather than tightening it to -all once everything sending on the domain's behalf has been confirmed and listed.
• Quietly exceeding the ten lookup limit through accumulated includes, which silently breaks the entire check.

Frabs' SPF Checker looks up a domain's SPF record directly and reports whether one is present, along with the raw record so you can read through the includes and the final qualifier yourself. If email from a particular provider is being marked as spam or rejected outright, this is usually the first place to look.