Sender Policy Framework

Sender Policy Framework (SPF) is an email authentication method that allows checking whether the sending mail server is authorized to originate mail from the email sender's domain. No mention was made of the concept again until a first attempt at an SPF-like specification was published in 2002 on the IETF "namedroppers" mailing list by Dana Valerie Reese,

In June 2003, Meng Weng Wong merged the RMX and DMP specifications and solicited suggestions from others. Over the next six months, a large number of changes were made and a large community had started working on SPF. Originally SPF stood for Sender Permitted From and was sometimes also called SMTP+SPF; but its name was changed to Sender Policy Framework in February 2004.

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.

The SPF community returned to the original "classic" version of SPF. 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. On April 28, 2006, the SPF RFC was published as experimental RFC 4408.

On April 25, 2014 IETF published SPF in RFC 7208 as a "proposed standard" which "obsoleted" RFC 4408 and, as of May 2026, RFC 7208 had not been obsoleted.

Principles of operation

thumb|Example scenario|320x320px

The Simple Mail Transfer Protocol permits any computer to send email claiming to be from any source address. This is exploited by spammers and scammers who often use forged email addresses, making it more difficult to trace a message back to its source, and easy for spammers to hide their identity in order to avoid responsibility. 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.

SPF allows the owner of an Internet domain to specify which computers are authorized to send mail with envelope-from addresses in that domain, using Domain Name System (DNS) records. Receivers verifying the SPF information in TXT records may reject messages from unauthorized sources before receiving the body of the message. 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. Current practice requires the use of TXT records, just as early implementations did. For a while a new record type (SPF, type 99) was registered and made available in common DNS software. Use of TXT records for SPF was intended as a transitional mechanism at the time. The experimental RFC, RFC 4408, section 3.1.1, suggested "an SPF-compliant domain name SHOULD have SPF records of both RR types". The proposed standard, RFC 7208, says "use of alternative DNS RR types was supported in SPF's experimental phase but has been discontinued".

FAIL and forwarding

SPF breaks plain message forwarding. When a domain publishes an SPF FAIL policy, legitimate messages sent to receivers forwarding their mail to third parties may be rejected and/or bounced if all of the following occur:

The forwarder does not rewrite the Return-Path, unlike mailing lists.
The next hop does not allowlist the forwarder.
This hop checks SPF.

This is a necessary and obvious feature of SPF – checks behind the "border" MTA (MX) of the receiver cannot work directly.

Publishers of SPF FAIL policies must accept the risk of their legitimate emails being rejected or bounced. They should test (e.g., with a SOFTFAIL policy) until they are satisfied with the results. See below for a list of alternatives to plain message forwarding.

HELO tests

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

With a bogus HELO identity the result NONE would not help, but for valid host names SPF also protects the HELO identity. This SPF feature was always supported as an option for receivers, and later SPF drafts including the final specification recommend to check the HELO always.

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

Implementation

Compliance with SPF consists of three loosely related tasks:

Publishing a policy: Domains and hosts identify the machines authorized to send email on their behalf. They do this by adding additional records to their existing DNS information: every domain name or host that has an A record or MX record should have an SPF record specifying the policy if it is used either in an email address or as HELO/EHLO argument. Hosts which do not send mail should have an SPF record published which indicate such ("v=spf1 -all").
Checking and using SPF information: Receivers use ordinary DNS queries, which are typically cached to enhance performance. Receivers then interpret the SPF information as specified and act upon the result.
Revising mail forwarding: Plain mail forwarding is not allowed by SPF. The alternatives are:
Remailing (i.e., replacing the original sender with one belonging to the local domain)
Refusing (e.g., answering <code>551 User not local; please try <user@example.com></code>)
Allowlisting on the target server, so that it will not refuse a forwarded message
Sender Rewriting Scheme, a more complicated mechanism that handles routing non-delivery notifications to the original sender

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

"v=spf1 ip4:192.0.2.0/24 ip4:198.51.100.123 a -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 "ip4" and "a" 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 should be rejected.

Mechanisms

Eight mechanisms are defined:

| valign="top" | ALL || Matches always; used for a default result like <code>-all</code> for all IPs not matched by prior mechanisms.

| valign="top" | A || If the domain name has an address record (A or AAAA) that can be resolved to the sender's address, it will match.

| valign="top" | IP4 || If the sender is in a given IPv4 address range, match.

| valign="top" | IP6 || If the sender is in a given IPv6 address range, match.

| valign="top" | MX || If the domain name has an MX record resolving to the sender's address, it will match (i.e. the mail comes from one of the domain's incoming mail servers).

| valign="top" | PTR || If the domain name (PTR record) for the client's address is in the given domain and that domain name resolves to the client's address (forward-confirmed reverse DNS), match. This mechanism is discouraged and should be avoided, if possible.

A typical SPF HELO policy <code>v=spf1 a mx ip4:192.0.2.0 -all</code> may execute four or more DNS queries: (1) TXT record (SPF type was obsoleted by RFC 7208), (2) A or AAAA for mechanism <code>a</code>, (3) MX record and (4+) A or AAAA for each MX name, for mechanism <code>mx</code>. Except the first one, all those queries count towards the limit of 10. In addition if, for example, the sender has an IPv6 address, while its name and its two MX names have only IPv4 addresses, then the evaluation of the first two mechanisms already results in more than two void lookups and hence PERMERROR. Mechanisms <code>ip4</code>, <code>ip6</code> and <code>all</code> need no DNS lookup.

Issues

DNS SPF Records

To enable rapid testing and deployment, initial versions of SPF checked for its setting in the DNS TXT record of the sending domain - even though this record was traditionally supposed to be free-form text with no semantics attached. 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 2014 the use of this record was discontinued after the SPFbis working group concluded that " ...significant migration to the SPF RR type in the foreseeable future was very unlikely and that the best solution for resolving this interoperability issue was to drop support for the SPF RR type."

Deployment

Anti-spam software such as SpamAssassin version 3.0.0 and ASSP implement SPF. Many mail transfer agents (MTAs) support SPF directly such as Courier, CommuniGate Pro, Wildcat, MDaemon, and Microsoft Exchange, or have patches or plug-ins available that support SPF, including Postfix, Sendmail, Exim, qmail, and Qpsmtpd. As of 2017, more than eight million domains publish SPF FAIL <code>-all</code> policies. In a survey published in 2007, 5% of the <code>.com</code> and <code>.net</code> domains had some kind of SPF policy. In 2009, a continuous survey run at Nokia Research reports that 51% of the tested domains specify an SPF policy. These results can include trivial policies like <code>v=spf1 ?all</code>.

In April 2007, BITS, a division of the Financial Services Roundtable, published email security recommendations for its members including SPF deployment. In 2008, the Messaging Anti-Abuse Working Group (MAAWG) published a paper about email authentication covering SPF, Sender ID, and DomainKeys Identified Mail (DKIM). In their "Sender Best Communication Practices" the MAAWG stated: "At the very least, senders should incorporate SPF records for their mailing domains". In 2015, the Messaging Anti-Abuse Working Group (MAAWG) revised a paper about email authentication covering SPF, DomainKeys Identified Mail (DKIM), and DMARC (DMARC). In their revised "Sender Best Communication Practices" the MAAWG stated: "Authentication supports transparency by further identifying the sender(s) of a message, while also contributing to the reduction or elimination of spoofed and forged addresses".

From February 1, 2024, Google requires SPF or DKIM for all domains sending emails to Gmail accounts. Bulk senders (5000+ emails per day) are required to have SPF, DKIM, and DMARC setup for their domains.

References

External links

IETF RFC4408: Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1 EXPERIMENTAL (2006)
IETF RFC6652: Sender Policy Framework (SPF) Authentication Failure Reporting Using the Abuse Reporting Format, PROPOSED STANDARD (2012)
IETF RFC7208: Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1, PROPOSED STANDARD (2014)
libspf2 – An Open Source Implementation of the SPF Protocol (2010)
SenderPolicyFramework.com – tool for the lookup, generation, and validation of SPF records