Sender Policy Framework

If the email is bounced, a message is sent to this address,[2] and for downstream transmission it typically appears in the "Return-Path" header.

[7][5] These posts ignited a lot of interest, led to the forming of the IETF Anti-Spam Research Group (ASRG) and their mailing list, where the SPF idea was further developed.

Among the proposals submitted to the ASRG were "Reverse MX" (RMX) by Hadmut Danisch, and "Designated Mailer Protocol" (DMP) by Gordon Fecyk.

[8] In June 2003, Meng Weng Wong merged the RMX and DMP specifications[9] and solicited suggestions from others.

In early 2004, the IETF created the MARID working group and tried to use SPF and Microsoft's CallerID proposal as the basis for what is now known as Sender ID; but this collapsed due to technical and licensing conflicts.

In July 2005, this version of the specification was approved by the IESG as an IETF experiment, inviting the community to observe SPF during the two years following publication.

The Simple Mail Transfer Protocol permits any computer to send email claiming to be from any source address.

It is also used in phishing techniques, where users can be duped into disclosing private information in response to an email purportedly sent by an organization such as a bank.

Thus, the principles of operation are similar to those of DNS-based blackhole lists (DNSBL), except that SPF uses the authority delegation scheme of the Domain Name System.

[14] The proposed standard, RFC 7208, says "use of alternative DNS RR types was supported in SPF's experimental phase but has been discontinued".

Publishers of SPF FAIL policies must accept the risk of their legitimate emails being rejected or bounced.

For an empty Return-Path as used in error messages and other auto-replies, an SPF check of the HELO identity is mandatory.

To date only the two modifiers defined in the RFC 4408 have been widely deployed: As soon as SPF implementations detect syntax errors in a sender policy they must abort the evaluation with result PERMERROR.

[17] Although in July 2005, IANA assigned a specific Resource Record type 99 to SPF the uptake of was never high, and having two mechanisms was confusing for users.

In 2009, a continuous survey run at Nokia Research reports that 51% of the tested domains specify an SPF policy.

[24][25][needs update] In April 2007, BITS, a division of the Financial Services Roundtable, published email security recommendations for its members including SPF deployment.

[26] In 2008, the Messaging Anti-Abuse Working Group (MAAWG) published a paper about email authentication covering SPF, Sender ID, and DomainKeys Identified Mail (DKIM).

[29] From February 1, 2024, Google requires SPF or DKIM for all domains sending emails to Gmail accounts.