Sender Policy Framework

In computing, Sender Policy Framework (SPF) is an extension to the Simple Mail Transfer Protocol (SMTP). SPF allows software to identify and reject forged addresses in the SMTP MAIL FROM (Return-Path), a typical nuisance in e-mail spam. SPF is defined in RFC 4408.

Principles of Operation

Normal SMTP allows any computer to send e-mail claiming to be from anyone. Thus, it's easy for spammers to send e-mail from forged addresses. This makes itdifficult to trace back to where the spam truly comes from, and easy for spammers to appear to besenders the receiver would ordinarily trust. Manybelieve that the ability for anyone to forge Return-Path addresses is a security flaw in modernSMTP, caused by an undesirable side-effect of thedeprecation of source routes.

Further information: Sender Rewriting Scheme (SRS)

SPF allows the owner of an Internet domain to use special DNS records to specify which machines are authorized to transmit e-mail for that domain. For example, the owner of the example.org domain can designate which machines are authorized to send e-mail whosee-mail address in the Return-Path ends with "@example.org". Receivers checking SPF can then reject any e-mail that claims to come from that domain, but fails in a check against the IPslisted in the sender policy of this domain.

SPF protects the address in the Return-Path, thatis the address to which bounces would be sent ifthe mail is not delivered. While the address inthe Return-Path often matchesother originator addresses in the mail header like "From:" or "Sender:" this is not necessarily thecase, and SPF does not prevent forgeries of theseother addresses.

Spammers can send e-mail with an SPF PASS resultif they have an account in a domain with a senderpolicy, or abuse a compromised system in thisdomain. However, doing so makes the spam easier totrace and prosecute. An SPF PASS result from unknown strangers still guarantees that auto-replieslike error messages (bounces) cannot hit innocent bystanders.

The main benefit of SPF is to people whose e-mail addresses are forged in the Return-Paths. Theyreceive a large mass of unsolicited error messagesand other auto-replies, making it difficult to usee-mail normally. If such people use SPF tospecify their legitimate sending IPs with a FAILresult for all other IPs, then receivers checkingSPF can reject forgeries, already reducing theamount of back-scatter. More important spammersknowing their trade will avoid forging SPF FAILprotected addresses, because they want to reachas many of their primary victims as possible -there are more than enough unprotected addressesfor this abuse.

SPF has potential advantages beyond helping identify unwanted e-mail. In particular, if a sender provides SPF information, then receivers can use SPF PASS results in combination with a white list to identify known reliable senders.Scenarios like compromised systems and shared sending mailers limit this use, but at least auto-replies cannot hit innocent bystanders.

FAIL and forwarding

If a domain publishes an SPF FAIL policy,then legitimate mails sent to receivers forwardingtheir mail to third parties can be rejected andbounced if (1) the forwarder doesn't rewrite theReturn-Path unlike mailing lists, (2) the nexthop doesn't white list the forwarder, and (3) this hop checks SPF. This is an intentional and obvious feature of SPF - checks behind the "border" MTA(MX) of the receiver can't workdirectly.

Publishers of SPF FAIL policies must accept thispotential problem, they cannot expect that all receivers change their forwarding arrangements,i.e. clear at least one of the three criticalconditions.

A technique called Sender Rewriting Scheme(SRS) is a way for mail forwarding services to avoid this problem.

HELO tests

For an empty Return-Path as used in error messagesand other auto-replies SPF checks the HELO-identity. Actually it checks an artificial postmaster@mail.example.org address for aHELO or EHLO mail.example.org.

With a bogus HELO identity the result NONE won't help, but for valid host names SPF also protects the HELO identity. This SPF feature was always supported as option for receivers, and later SPF drafts including the final specification recommendto check the HELO always.

This allows to white list sending mailers based ona HELO PASS, or to reject all mails after a HELO FAIL. It can be also used in reputation systems (any white or black list is a simple case of a reputation system).

Implementation

Implementing SPF has two parts:
* Domains identify the machines authorized to send e-mail on their behalf. Domains do this by adding an additional record to their existing DNS information.
* Receivers can request and use SPF information. They use ordinary DNS queries, which are typically cached to enhance performance. Receivers then interpret the SPF information as specified and act upon the result.

Thus, the key issue in SPF is the specification for the new DNS information that domains set and receivers use. The records are laid out like this(in typical DNS-syntax):

example.org. IN TXT "v=spf1 a mx -all"

"v=" defines the version of SPF used, the following words provide mechanisms to use to determine if a domain is eligible to send mail. The "a" and "mx" specify the systems permitted to send messages for the given domain. The "-all"at the end specifies that, if the previous mechanisms did not match, the message shouldbe rejected.

Mechanisms

Eight mechanisms are defined:{| valign="top" | ALL