Editing Sender Policy Framework (section)

==Principles of operation==
{{Further2|[[Sender Rewriting Scheme]] (SRS)}}
[[File:Sender Policy Framework.svg|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 [[e-mail spam|spammers]] and scammers who often use forged [[Address munging|email addresses]],<ref name=":0">{{cite web |url=https://www.ietf.org/mail-archive/web/ietf/current/msg81939.html |title=Last Call: <draft-ietf-spfbis-4408bis-19.txt> (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard |author=Dan Schlitt |date=29 August 2013 |work=IETF Discussion List |publisher=[[Internet Engineering Task Force|IETF]] |access-date=16 December 2013}}</ref> 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 record]]s 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,<ref name="rfc7208-txt">{{cite IETF |title=Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1 |rfc=7208 |sectionname=DNS Resource Records |section=5.5 |author=Scott Kitterman |date=April 2014 |publisher=[[Internet Engineering Task Force|IETF]] |access-date=26 April 2014 }}</ref> 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 [[Domain Name System#Resource_records|RR]] types".<ref>Wong, M., and W. Schlitt. RFC 4408. April 2006 <rfc:4408></ref>  The proposed standard, RFC 7208, says "use of alternative DNS RR types was supported in SPF's experimental phase but has been discontinued".<ref name="rfc7208-txt" />

The envelope-from address is transmitted at the beginning of the SMTP dialog. If the [[server (computing)|server]] rejects the domain, the unauthorized [[Client (computing)|client]] should receive a rejection message, and if that client was a relaying [[message transfer agent]] (MTA), a [[bounce message]] to the original envelope-from address may be generated. If the server accepts the domain, and subsequently also accepts the recipients and the body of the message, it should insert a Return-Path field in the message header in order to save the envelope-from address. While the address in the Return-Path often matches other originator addresses in the mail header such as the ''header-from'', this is not necessarily the case, and SPF does not prevent forgery of these other addresses such as ''sender'' header.

Spammers can send email with an SPF PASS result if they have an account in a domain with a sender policy, or abuse a compromised system in this domain. However, doing so makes the spammer easier to trace.

The main benefit of SPF is to the owners of email addresses that are forged in the Return-Path. They receive large numbers of unsolicited error messages and other auto-replies. If such receivers use SPF to specify their legitimate source IP addresses and indicate FAIL result for all other addresses, receivers checking SPF can reject forgeries, thus reducing or eliminating the amount of [[Backscatter (e-mail)|backscatter]].

SPF has potential advantages beyond helping identify unwanted mail. In particular, if a sender provides SPF information, then receivers can use SPF PASS results in combination with an allow list to identify known reliable senders. Scenarios like compromised systems and shared sending mailers limit this use.

===Reasons to implement===
If a domain publishes an SPF record, spammers and phishers are less likely to forge emails pretending to be from that domain, because the forged emails are more likely to be caught in spam filters which check the SPF record. Therefore, an SPF-protected domain is less attractive to spammers and phishers. Because an SPF-protected domain is less attractive as a spoofed address, it is less likely to be denylisted by spam filters and so ultimately the legitimate email from the domain is more likely to get through.<ref>{{cite web|url=http://www.emailmanual.co.uk/index.php/2009/05/why-should-i-implement-a-spf-record-on-my-domain/ |title=Why should I implement a SPF record on my domain? |publisher=Email Manual |date=May 2009 |access-date=2010-01-01 |url-status=dead |archive-url=https://web.archive.org/web/20100129195805/http://www.emailmanual.co.uk/index.php/2009/05/why-should-i-implement-a-spf-record-on-my-domain |archive-date=January 29, 2010 }}</ref>

===FAIL and forwarding===
SPF breaks [[Email forwarding#Server-based forwarding|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" [[Mail transfer agent|MTA]] ([[MX record|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 [[Bounce message|error messages]] and other auto-replies, an SPF check of the [[Simple Mail Transfer Protocol#SMTP transport example|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 system]]s (any allow or deny list is a simple case of a reputation system).