Editing Sender Policy Framework (section)

==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>)
** [[Whitelisting|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.<ref name="rfc7208-txt" />
|-
| valign="top" | EXISTS || If the given domain name resolves to any address, match (no matter the address it resolves to). This is rarely used. Along with the SPF macro language it offers more complex matches like [[DNSBL]]-queries.
|-
| valign="top" | INCLUDE || References the policy of another domain. If that domain's policy passes, this mechanism passes. However, if the included policy fails, processing continues. To fully delegate to another domain's policy, the ''redirect'' extension must be used.
|}

===Qualifiers===
Each ''mechanism'' can be combined with one of four ''qualifiers'':
* '''<code>+</code>''' for a PASS result. This can be omitted; e.g., <code>+mx</code> is the same as <code>mx</code>.
* '''<code>?</code>''' for a NEUTRAL result interpreted like NONE (no policy).
* '''<code>~</code>''' (tilde) for SOFTFAIL, a debugging aid between NEUTRAL and FAIL. Typically, messages that return a SOFTFAIL are accepted but tagged.
* '''<code>-</code>''' (minus) for FAIL, the mail should be rejected (see below).

===Modifiers===
The ''modifiers'' allow for future extensions to the framework. To date only the two ''modifiers'' defined in the RFC 4408 have been widely deployed:
*<code>exp=some.example.com</code> gives the name of a domain with a [[Domain Name System|DNS]] TXT record (interpreted using SPF's macro language) to get an explanation for FAIL results—typically a [[Uniform Resource Locator|URL]] which is added to the SMTP error code. This feature is rarely used.
*<code>redirect=some.example.com</code> can be used instead of the ALL-''mechanism'' to link to the policy record of another domain. This ''modifier'' is easier to understand than the somewhat similar INCLUDE-''mechanism''.

===Error handling===
As soon as SPF implementations detect syntax errors in a sender policy they '''must''' abort the evaluation with result PERMERROR. Skipping erroneous ''mechanisms'' cannot work as expected, therefore <code>include:bad.example</code> and <code>redirect=bad.example</code> also cause a PERMERROR.

Another safeguard is the maximum of ten mechanisms querying DNS, i.e. any mechanism except from IP4, IP6, and ALL. Implementations can abort the evaluation with result TEMPERROR <!-- Section 4.4 of rfc7208 --> when it takes too long or a DNS query times out or they can continue pretending that the query returned no data <!-- Section 5 of rfc7208, last paragraph --> —which is called a "void lookup".  However, they '''must''' return PERMERROR if the policy directly or indirectly needs more than ten queries for ''mechanisms''.  In addition, they '''should''' <!-- Sections 4.6.4 and 11.1 of rfc7208 --> return PERMERROR as soon as more than two "void lookups" have been encountered.  Any <code>redirect=</code> also counts towards this ''processing limits''.<ref>{{cite web |first1=Steve |last1=Atkins|title=SPF: The rule of ten |url=https://wordtothewise.com/2016/03/spf-the-rule-of-ten/ |publisher=wordtothewise.com |access-date=2019-09-23|date=2016-03-14 | df = dmy-all }}</ref>

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.