The Received-SPF header

Received-SPF is a header a receiving server adds after checking SPF. The first word is the result (pass, fail, softfail, neutral, none, temperror or permerror), then a human-readable comment, then key=value pairs that record exactly what was checked: the connecting IP (client-ip), the envelope sender (envelope-from), the HELO name, and often which rule in the SPF record matched. It carries the same verdict as spf= in Authentication-Results, with more detail. As with any trace header, only the one your own provider added at the top is reliable.

Received-SPF: pass (mx1.example.org: domain of bounce@example.com designates
       203.0.113.5 as permitted sender) receiver=mx1.example.org;
       client-ip=203.0.113.5; envelope-from="bounce@example.com";
       helo=out1.example.com; identity=mailfrom; mechanism=ip4:203.0.113.0/24;

The format

RFC 7208 §9.1 defines the header:

Received-SPF: <result> (<comment>) key=value; key=value; ...

It's a trace field, added at the top of the header above the receiving server's own Received: line. A new Received-SPF must go above any existing ones, so the topmost is the newest.

The result

The result is one of the seven SPF outcomes defined in RFC 7208 §2.6:

Each result has its own page; the ones people ask about most are fail, softfail and permerror.

The comment

The parenthesized text after the result is free-form. RFC 7208 §9.1 suggests it include the IP, the sender and the domain, and most implementations produce a sentence like "domain of X designates Y as permitted sender." It's for humans. The wording differs by software and isn't meant to be parsed.

The key=value pairs

These are meant for machines, and RFC 7208 §9.1 recommends including at least client-ip, helo, and envelope-from (when the MAIL FROM identity was checked), so the result could be re-checked later.

Implementations may add their own keys (RFC 7208 §9.1), and some omit the recommended ones, so don't be surprised by variation.

Which identity was checked

SPF can check two identities (RFC 7208 §2.3, §2.4):

• MAIL FROM: the domain of the envelope sender. This is the usual one and the one DMARC uses.
• HELO: the host name in the greeting. Servers are encouraged to check this too, and it's what gets checked for bounce messages, which have an empty envelope sender. In that case SPF treats the sender as postmaster@ the HELO name.

identity= tells you which one the result refers to. When it says helo, the result says nothing about the From or Return-Path domain.

Received-SPF vs Authentication-Results spf=

RFC 7208 §9 describes both headers and explains the difference in purpose:

• Received-SPF is designed to record enough detail to reconstruct the check: IP, HELO, envelope sender, matching mechanism.
• Authentication-Results reports just the outcome and which identity it applied to, in a format shared with DKIM, DMARC and other methods (RFC 7208 §9.2, RFC 8601 §2.7.2).

The same check, written both ways:

Authentication-Results: mx1.example.org; spf=pass smtp.mailfrom=example.com
Received-SPF: pass (mx1.example.org: domain of bounce@example.com designates
       203.0.113.5 as permitted sender) client-ip=203.0.113.5;
       envelope-from="bounce@example.com"; helo=out1.example.com;

smtp.mailfrom in Authentication-Results corresponds to envelope-from with identity=mailfrom in Received-SPF. If the check was on HELO, Authentication-Results says smtp.helo= instead.

Large providers such as Gmail and Microsoft 365 commonly add both; some other systems write only one. If both are present from the same server, they should agree. RFC 7208 §9 notes that operators who use both must keep them consistent.

Trusting it

Like any trace header, Received-SPF can be forged by the sender or added by any server along the way. Only the topmost one written by your own provider's inbound server reflects a check you can rely on.

A quick consistency test: the client-ip in your provider's Received-SPF should be the same IP that appears in brackets in your provider's first inbound Received: line. If a Received-SPF lower down names a different IP, that's an earlier hop's check: perhaps the sender's own outbound filter, or a forwarder. That's useful for debugging and meaningless as proof.

Tip: Forwarding breaks SPF. When a message is forwarded, the forwarder's IP becomes the client-ip, and it usually isn't in the original sender's SPF record, so you'll see fail or softfail on mail that was genuine. Look for DKIM or ARC results in that case. See forwarding and mailing lists.

Reading one quickly

1. Read the result word.
2. Check identity (or assume mailfrom if absent) and the domain in envelope-from. That's the domain the result is about, not necessarily the From domain.
3. Confirm client-ip matches your provider's first inbound hop.
4. If it failed, mechanism and problem explain why. Paste the header into the analyser to see it alongside the other authentication results and the alignment check.