Received-SPF is an email header inserted by the receiving mail server recording the SPF check verdict for the message. It’s the first line of evidence when debugging a delivery failure — showing exactly why SPF passed, softfailed, or failed.
Header Format
Received-SPF: pass (google.com: domain of [email protected] designates 203.0.113.42
as permitted sender) client-ip=203.0.113.42;SPF Verdicts
| Result | Meaning |
|---|---|
pass | Sending IP is in the SPF record — authorized |
fail | Sending IP is not in SPF, policy is -all — hard reject |
softfail | Sending IP is not in SPF, policy is ~all — flag but deliver |
neutral | Policy explicitly gives no verdict (?all) |
none | No SPF record at the domain |
temperror | DNS lookup failure — try again |
permerror | SPF syntax error, too many DNS lookups, or two SPF records |
What to Do With Each
- pass — authentication succeeded, continue investigating other failure modes (DKIM, DMARC alignment)
- softfail — mail probably going to spam folder; tighten to
-allafter verifying no legitimate senders miss - fail — SPF is actively rejecting; add the sending source or fix
include:chain - permerror — SPF is broken structurally; count DNS lookups (limit 10), check for multiple TXT records, validate syntax
Modern Header
Many receivers now use Authentication-Results: (RFC 8601) instead of Received-SPF — same information, unified format across SPF/DKIM/DMARC.
Debug SPF verdicts and fix errors with the email authentication checker and the SPF failure fix guide.
Related
Check the SPF glossary entry, the MAIL FROM entry, and read what an SPF record is.