SPF

What SPF actually checks

When a message arrives, the receiving server looks at the domain in the envelope sender (the Return-Path), fetches that domain's TXT records, and finds the one beginning v=spf1. It then asks whether the IP address that delivered the message is on the list. The answer is pass, softfail, fail, or neutral.

SPF checks the Return-Path domain, not the visible From address. That gap is why SPF alone does not stop someone writing your name in the From line, and why DMARC exists: it requires the checked domain to align with the From domain.

The record, read left to right

v=spf1 include:_spf.google.com include:sendgrid.net ~all

• v=spf1 — the version tag. It must come first.
• include: — also authorize whatever that domain's own SPF record authorizes. See SPF include.
• ip4: / ip6: — authorize a specific address or range.
• ~all — softfail everything else. -all is a hard fail. +all authorizes the whole internet; never use it.

The three failures that cause most problems

1. Two SPF records. A domain may publish only one. Two make SPF return a permanent error, and receivers treat the result as a failure.
2. Too many lookups. SPF allows ten DNS lookups; include chains count. See the SPF lookup limit.
3. A sender left out. Your sequencer, CRM, or billing tool sends as your domain but is not in the record.

SPF is per domain and is not inherited by subdomains, so a sending subdomain needs its own record. Build one with the SPF generator, then look it up live with the deliverability checker. Provider-specific steps are under SPF, DKIM and DMARC setup.