Home | Sitemap | Recent Changes | Login

SPF Logo

Sender Policy Framework

SPF Received Header

When an SPF query returns "fail", the MTA should reject the connection.

When an SPF query returns any other result, the MTA should add an advisory header to the message of the form "Received-SPF: neutral" or "Received-SPF: pass". That way, a spam filter further down the road can take that header into account as part of a more balanced decision.

Received-SPF: pass (mybox.example.org: domain of myname@example.com
    designates 192.0.2.1 as permitted sender)
    receiver=mybox.example.org; client_ip=192.0.2.1;
    envelope-from=myname@example.com;

Received-SPF: fail (mybox.example.org: domain of myname@example.com does
    not designate 192.0.2.1 as permitted sender)

Received-SPF: softfail (mybox.example.org: domain of transitioning
    myname@example.com does not designate 192.0.2.1 as permitted sender)

Received-SPF: neutral (mybox.example.org: 192.0.2.1 is neither permitted
    nor denied by domain of myname@example.com)

Received-SPF: none (mybox.example.org: domain of myname@example.com does
    not designate permitted sender hosts)

Received-SPF: permerror -extension:foo (mybox.example.org: domain of
    myname@example.com uses mechanism not recognized by this client)

Received-SPF: temperror (mybox.example.org: error in processing during
    lookup of myname@example.com: DNS timeout)

The SPF specification includes an extension to RFC2822 reserving the "Received-SPF:" header.

If the "permerror" occurred because an SPF publisher uses a mechanism not understood by an SPF client and the receiver does not reject the message due to the permerror, that mechanism should be provided in the header immediately following the "permerror". That way, the information is available to the end user to support troubleshooting.

The following key-value pairs are designed for later machine parsing. SPF clients SHOULD give enough information so that the SPF results can be verified. That is, at least "client-ip", "helo", and, if the "MAIL FROM" identity was checked, "envelope-from".

client-ipthe IP address of the SMTP client
envelope-fromthe envelope sender mailbox
helothe host name given in the HELO or EHLO command
mechanismthe mechanism that matched (if no mechanisms matched, substitute the word "default")
problemif an error was returned, details about the error
receiverthe host name of the SPF client
identitythe identity that was checked; see the <identity> ABNF rule

Here is an example:

Received-SPF: Pass (example.org: domain of scott@kitterman.com
    designates 72.81.252.18 as permitted sender)
    receiver=example.org; client-ip=72.81.252.18;
    envelope-from=<scott@kitterman.com>; helo=mailout00.controlledmail.com;

"Received-SPF:" headers must be added above the standard SMTP "Received:" header for that MTA to avoid ambiguity about whether or not the header was added by a trusted MTA.


Edit text of this page | View other revisions
Last edited 2006-11-20 2:14 (UTC) by Julian Mehnle (diff)