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: myname@example.com does not designated permitted sender hosts)

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

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

The SPF RFC includes an extension to RFC2822 reserving the Received-SPF header.

If the "unknown" occurred because an SPF publisher uses a mechanism not understood by an SPF client, that mechanism should be provided in the header immediately following the "unknown". That way, a downstream filter that does understand that mechanism can perform further tests on the message.

Received-SPF: unknown +domainkeys:dk.example.com (domain of sender mengwong@pobox.com specifies unrecognized mechanism)