idnits 2.17.1 draft-ietf-spfbis-4408bis-20.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. == There are 6 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 1 instance of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 1712 has weird spacing: '...pe-from the e...' == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (September 12, 2013) is 3877 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'CFWS' is mentioned on line 2398, but not defined ** Obsolete normative reference: RFC 5451 (Obsoleted by RFC 7001) ** Downref: Normative reference to an Informational RFC: RFC 5598 -- Possible downref: Non-RFC (?) normative reference: ref. 'US-ASCII' -- Obsolete informational reference (is this intentional?): RFC 2671 (Obsoleted by RFC 6891) -- Obsolete informational reference (is this intentional?): RFC 4408 (Obsoleted by RFC 7208) -- Obsolete informational reference (is this intentional?): RFC 5751 (Obsoleted by RFC 8551) Summary: 3 errors (**), 0 flaws (~~), 7 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Kitterman 3 Internet-Draft Kitterman Technical Services 4 Obsoletes: 4408 (if approved) September 12, 2013 5 Intended status: Standards Track 6 Expires: March 16, 2014 8 Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, 9 Version 1 10 draft-ietf-spfbis-4408bis-20 12 Abstract 14 Email on the Internet can be forged in a number of ways. In 15 particular, existing protocols place no restriction on what a sending 16 host can use as the "MAIL FROM" of a message or the domain given on 17 the SMTP HELO/EHLO commands. This document describes version 1 of 18 the Sender Policy Framework (SPF) protocol, whereby ADministrative 19 Management Domains (ADMDs) can explicitly authorize the hosts that 20 are allowed to use its domain names, and a receiving host can check 21 such authorization. 23 This document obsoletes RFC4408. 25 Status of this Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on March 16, 2014. 42 Copyright Notice 44 Copyright (c) 2013 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 This document may contain material from IETF Documents or IETF 58 Contributions published or made publicly available before November 59 10, 2008. The person(s) controlling the copyright in some of this 60 material may not have granted the IETF Trust the right to allow 61 modifications of such material outside the IETF Standards Process. 62 Without obtaining an adequate license from the person(s) controlling 63 the copyright in such materials, this document may not be modified 64 outside the IETF Standards Process, and derivative works of it may 65 not be created outside the IETF Standards Process, except to format 66 it for publication as an RFC or to translate it into languages other 67 than English. 69 Table of Contents 71 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6 72 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 73 1.1.1. Keywords . . . . . . . . . . . . . . . . . . . . . . . 6 74 1.1.2. Imported Definitions . . . . . . . . . . . . . . . . . 6 75 1.1.3. MAIL FROM Definition . . . . . . . . . . . . . . . . . 7 76 1.1.4. HELO Definition . . . . . . . . . . . . . . . . . . . 7 77 1.2. check_host() . . . . . . . . . . . . . . . . . . . . . . . 7 78 2. Operational Overview . . . . . . . . . . . . . . . . . . . . . 8 79 2.1. Publishing Authorization . . . . . . . . . . . . . . . . . 8 80 2.2. Checking Authorization . . . . . . . . . . . . . . . . . . 8 81 2.3. The "HELO" Identity . . . . . . . . . . . . . . . . . . . 9 82 2.4. The "MAIL FROM" Identity . . . . . . . . . . . . . . . . . 10 83 2.5. Location of Checks . . . . . . . . . . . . . . . . . . . . 10 84 2.6. Results of Evaluation . . . . . . . . . . . . . . . . . . 10 85 2.6.1. None . . . . . . . . . . . . . . . . . . . . . . . . . 11 86 2.6.2. Neutral . . . . . . . . . . . . . . . . . . . . . . . 11 87 2.6.3. Pass . . . . . . . . . . . . . . . . . . . . . . . . . 11 88 2.6.4. Fail . . . . . . . . . . . . . . . . . . . . . . . . . 11 89 2.6.5. Softfail . . . . . . . . . . . . . . . . . . . . . . . 11 90 2.6.6. Temperror . . . . . . . . . . . . . . . . . . . . . . 11 91 2.6.7. Permerror . . . . . . . . . . . . . . . . . . . . . . 11 92 3. SPF Records . . . . . . . . . . . . . . . . . . . . . . . . . 12 93 3.1. DNS Resource Records . . . . . . . . . . . . . . . . . . . 12 94 3.2. Multiple DNS Records . . . . . . . . . . . . . . . . . . . 13 95 3.3. Multiple Strings in a Single DNS record . . . . . . . . . 13 96 3.4. Record Size . . . . . . . . . . . . . . . . . . . . . . . 14 97 3.5. Wildcard Records . . . . . . . . . . . . . . . . . . . . . 14 98 4. The check_host() Function . . . . . . . . . . . . . . . . . . 16 99 4.1. Arguments . . . . . . . . . . . . . . . . . . . . . . . . 16 100 4.2. Results . . . . . . . . . . . . . . . . . . . . . . . . . 16 101 4.3. Initial Processing . . . . . . . . . . . . . . . . . . . . 17 102 4.4. Record Lookup . . . . . . . . . . . . . . . . . . . . . . 17 103 4.5. Selecting Records . . . . . . . . . . . . . . . . . . . . 17 104 4.6. Record Evaluation . . . . . . . . . . . . . . . . . . . . 17 105 4.6.1. Term Evaluation . . . . . . . . . . . . . . . . . . . 18 106 4.6.2. Mechanisms . . . . . . . . . . . . . . . . . . . . . . 18 107 4.6.3. Modifiers . . . . . . . . . . . . . . . . . . . . . . 19 108 4.6.4. DNS Lookup Limits . . . . . . . . . . . . . . . . . . 19 109 4.7. Default Result . . . . . . . . . . . . . . . . . . . . . . 20 110 4.8. Domain Specification . . . . . . . . . . . . . . . . . . . 20 111 5. Mechanism Definitions . . . . . . . . . . . . . . . . . . . . 22 112 5.1. "all" . . . . . . . . . . . . . . . . . . . . . . . . . . 23 113 5.2. "include" . . . . . . . . . . . . . . . . . . . . . . . . 23 114 5.3. "a" . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 115 5.4. "mx" . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 116 5.5. "ptr" (do not use) . . . . . . . . . . . . . . . . . . . . 25 117 5.6. "ip4" and "ip6" . . . . . . . . . . . . . . . . . . . . . 27 118 5.7. "exists" . . . . . . . . . . . . . . . . . . . . . . . . . 27 119 6. Modifier Definitions . . . . . . . . . . . . . . . . . . . . . 29 120 6.1. redirect: Redirected Query . . . . . . . . . . . . . . . . 29 121 6.2. exp: Explanation . . . . . . . . . . . . . . . . . . . . . 30 122 7. Macros . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 123 7.1. Formal Specification . . . . . . . . . . . . . . . . . . . 32 124 7.2. Macro Definitions . . . . . . . . . . . . . . . . . . . . 32 125 7.3. Macro Processing Details . . . . . . . . . . . . . . . . . 33 126 7.4. Expansion Examples . . . . . . . . . . . . . . . . . . . . 35 127 8. Result Handling . . . . . . . . . . . . . . . . . . . . . . . 37 128 8.1. None . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 129 8.2. Neutral . . . . . . . . . . . . . . . . . . . . . . . . . 37 130 8.3. Pass . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 131 8.4. Fail . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 132 8.5. Softfail . . . . . . . . . . . . . . . . . . . . . . . . . 38 133 8.6. Temperror . . . . . . . . . . . . . . . . . . . . . . . . 39 134 8.7. Permerror . . . . . . . . . . . . . . . . . . . . . . . . 39 135 9. Recording the Result . . . . . . . . . . . . . . . . . . . . . 40 136 9.1. The Received-SPF Header Field . . . . . . . . . . . . . . 40 137 9.2. SPF Results in the Authentication-Results Header Field . . 42 138 10. Effects on Infrastructure . . . . . . . . . . . . . . . . . . 44 139 10.1. Sending Domains . . . . . . . . . . . . . . . . . . . . . 44 140 10.1.1. DNS Resource Considerations . . . . . . . . . . . . . 44 141 10.1.2. Administrator's Considerations . . . . . . . . . . . . 45 142 10.1.3. Bounces . . . . . . . . . . . . . . . . . . . . . . . 46 143 10.2. Receivers . . . . . . . . . . . . . . . . . . . . . . . . 46 144 10.3. Mediators . . . . . . . . . . . . . . . . . . . . . . . . 46 145 11. Security Considerations . . . . . . . . . . . . . . . . . . . 48 146 11.1. Processing Limits . . . . . . . . . . . . . . . . . . . . 48 147 11.2. SPF-Authorized Email May Contain Other False Identities . 49 148 11.3. Spoofed DNS and IP Data . . . . . . . . . . . . . . . . . 49 149 11.4. Cross-User Forgery . . . . . . . . . . . . . . . . . . . . 49 150 11.5. Untrusted Information Sources . . . . . . . . . . . . . . 50 151 11.5.1. Recorded Results . . . . . . . . . . . . . . . . . . . 50 152 11.5.2. External Explanations . . . . . . . . . . . . . . . . 50 153 11.5.3. Macro Expansion . . . . . . . . . . . . . . . . . . . 51 154 11.6. Privacy Exposure . . . . . . . . . . . . . . . . . . . . . 51 155 11.7. Delivering Mail Producing a 'Fail' Result . . . . . . . . 51 156 12. Contributors and Acknowledgements . . . . . . . . . . . . . . 52 157 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 53 158 13.1. The SPF DNS Record Type . . . . . . . . . . . . . . . . . 53 159 13.2. The Received-SPF Mail Header Field . . . . . . . . . . . . 53 160 13.3. SPF Modifier Registry . . . . . . . . . . . . . . . . . . 53 161 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 54 162 14.1. Normative References . . . . . . . . . . . . . . . . . . . 54 163 14.2. Informative References . . . . . . . . . . . . . . . . . . 55 164 Appendix A. Collected ABNF . . . . . . . . . . . . . . . . . . . 57 165 Appendix B. Extended Examples . . . . . . . . . . . . . . . . . . 60 166 B.1. Simple Examples . . . . . . . . . . . . . . . . . . . . . 60 167 B.2. Multiple Domain Example . . . . . . . . . . . . . . . . . 61 168 B.3. DNSBL Style Example . . . . . . . . . . . . . . . . . . . 62 169 B.4. Multiple Requirements Example . . . . . . . . . . . . . . 62 170 Appendix C. Changes in implementation requirements from RFC 171 4408 . . . . . . . . . . . . . . . . . . . . . . . . 63 172 Appendix D. Further Testing Advice . . . . . . . . . . . . . . . 64 173 Appendix E. SPF/Mediator Interactions . . . . . . . . . . . . . . 65 174 E.1. Originating ADMDs . . . . . . . . . . . . . . . . . . . . 65 175 E.2. Mediators . . . . . . . . . . . . . . . . . . . . . . . . 66 176 E.3. Receving ADMDs . . . . . . . . . . . . . . . . . . . . . . 66 177 Appendix F. Mail Services . . . . . . . . . . . . . . . . . . . . 67 178 Appendix G. MTA Relays . . . . . . . . . . . . . . . . . . . . . 68 179 Appendix H. Local Policy Considerations . . . . . . . . . . . . . 69 180 H.1. Policy For SPF Pass . . . . . . . . . . . . . . . . . . . 69 181 H.2. Policy For SPF Fail . . . . . . . . . . . . . . . . . . . 69 182 H.3. Policy For SPF Permerror . . . . . . . . . . . . . . . . . 70 183 H.4. Policy For SPF Temperror . . . . . . . . . . . . . . . . . 70 184 Appendix I. Protocol Status . . . . . . . . . . . . . . . . . . . 72 185 Appendix J. Change History . . . . . . . . . . . . . . . . . . . 73 186 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 76 188 1. Introduction 190 The current email infrastructure has the property that any host 191 injecting mail into the system can use any DNS domain name it wants 192 in each of the various identifiers specified by [RFC5321] and 193 [RFC5322]. Although this feature is desirable in some circumstances, 194 it is a major obstacle to reducing Unsolicited Bulk Email (UBE, aka 195 spam). Furthermore, many domain owning ADMDs (as described in 196 [RFC5598]) are understandably concerned about the ease with which 197 other entities can make use of their domain names, often with 198 malicious intent. 200 This document defines a protocol by which ADMDs can authorize hosts 201 to use their domain names in the "MAIL FROM" or "HELO" identities. 202 Compliant ADMDs publish Sender Policy Framework (SPF) records in the 203 DNS specifying which hosts are permitted to use their names, and 204 compliant mail receivers use the published SPF records to test the 205 authorization of sending Mail Transfer Agents (MTAs) using a given 206 "HELO" or "MAIL FROM" identity during a mail transaction. 208 An additional benefit to mail receivers is that after the use of an 209 identity is verified, local policy decisions about the mail can be 210 made based on the sender's domain, rather than the host's IP address. 211 This is advantageous because reputation of domain names is likely to 212 be more accurate than reputation of host IP addresses since domains 213 are likely to be more stable over a longer period. Furthermore, if a 214 claimed identity fails verification, local policy can take stronger 215 action against such email, such as rejecting it. 217 1.1. Terminology 219 1.1.1. Keywords 221 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 222 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 223 "OPTIONAL" in this document are to be interpreted as described in 224 [RFC2119]. 226 1.1.2. Imported Definitions 228 ABNF (Augmented Backus-Naur Form) ABNF is defined in [RFC5234], as 229 are the tokens "ALPHA", "DIGIT", and "SP" (space). 231 The tokens "Local-part", "Domain", and "Mailbox are defined in 232 [RFC5321]. 234 "dot-atom", "quoted-string", "comment", "CFWS" (comment folded white 235 space), "FWS" (folded white space), and "CRLF" (carriage-return/ 236 line-feed) are defined in [RFC5322]. 238 1.1.3. MAIL FROM Definition 240 This document is concerned with the portion of a mail message 241 commonly called "envelope sender", "return path", "reverse path", 242 "bounce address", "5321 FROM", "MAIL FROM", or RFC5321.MailFrom. 243 Since these terms are either not well defined or often used casually, 244 this document uses "MAIL FROM" for consistency. This means the 245 RFC5321.MailFrom as defined in [RFC5598]. Note that other terms that 246 might superficially look like the common terms, such as 'reverse- 247 path', are used only as they are specified in their defining 248 documents. 250 1.1.4. HELO Definition 252 This document also makes use of the HELO/EHLO identity. The "HELO" 253 identity derives from either the SMTP HELO or EHLO command (see 254 [RFC5321]). Since HELO and EHLO can, in many cases, be used 255 interchangeably, they are identified commonly as "HELO" in this 256 document. This means RFC5321.HELO/.EHLO as defined in [RFC5598]. 257 These commands supply the identity of the SMTP client (sending host) 258 for the SMTP session. 260 1.2. check_host() 262 Section 4 introduces an algorithm to evaluate an SPF policy against 263 an arriving email transaction. In an early implementation, this 264 algorithm was encoded in a function called check_host(). That name 265 is used in this document as symbolic of the SPF evaluation algorithm, 266 but of course implementers are not required to use this name. 268 2. Operational Overview 270 2.1. Publishing Authorization 272 An SPF-compliant domain publishes valid SPF records as described in 273 Section 3. These records authorize the use of the relevant domain 274 names in the "HELO" and "MAIL FROM" identities by the MTAs specified 275 therein. 277 SPF results can be used to make both positive (source is authorized) 278 and negative (source is not authorized) determinations. If ADMDs 279 choose to publish SPF records and want to support receivers making 280 negative authorization determinations, it is necessary for them to 281 publish records that end in "-all", or redirect to other records that 282 do, otherwise, no definitive determination of authorization can be 283 made. Potential issues and mitigations associated with negative 284 determinations are discussed in Section 10. 286 ADMDs that wish to declare that no hosts are authorized to use their 287 DNS domain names in the HELO or MAIL FROM commands during SMTP 288 sessions can publish SPF records that say so for domain names that 289 are neither used in the domain part of email addresses nor expected 290 to originate mail. 292 When changing SPF records, care has to be taken to ensure that there 293 is a transition period so that the old policy remains valid until all 294 legitimate email can reasonably expect to have been checked. 295 [RFC5321] Section 4.5.4.1 discusses how long a message might be in 296 transit. While offline checks are possible, the closer to the 297 original transmission time checks are performed, the more likely they 298 are to get an SPF result that matches the sending ADMD intent at the 299 time the message was sent. 301 2.2. Checking Authorization 303 A mail receiver can perform a set of SPF checks for each mail message 304 it receives. An SPF check tests the authorization of a client host 305 to emit mail with a given identity. Typically, such checks are done 306 by a receiving MTA, but can be performed elsewhere in the mail 307 processing chain so long as the required information is available and 308 reliable. The "MAIL FROM" and "HELO" identities are checked as 309 described in Section 2.4 and Section 2.3 respectively. 311 Without explicit approval of the publishing ADMD, checking other 312 identities against SPF version 1 records is NOT RECOMMENDED because 313 there are cases that are known to give incorrect results. For 314 example, almost all mailing lists rewrite the "MAIL FROM" identity 315 (see Section 10.3), but some do not change any other identities in 316 the message. Documents that define other identities will have to 317 define the method for explicit approval. 319 It is possible that mail receivers will use the SPF check as part of 320 a larger set of tests on incoming mail. The results of other tests 321 might influence whether or not a particular SPF check is performed. 322 For example, finding the sending host's IP address on a local white 323 list might cause all other tests to be skipped and all mail from that 324 host to be accepted. 326 When a mail receiver decides to perform an SPF check, it has to use a 327 correctly-implemented check_host() function (Section 4) evaluated 328 with the correct parameters. Although the test as a whole is 329 optional, once it has been decided to perform a test it has to be 330 performed as specified so that the correct semantics are preserved 331 between publisher and receiver. 333 To make the test, the mail receiver MUST evaluate the check_host() 334 function with the arguments described in Section 4.1. 336 Although invalid, malformed, or non-existent domains cause SPF checks 337 to return "none" because no SPF record can be found, it has long been 338 the policy of many MTAs to reject email from such domains, especially 339 in the case of invalid "MAIL FROM". Rejecting email will prevent one 340 method of circumventing of SPF records. 342 Implementations have to take care to correctly extract the 343 from the data given with the SMTP MAIL FROM command as many MTAs will 344 still accept such things as source routes (see [RFC5321], Appendix 345 C), the %-hack (see [RFC1123]), and bang paths (see [RFC1983]). 346 These archaic features have been maliciously used to bypass security 347 systems. 349 2.3. The "HELO" Identity 351 It is RECOMMENDED that SPF verifiers not only check the "MAIL FROM" 352 identity, but also separately check the "HELO" identity by applying 353 the check_host() function (Section 4) to the "HELO" identity as the 354 . Checking "HELO" promotes consistency of results and can 355 reduce DNS resource usage. If a conclusive determination about the 356 message can be made based on a check of "HELO", then the use of DNS 357 resources to process the typically more complex "MAIL FROM" can be 358 avoided. Additionally, since SPF records published for "HELO" 359 identities refer to a single host, when available, they are a very 360 reliable source of host authorization status. Checking "HELO" before 361 "MAIL FROM" is the RECOMMENDED sequence if both are checked. 363 Note that requirements for the domain presented in the EHLO or HELO 364 command are not always clear to the sending party, and SPF verifiers 365 have to be prepared for the identity to be an IP address literal (see 366 [RFC5321] section 4.1.3), or simply be malformed. This SPF check can 367 only be performed when the "HELO" string is a valid, multi-label 368 domain name. 370 2.4. The "MAIL FROM" Identity 372 SPF verifiers MUST check the "MAIL FROM" identity if a "HELO" check 373 has either not been performed or has not reached a definitive policy 374 result by applying the check_host() function to the "MAIL FROM" 375 identity as the . 377 [RFC5321] allows the reverse-path to be null (see Section 4.5.5 in 378 [RFC5321]). In this case, there is no explicit sender mailbox, and 379 such a message can be assumed to be a notification message from the 380 mail system itself. When the reverse-path is null, this document 381 defines the "MAIL FROM" identity to be the mailbox composed of the 382 local-part "postmaster" and the "HELO" identity (which might or might 383 not have been checked separately before). 385 2.5. Location of Checks 387 The authorization check SHOULD be performed during the processing of 388 the SMTP transaction that receives the mail. This reduces the 389 complexity of determining the correct IP address to use as an input 390 to check_host() and allows errors to be returned directly to the 391 sending MTA by way of SMTP replies. Appendix C of [RFC5451] provides 392 a more thorough discussion of this topic. 394 Performing the authorization check other than using the MAIL FROM and 395 client address at the time of the MAIL command during the SMTP 396 transaction can cause problems, such as the following: (1) It might 397 be difficult to accurately extract the required information from 398 potentially deceptive headers; (2) legitimate email might fail 399 because the sender's policy had since changed. 401 Generating non-delivery notifications to forged identities that have 402 failed the authorization check often constitutes backscatter, i.e., 403 inactionable, nuisance rejection notices. Operators are strongly 404 advised to avoid such practices. Section 2 of [RFC3834] describes 405 backscatter and the problems it causes. 407 2.6. Results of Evaluation 409 Section 4 defines check_host(), a model function definition that uses 410 the inputs defined above and the sender's policy published in the DNS 411 to reach a conclusion about client authorization. An SPF verifier 412 implements something semantically equivalent to the function defined 413 there. 415 This section enumerates and briefly defines the possible outputs of 416 that function. Note, however, that the protocol establishes no 417 normative requirements for handling any particular result. 418 Discussion of handling options for each result can be found in 419 Section 8. 421 2.6.1. None 423 A result of "none" means either (a) no syntactically valid DNS domain 424 name was extracted from the SMTP session that could be used as the 425 one to be authorized, or (b) no SPF records were retrieved from the 426 DNS. 428 2.6.2. Neutral 430 The ADMD has explicitly stated that it is not asserting whether the 431 IP address is authorized. 433 2.6.3. Pass 435 A "pass" result means that the client is authorized to inject mail 436 with the given identity. 438 2.6.4. Fail 440 A "fail" result is an explicit statement that the client is not 441 authorized to use the domain in the given identity. 443 2.6.5. Softfail 445 The ADMD has published a weak statement that the host is probably not 446 authorized. It has not published a stronger, more definitive policy 447 that results in a "fail". 449 2.6.6. Temperror 451 A "temperror" result means the SPF verifier encountered a transient 452 (generally DNS) error while performing the check. A later retry may 453 succeed without further DNS operator action. 455 2.6.7. Permerror 457 A "permerror" result means the domain's published records could not 458 be correctly interpreted. This signals an error condition that 459 definitely requires DNS operator intervention to be resolved. 461 3. SPF Records 463 An SPF record is a DNS record that declares which hosts are, and are 464 not, authorized to use a domain name for the "HELO" and "MAIL FROM" 465 identities. Loosely, the record partitions hosts into permitted and 466 not-permitted sets (though some hosts might fall into neither 467 category). 469 The SPF record is expressed as a single string of text found in the 470 RDATA of a single DNS TXT resource record; multiple SPF records are 471 not permitted for the same owner name. The record format and the 472 process for selecting records is described below in Section 4. An 473 example record is the following: 475 v=spf1 +mx a:colo.example.com/28 -all 477 This record has a version of "spf1" and three directives: "+mx", 478 "a:colo.example.com/28" (the + is implied), and "-all". 480 Each SPF record is placed in the DNS tree at the owner name it 481 pertains to, not a subdomain under it, such as is done with SRV 482 records [RFC2782]. 484 The example in this section might be published via these lines in a 485 domain zone file: 487 example.com. TXT "v=spf1 +mx a:colo.example.com/28 -all" 489 Since TXT records have multiple uses, beware of other TXT records 490 published there for other purposes. They might cause problems with 491 size limits (see Section 3.4) and care has to be taken to ensure only 492 SPF records are used for SPF processing. 494 ADMDs publishing SPF records ought to keep the amount of DNS 495 information needed to evaluate a record to a minimum. Section 4.6.4 496 and Section 10.1.1 provide some suggestions about "include" 497 mechanisms and chained "redirect" modifiers. 499 3.1. DNS Resource Records 501 SPF records MUST be published as a DNS TXT (type 16) Resource Record 502 (RR) [RFC1035] only. The character content of the record is encoded 503 as [US-ASCII]. Use of alternative DNS RR types was supported in 504 SPF's experimental phase, but has been discontinued. 506 In 2003, when SPF was first being developed, the requirements for 507 assignment of a new DNS RR type were considerably more stringent than 508 they are now. Additionally, support for easy deployment of new DNS 509 RR types was not widely deployed in DNS servers and provisioning 510 systems. As a result, developers of SPF found it easier and more 511 practical to use the TXT RR type for SPF records. 513 In its review of [RFC4408] the SPFbis working group concluded that 514 its dual RR type transition model was fundamentally flawed since it 515 contained no common RR type that implementers were required to serve 516 and required to check. Many alternatives were considered to resolve 517 this issue, but ultimately the working group concluded that 518 significant migration to the SPF RR type in the foreseeable future was 519 very unlikely and that the best solution for resolving this 520 interoperability issue was to drop support for the SPF RR type from 521 SPF version 1. See Appendix A of [RFC6686] for further information. 523 The circumstances surrounding SPF's initial deployment a decade ago 524 are unique. If a future update to SPF were developed that did not 525 reuse existing SPF records, it could use the SPF RR type. SPF's use 526 of the TXT RR type for structured data should in no way be taken as 527 precedent for future protocol designers. Further discussion of 528 design considerations when using new DNS RR types can be found in 529 [RFC5507]. 531 3.2. Multiple DNS Records 533 A domain name MUST NOT have multiple records that would cause an 534 authorization check to select more than one record. See Section 4.5 535 for the selection rules. 537 3.3. Multiple Strings in a Single DNS record 539 As defined in [RFC1035] sections 3.3 and 3.3.14, a single text DNS 540 record can be composed of more than one string. If a published 541 record contains multiple character-strings, then the record MUST be 542 treated as if those strings are concatenated together without adding 543 spaces. For example: 545 IN TXT "v=spf1 .... first" "second string..." 547 is equivalent to: 549 IN TXT "v=spf1 .... firstsecond string..." 551 TXT records containing multiple strings are useful in constructing 552 records that would exceed the 255-octet maximum length of a 553 character-string within a single TXT record. 555 3.4. Record Size 557 The published SPF record for a given domain name SHOULD remain small 558 enough that the results of a query for it will fit within 512 octets. 559 This UDP limit is defined in [RFC1035] section 2.3.4, although it was 560 raised by [RFC2671]. Staying below 512 octets ought to prevent older 561 DNS implementations from failing over to TCP,and will work with UDP 562 in the absence of EDNS0 [RFC6891] support. Since the answer size is 563 dependent on many things outside the scope of this document, it is 564 only possible to give this guideline: If the size of the DNS message, 565 the combined length of the DNS name and the text of all the records 566 of a given type is under 450 octets, then DNS answers ought to fit in 567 UDP packets. Records that are too long to fit in a single UDP packet 568 could be silently ignored by SPF verifiers due to firewall and other 569 issues that interfere with the operation of DNS over TCP or using 570 ENDS0. 572 Note that when computing the sizes for replies to queries of the TXT 573 format, one has to take into account any other TXT records published 574 at the domain name. Similarly, the sizes for replies to all queries 575 related to SPF have to be evaluated to fit in a single 512 octet UDP 576 packet (i.e. DNS message size limited to 450 octects). 578 3.5. Wildcard Records 580 Use of wildcard records for publishing is discouraged and care has to 581 be taken if they are used. If a zone includes wildcard MX records, 582 it might want to publish wildcard declarations, subject to the same 583 requirements and problems. In particular, the declaration MUST be 584 repeated for any host that has any RR records at all, and for 585 subdomains thereof. Consider the example in [RFC1034], Section 586 4.3.3. Based on that, we can do the following: 588 EXAMPLE.COM. MX 10 A.EXAMPLE.COM 589 EXAMPLE.COM. TXT "v=spf1 a:A.EXAMPLE.COM -all" 591 *.EXAMPLE.COM. MX 10 A.EXAMPLE.COM 592 *.EXAMPLE.COM. TXT "v=spf1 a:A.EXAMPLE.COM -all" 594 A.EXAMPLE.COM. A 203.0.113.1 595 A.EXAMPLE.COM. MX 10 A.EXAMPLE.COM 596 A.EXAMPLE.COM. TXT "v=spf1 a:A.EXAMPLE.COM -all" 598 *.A.EXAMPLE.COM. MX 10 A.EXAMPLE.COM 599 *.A.EXAMPLE.COM. TXT "v=spf1 a:A.EXAMPLE.COM -all" 601 SPF records have to be listed twice for every name within the zone: 602 once for the name, and once with a wildcard to cover the tree under 603 the name, in order to cover all domains in use in outgoing mail. 605 4. The check_host() Function 607 This description is not an API (Application Program Interface) 608 definition, but rather a function description used to illustrate the 609 algorithm. A compliant SPF implementation MUST produce results 610 semantically equivalent to this description. 612 The check_host() function fetches SPF records, parses them, and 613 evaluates them to determine whether a particular host is or is not 614 permitted to send mail with a given identity. Receiving ADMDs that 615 perform this check MUST correctly evaluate the check_host() function 616 as described here. 618 Implementations MAY use a different algorithm than the canonical 619 algorithm defined here, so long as the results are the same in all 620 cases. 622 4.1. Arguments 624 The check_host() function takes these arguments: 626 - the IP address of the SMTP client that is emitting the 627 mail, either IPv4 or IPv6. 629 - the domain that provides the sought-after authorization 630 information; initially, the domain portion of the "MAIL 631 FROM" or "HELO" identity. 633 - the "MAIL FROM" or "HELO" identity. 635 For recursive evaluations, the domain portion of might not 636 be the same as the argument when check_host() is initially 637 evaluated. In most other cases it will be the same. (See 638 Section 5.2 below). 640 Note that the argument might not be a well-formed domain 641 name. For example, if the reverse-path was null, then the EHLO/HELO 642 domain is used, with its associated problems (see Section 2.3). In 643 these cases, check_host() is defined in Section 4.3 to return a 644 "none" result. 646 4.2. Results 648 The function check_host() can return one of several results described 649 in Section 2.6. Based on the result, the action to be taken is 650 determined by the local policies of the receiver. This is discussed 651 in Section 8. 653 4.3. Initial Processing 655 If the is malformed (e.g. label longer than 63 characters, 656 zero-length label not at the end, etc.) or is not a multi-label 657 domain name, or if the DNS lookup returns "domain does not exist" 658 (RCODE 3), check_host() immediately returns the result "none". DNS 659 RCODES are defined in [RFC1035]. Properly formed domains are fully 660 qualified domains as defined in [RFC1983]. That is, in the DNS they 661 are implicitly qualified relative to the root (see section 3.1 of 662 [RFC1034]). Internationalized domain names MUST be encoded as 663 A-labels, as described in Section 2.3 of [RFC5890]. 665 If the has no local-part, substitute the string "postmaster" 666 for the local-part. 668 4.4. Record Lookup 670 In accordance with how the records are published (see Section 3 671 above), a DNS query needs to be made for the name, querying 672 for type TXT only. 674 If the DNS lookup returns a server failure (RCODE 2), or other error 675 (RCODE other than 0 or 3), or time out, then check_host() terminates 676 immediately with the result "temperror". 678 4.5. Selecting Records 680 Records begin with a version section: 682 record = version terms *SP 683 version = "v=spf1" 685 Starting with the set of records that were returned by the lookup, 686 discard records that do not begin with a version section of exactly 687 "v=spf1". Note that the version section is terminated either by an 688 SP character or the end of the record. As an example, a record with 689 a version section of "v=spf10" does not match and is discarded. 691 If the resultant record set includes no records, check_host() 692 produces the "none" result. If the resultant record set includes 693 more than one record, check_host() produces the "permerror" result. 695 4.6. Record Evaluation 697 The check_host() function parses and interprets the SPF record to 698 find a result for the current test. If there are any syntax errors 699 anywhere in the record, check_host() returns immediately with the 700 result "permerror", without further interpretation. 702 4.6.1. Term Evaluation 704 There are two types of terms: mechanisms (defined in Section 5) and 705 modifiers (defined in Section 6). A record contains an ordered list 706 of these as specified in the following Augmented Backus-Naur Form 707 (ABNF). 709 terms = *( 1*SP ( directive / modifier ) ) 711 directive = [ qualifier ] mechanism 712 qualifier = "+" / "-" / "?" / "~" 713 mechanism = ( all / include 714 / a / mx / ptr / ip4 / ip6 / exists ) 715 modifier = redirect / explanation / unknown-modifier 716 unknown-modifier = name "=" macro-string 717 ; where name is not any known modifier 719 name = ALPHA *( ALPHA / DIGIT / "-" / "_" / "." ) 721 Most mechanisms allow a ":" or "/" character after the name. 723 Modifiers always contain an equals ('=') character immediately after 724 the name, and before any ":" or "/" characters that might be part of 725 the macro-string. 727 Terms that do not contain any of "=", ":", or "/" are mechanisms, as 728 defined in Section 5. 730 As per the definition of the ABNF notation in [RFC5234], mechanism 731 and modifier names are case-insensitive. 733 4.6.2. Mechanisms 735 Each mechanism is considered in turn from left to right. If there 736 are no more mechanisms, the result is the default result as described 737 in Section 4.7. 739 When a mechanism is evaluated, one of three things can happen: it can 740 match, not match, or return an exception. 742 If it matches, processing ends and the qualifier value is returned as 743 the result of that record. If it does not match, processing 744 continues with the next mechanism. If it returns an exception, 745 mechanism processing ends and the exception value is returned. 747 The possible qualifiers, and the results they cause check_host() to 748 return are as follows: 750 "+" pass 751 "-" fail 752 "~" softfail 753 "?" neutral 755 The qualifier is optional and defaults to "+". 757 When a mechanism matches and the qualifier is "-", then a "fail" 758 result is returned and the explanation string is computed as 759 described in Section 6.2. 761 The specific mechanisms are described in Section 5. 763 4.6.3. Modifiers 765 Modifiers are not mechanisms. They do not return match or not-match. 766 Instead, they provide additional information. Although modifiers do 767 not directly affect the evaluation of the record, the "redirect" 768 modifier has an effect after all the mechanisms have been evaluated. 770 4.6.4. DNS Lookup Limits 772 Some mechanisms and modifiers (collectively, "terms") cause DNS 773 queries at the time of evaluation, and some do not. The following 774 terms cause DNS queries: the "include", "a", "mx", "ptr", and 775 "exists" mechanisms and the "redirect" modifier. SPF implementations 776 MUST limit the total number of those terms to 10 during SPF 777 evaluation, to avoid unreasonable load on the DNS. If this limit is 778 exceeded, the implementation MUST return "permerror". The other 779 terms: the "all", "ip4", and "ip6" mechanisms do not cause DNS 780 queries at the time of SPF evaluation (the "exp" modifier causes a 781 lookup at a later time), and their use, including "exp", is not 782 subject to this limit. 784 When evaluating the "mx" mechanism, the number of "MX" resource 785 records queried is included in the overall limit of 10 mechanisms/ 786 modifiers that cause DNS lookups described above. The evaluation of 787 each "MX" record MUST NOT result in querying more than 10 address 788 records, either "A" or "AAAA" resource records. If this limit is 789 exceeded, the "mx" mechanism MUST produce a "permerror" result. 791 When evaluating the "ptr" mechanism or the %{p} macro, the number of 792 "PTR" resource records queried is included in the overall limit of 10 793 mechanisms/modifiers that cause DNS lookups described above. The 794 evaluation of each "PTR" record MUST NOT result in querying more than 795 10 address records, either "A" or "AAAA" resource records. If this 796 limit is exceeded, all records other than the first 10 MUST be 797 ignored. 799 The reason for the disparity is that the set of and contents of the 800 MX record are under control of the publishing ADMD, while the set of 801 and contents of PTR records are under control of the owner of the IP 802 address actually making the connection. 804 These limits are per mechanism or macro in the record, and are in 805 addition to the lookup limits specified above. 807 MTAs or other processors SHOULD impose a limit on the maximum amount 808 of elapsed time to evaluate check_host(). Such a limit SHOULD allow 809 at least 20 seconds. If such a limit is exceeded, the result of 810 authorization SHOULD be "temperror". 812 As described at the end of Section 11.1, there may be cases where it 813 is useful to limit the number of "terms" for which DNS queries return 814 either a positive answer (RCODE 0) with an answer count of 0, or a no 815 such record (RCODE 3) answer. These are sometimes collectively 816 referred to as "void lookups". SPF implementations SHOULD limit 817 "void lookups" to two. An implementation MAY choose to make such a 818 limit configurable. In this case, a default of two is RECOMMENDED. 820 4.7. Default Result 822 If none of the mechanisms match and there is no "redirect" modifier, 823 then the check_host() returns a result of "neutral", just as if 824 "?all" were specified as the last directive. If there is a 825 "redirect" modifier, check_host() proceeds as defined in Section 6.1. 827 It is better to use either a "redirect" modifier or an "all" 828 mechanism to explicitly terminate processing. Although there is an 829 implicit "?all" at the end of every record that is not explicitly 830 terminated, it aids debugging efforts when it is explicitly provided. 832 For example: 834 v=spf1 +mx -all 835 or 836 v=spf1 +mx redirect=_spf.example.com 838 4.8. Domain Specification 840 Several of these mechanisms and modifiers have a domain-spec section. 841 The domain-spec string is subject to macro expansion (see Section 7). 842 The resulting string is the common presentation form of a fully- 843 qualified DNS name: a series of labels separated by periods. This 844 domain is called the in the rest of this document. 846 Note: The result of the macro expansion is not subject to any further 847 escaping. Hence, this facility cannot produce all characters that 848 are legal in a DNS label (e.g., the control characters). However, 849 this facility is powerful enough to express legal host names and 850 common utility labels (such as "_spf") that are used in DNS. 852 For several mechanisms, the domain-spec is optional. If it is not 853 provided, the from the check_host() arguments (see 854 Section 4.1) is used as the . "domain" and domain-spec 855 are syntactically identical after macro expansion. "domain" is an 856 input value for check_host() while domain-spec is computed by 857 check_host(). 859 The result of evaluating check_host() with a syntactically invalid 860 domain is undefined. 862 5. Mechanism Definitions 864 This section defines two types of mechanisms: basic language 865 framework mechanisms and designated sender mechanisms. 867 Basic mechanisms contribute to the language framework. They do not 868 specify a particular type of authorization scheme. 870 all 871 include 873 Designated sender mechanisms are used to identify a set of 874 addresses as being permitted or not permitted to use the for 875 sending mail. 877 a 878 mx 879 ptr (do not publish) 880 ip4 881 ip6 882 exists 884 The following conventions apply to all mechanisms that perform a 885 comparison between and an IP address at any point: 887 If no CIDR prefix length is given in the directive, then and the 888 IP address are compared for equality. (Here, CIDR is Classless 889 Inter-Domain Routing, described in [RFC4632].) 891 If a CIDR prefix length is specified, then only the specified number 892 of high-order bits of and the IP address are compared for 893 equality. 895 When any mechanism fetches host addresses to compare with , when 896 is an IPv4, "A" records are fetched; when is an IPv6 897 address, "AAAA" records are fetched. SPF implementations on IPv6 898 servers need to handle both "AAAA" and "A" records, for clients on 899 IPv4 mapped IPv6 addresses [RFC4291]. IPv4 addresses are only 900 listed in an SPF record using the "ip4" mechanism. 902 Several mechanisms rely on information fetched from the DNS. For 903 these DNS queries, except where noted, if the DNS server returns an 904 error (RCODE other than 0 or 3) or the query times out, the mechanism 905 stops and the topmost check_host() returns "temperror". If the 906 server returns "domain does not exist" (RCODE 3), then evaluation of 907 the mechanism continues as if the server returned no error (RCODE 0) 908 and zero answer records. 910 5.1. "all" 912 all = "all" 914 The "all" mechanism is a test that always matches. It is used as the 915 rightmost mechanism in a record to provide an explicit default. 917 For example: 919 v=spf1 a mx -all 921 Mechanisms after "all" will never be tested. Mechanisms listed after 922 "all" MUST be ignored. Any "redirect" modifier (Section 6.1) MUST be 923 ignored when there is an "all" mechanism in the record. 925 5.2. "include" 927 include = "include" ":" domain-spec 929 The "include" mechanism triggers a recursive evaluation of 930 check_host(). 932 1. The domain-spec is expanded as per Section 7. 934 2. check_host() is evaluated with the resulting string as the 935 . The and arguments remain the same as in 936 the current evaluation of check_host(). 938 3. The recursive evaluation returns either match, not match, or an 939 error. If it matches, then the appropriate result for the 940 include: mechanism is used (e.g. include or +include produces a 941 "pass" result and -include produces "fail"). 943 4. If there is no match, the parent check_host() resumes processing 944 as per the table below, with the previous value of 945 restored. 947 In hindsight, the name "include" was poorly chosen. Only the 948 evaluated result of the referenced SPF record is used, rather than 949 literally including the mechanisms of the referenced record in the 950 first. For example, evaluating a "-all" directive in the referenced 951 record does not terminate the overall processing and does not 952 necessarily result in an overall "fail". (Better names for this 953 mechanism would have been "if-match", "on-match", etc.) 955 The "include" mechanism makes it possible for one domain to designate 956 multiple administratively-independent domains. For example, a vanity 957 domain "example.net" might send mail using the servers of 958 administratively-independent domains example.com and example.org. 960 Example.net could say 962 IN TXT "v=spf1 include:example.com include:example.org -all" 964 This would direct check_host() to, in effect, check the records of 965 example.com and example.org for a "pass" result. Only if the host 966 were not permitted for either of those domains would the result be 967 "fail". 969 Whether this mechanism matches, does not match, or returns an 970 exception depends on the result of the recursive evaluation of 971 check_host(): 973 +---------------------------------+---------------------------------+ 974 | A recursive check_host() result | Causes the "include" mechanism | 975 | of: | to: | 976 +---------------------------------+---------------------------------+ 977 | pass | match | 978 | | | 979 | fail | not match | 980 | | | 981 | softfail | not match | 982 | | | 983 | neutral | not match | 984 | | | 985 | temperror | return temperror | 986 | | | 987 | permerror | return permerror | 988 | | | 989 | none | return permerror | 990 +---------------------------------+---------------------------------+ 992 The "include" mechanism is intended for crossing administrative 993 boundaries. For example, if example.com and example.org were managed 994 by the same entity, and if the permitted set of hosts for both 995 domains was "mx:example.com", it would be possible for example.org to 996 specify "include:example.com", but it would be preferable to specify 997 "redirect=example.com" or even "mx:example.com". 999 With the "include" mechanism an administratively external set of 1000 hosts can be authorized, but determination of sender policy is still 1001 a function of the original domain's SPF record (as determined by the 1002 "all" mechanism in that record). The redirect modifier is more 1003 suitable for consolidating both authorizations and policy into a 1004 common set to be shared within an ADMD. Redirect is much more like a 1005 common code element to be shared among records in a single ADMD. It 1006 is possible to control both authorized hosts and policy for an 1007 arbitrary number of domains from a single record. 1009 5.3. "a" 1011 This mechanism matches if is one of the 's IP 1012 addresses. For clarity, this means the "a" mechanism also matches 1013 AAAA records. 1015 a = "a" [ ":" domain-spec ] [ dual-cidr-length ] 1017 An address lookup is done on the using the type of 1018 lookup (A or AAAA) appropriate for the connection type (IPv4 or 1019 IPv6). The is compared to the returned address(es). If any 1020 address matches, the mechanism matches. 1022 5.4. "mx" 1024 This mechanism matches if is one of the MX hosts for a domain 1025 name. 1027 mx = "mx" [ ":" domain-spec ] [ dual-cidr-length ] 1029 check_host() first performs an MX lookup on the . Then 1030 it performs an address lookup on each MX name returned. The is 1031 compared to each returned IP address. To prevent Denial of Service 1032 (DoS) attacks, the processing limits defined in Section 4.6.4 MUST be 1033 followed. If the MX lookup limit is exceeded, then "permerror" is 1034 returned and the evaluation is terminated. If any address matches, 1035 the mechanism matches. 1037 Note regarding implicit MXes: If the has no MX record, 1038 check_host() MUST NOT apply the implicit MX rules of[RFC5321] by 1039 querying for an A or AAAA record for the same name. 1041 5.5. "ptr" (do not use) 1043 This mechanism tests whether the DNS reverse-mapping for exists 1044 and correctly points to a domain name within a particular domain. 1045 This mechanism SHOULD NOT be published. See the note at the end of 1046 this section for more information. 1048 ptr = "ptr" [ ":" domain-spec ] 1050 The 's name is looked up using this procedure: 1052 o Perform a DNS reverse-mapping for : Look up the corresponding 1053 PTR record in "in-addr.arpa." if the address is an IPv4 one and in 1054 "ip6.arpa." if it is an IPv6 address. 1056 o For each record returned, validate the domain name by looking up 1057 its IP addresses. To prevent DoS attacks, the PTR processing 1058 limits defined in Section 4.6.4 MUST be applied. If they are 1059 exceeded, processing is terminated and the mechanism does not 1060 match. 1062 o If is among the returned IP addresses, then that domain name 1063 is validated. 1065 Check all validated domain names to see if they either match the 1066 domain or are a subdomain of the domain. 1067 If any do, this mechanism matches. If no validated domain name can 1068 be found, or if none of the validated domain names match or are a 1069 subdomain of the , this mechanism fails to match. If a 1070 DNS error occurs while doing the PTR RR lookup, then this mechanism 1071 fails to match. If a DNS error occurs while doing an A RR lookup, 1072 then that domain name is skipped and the search continues. 1074 Pseudocode: 1076 sending-domain_names := ptr_lookup(sending-host_IP); 1077 if more than 10 sending-domain_names are found, use at most 10. 1078 for each name in (sending-domain_names) { 1079 IP_addresses := a_lookup(name); 1080 if the sending-domain_IP is one of the IP_addresses { 1081 validated-sending-domain_names += name; 1082 } 1083 } 1085 for each name in (validated-sending-domain_names) { 1086 if name ends in , return match. 1087 if name is , return match. 1088 } 1089 return no-match. 1091 This mechanism matches if the is either a subdomain of 1092 a validated domain name or if the and a validated 1093 domain name are the same. For example: "mail.example.com" is within 1094 the domain "example.com", but "mail.bad-example.com" is not. 1096 Note: This mechanism is slow, it is not as reliable as other 1097 mechanisms in cases of DNS errors, and it places a large burden on 1098 the .arpa name servers. If used, proper PTR records have to be in 1099 place for the domain's hosts and the "ptr" mechanism SHOULD be one of 1100 the last mechanisms checked. After many years of SPF deployment 1101 experience, it has been concluded it is unnecessary and more reliable 1102 alternatives should be used instead. It is, however, still in use as 1103 part of the SPF protocol, so compliant check_host() implementations 1104 MUST support it. 1106 5.6. "ip4" and "ip6" 1108 These mechanisms test whether is contained within a given IP 1109 network. 1111 ip4 = "ip4" ":" ip4-network [ ip4-cidr-length ] 1112 ip6 = "ip6" ":" ip6-network [ ip6-cidr-length ] 1114 ip4-cidr-length = "/" ("0" | %x31-39 0*1DIGIT) ; value range 0-32 1115 ip6-cidr-length = "/" ("0" | %x31-39 0*2DIGIT) ; value range 0-128 1116 dual-cidr-length = [ ip4-cidr-length ] [ "/" ip6-cidr-length ] 1118 ip4-network = qnum "." qnum "." qnum "." qnum 1119 qnum = DIGIT ; 0-9 1120 / %x31-39 DIGIT ; 10-99 1121 / "1" 2DIGIT ; 100-199 1122 / "2" %x30-34 DIGIT ; 200-249 1123 / "25" %x30-35 ; 250-255 1124 ; as per conventional dotted quad notation. e.g., 192.0.2.0 1125 ip6-network = 1126 ; e.g., 2001:DB8::CD30 1128 The is compared to the given network. If CIDR prefix length 1129 high-order bits match, the mechanism matches. 1131 If ip4-cidr-length is omitted, it is taken to be "/32". If 1132 ip6-cidr-length is omitted, it is taken to be "/128". It is not 1133 permitted to omit parts of the IP address instead of using CIDR 1134 notations. That is, use 192.0.2.0/24 instead of 192.0.2. 1136 5.7. "exists" 1138 This mechanism is used to construct an arbitrary domain name that is 1139 used for a DNS A record query. It allows for complicated schemes 1140 involving arbitrary parts of the mail envelope to determine what is 1141 permitted. 1143 exists = "exists" ":" domain-spec 1145 The domain-spec is expanded as per Section 7. The resulting domain 1146 name is used for a DNS A RR lookup (even when the connection type is 1147 IPv6). If any A record is returned, this mechanism matches. 1149 Domains can use this mechanism to specify arbitrarily complex 1150 queries. For example, suppose example.com publishes the record: 1152 v=spf1 exists:%{ir}.%{l1r+-}._spf.%{d} -all 1154 The might expand to 1155 "1.2.0.192.someuser._spf.example.com". This makes fine-grained 1156 decisions possible at the level of the user and client IP address. 1158 6. Modifier Definitions 1160 Modifiers are name/value pairs that provide additional information. 1161 Modifiers always have an "=" separating the name and the value. 1163 The modifiers defined in this document ("redirect" and "exp") SHOULD 1164 appear at the end of the record, after all mechanisms, though 1165 syntactically they can appear anywhere in the record. Ordering of 1166 these two modifiers does not matter. These two modifiers MUST NOT 1167 appear in a record more than once each. If they do, then 1168 check_host() exits with a result of "permerror". 1170 Unrecognized modifiers MUST be ignored no matter where in a record, 1171 or how often. This allows implementations of this document to 1172 gracefully handle records with modifiers that are defined in other 1173 specifications. 1175 6.1. redirect: Redirected Query 1177 The redirect modifier is intended for consolidating both 1178 authorizations and policy into a common set to be shared within a 1179 single ADMD. It is possible to control both authorized hosts and 1180 policy for an arbitrary number of domains from a single record. 1182 redirect = "redirect" "=" domain-spec 1184 If all mechanisms fail to match, and a "redirect" modifier is 1185 present, then processing proceeds as follows: 1187 The domain-spec portion of the redirect section is expanded as per 1188 the macro rules in Section 7. Then check_host() is evaluated with 1189 the resulting string as the . The and 1190 arguments remain the same as in the current evaluation of 1191 check_host(). 1193 The result of this new evaluation of check_host() is then considered 1194 the result of the current evaluation with the exception that if no 1195 SPF record is found, or if the is malformed, the result 1196 is a "permerror" rather than "none". 1198 Note that the newly-queried domain can itself specify redirect 1199 processing. 1201 This facility is intended for use by organizations that wish to apply 1202 the same record to multiple domains. For example: 1204 la.example.com. TXT "v=spf1 redirect=_spf.example.com" 1205 ny.example.com. TXT "v=spf1 redirect=_spf.example.com" 1206 sf.example.com. TXT "v=spf1 redirect=_spf.example.com" 1207 _spf.example.com. TXT "v=spf1 mx:example.com -all" 1209 In this example, mail from any of the three domains is described by 1210 the same record. This can be an administrative advantage. 1212 Note: In general, the domain "A" cannot reliably use a redirect to 1213 another domain "B" not under the same administrative control. Since 1214 the stays the same, there is no guarantee that the record at 1215 domain "B" will correctly work for mailboxes in domain "A", 1216 especially if domain "B" uses mechanisms involving local-parts. An 1217 "include" directive will generally be more appropriate. 1219 For clarity, any "redirect" modifier SHOULD appear as the very last 1220 term in a record. 1222 6.2. exp: Explanation 1224 explanation = "exp" "=" domain-spec 1226 If check_host() results in a "fail" due to a mechanism match (such as 1227 "-all"), and the "exp" modifier is present, then the explanation 1228 string returned is computed as described below. If no "exp" modifier 1229 is present, then either a default explanation string or an empty 1230 explanation string MUST be returned to the calling application. 1232 The domain-spec is macro expanded (see Section 7) and becomes the 1233 . The DNS TXT RRset for the is fetched. 1235 If there are any DNS processing errors (any RCODE other than 0), or 1236 if no records are returned, or if more than one record is returned, 1237 or if there are syntax errors in the explanation string, then proceed 1238 as if no "exp" modifier was given. 1240 The fetched TXT record's strings are concatenated with no spaces, and 1241 then treated as an explain-string, which is macro-expanded. This 1242 final result is the explanation string. Implementations MAY limit 1243 the length of the resulting explanation string to allow for other 1244 protocol constraints and/or reasonable processing limits. Since the 1245 explanation string is intended for an SMTP response and [RFC5321] 1246 Section 2.4 says that responses are in [US-ASCII], the explanation 1247 string MUST be limited to [US-ASCII]. 1249 Software evaluating check_host() can use this string to communicate 1250 information from the publishing domain in the form of a short message 1251 or URL. Software SHOULD make it clear that the explanation string 1252 comes from a third party. For example, it can prepend the macro 1253 string "%{o} explains: " to the explanation, such as shown in 1254 Section 8.4. 1256 Suppose example.com has this record: 1258 v=spf1 mx -all exp=explain._spf.%{d} 1260 Here are some examples of possible explanation TXT records at 1261 explain._spf.example.com: 1263 "Mail from example.com should only be sent by its own servers." 1264 -- a simple, constant message 1266 "%{i} is not one of %{d}'s designated mail servers." 1267 -- a message with a little more information, including the IP 1268 address that failed the check 1270 "See http://%{d}/why.html?s=%{S}&i=%{I}" 1271 -- a complicated example that constructs a URL with the 1272 arguments to check_host() so that a web page can be 1273 generated with detailed, custom instructions 1275 Note: During recursion into an "include" mechanism, an "exp" modifier 1276 from the MUST NOT be used. In contrast, when executing 1277 a "redirect" modifier, an "exp" modifier from the original domain 1278 MUST NOT be used. This is because "include" is meant to cross 1279 administrative boundaries and the explanation provided should be the 1280 one from the receiving ADMD, while "redirect" is meant to operate as 1281 a tool to consolidate policy records within an ADMD an so the 1282 redirected explanation is the one that ought to have priority. 1284 7. Macros 1286 When evaluating an SPF policy record, certain character sequences are 1287 intended to be replaced by parameters of the message or of the 1288 connection. These character sequences are referred to as "macros". 1290 7.1. Formal Specification 1292 The ABNF description for a macro is as follows: 1294 domain-spec = macro-string domain-end 1295 domain-end = ( "." toplabel [ "." ] ) / macro-expand 1297 toplabel = ( *alphanum ALPHA *alphanum ) / 1298 ( 1*alphanum "-" *( alphanum / "-" ) alphanum ) 1299 alphanum = ALPHA / DIGIT 1301 explain-string = *( macro-string / SP ) 1303 macro-string = *( macro-expand / macro-literal ) 1304 macro-expand = ( "%{" macro-letter transformers *delimiter "}" ) 1305 / "%%" / "%_" / "%-" 1306 macro-literal = %x21-24 / %x26-7E 1307 ; visible characters except "%" 1308 macro-letter = "s" / "l" / "o" / "d" / "i" / "p" / "h" / 1309 "c" / "r" / "t" / "v" 1310 transformers = *DIGIT [ "r" ] 1311 delimiter = "." / "-" / "+" / "," / "/" / "_" / "=" 1313 The "toplabel" construction is subject to the LDH rule plus 1314 additional top-level domain (TLD) restrictions. See Section 2 of 1315 [RFC3696] for background. 1317 Some special cases: 1319 o A literal "%" is expressed by "%%". 1321 o "%_" expands to a single " " space. 1323 o "%-" expands to a URL-encoded space, viz., "%20". 1325 7.2. Macro Definitions 1327 The following macro letters are expanded in term arguments: 1329 s = 1330 l = local-part of 1331 o = domain of 1332 d = 1333 i = 1334 p = the validated domain name of (do not use) 1335 v = the string "in-addr" if is ipv4, or "ip6" if is ipv6 1336 h = HELO/EHLO domain 1338 , , and are defined in Section 2.2. 1340 The following macro letters are allowed only in "exp" text: 1342 c = SMTP client IP (easily readable format) 1343 r = domain name of host performing the check 1344 t = current timestamp 1346 7.3. Macro Processing Details 1348 A '%' character not followed by a '{', '%', '-', or '_' character is 1349 a syntax error. So: 1351 -exists:%(ir).sbl.example.org 1353 is incorrect and will cause check_host() to yield a "permerror". 1354 Instead, the following is legal: 1356 -exists:%{ir}.sbl.example.org 1358 Optional transformers are the following: 1360 *DIGIT = zero or more digits 1361 'r' = reverse value, splitting on dots by default 1363 If transformers or delimiters are provided, the replacement value for 1364 a macro letter is split into parts separated by one or more of the 1365 specified delimiter characters. After performing any reversal 1366 operation and/or removal of left-hand parts, the parts are rejoined 1367 using "." and not the original splitting characters. 1369 By default, strings are split on "." (dots). Note that no special 1370 treatment is given to leading, trailing, or consecutive delimiters in 1371 input strings, and so the list of parts might contain empty strings. 1372 Some older implementations of SPF prohibit trailing dots in domain 1373 names, so trailing dots SHOULD NOT be published, although they MUST 1374 be accepted by implementations conforming to this document. Macros 1375 can specify delimiter characters that are used instead of ".". 1377 The "r" transformer indicates a reversal operation: if the client IP 1378 address were 192.0.2.1, the macro %{i} would expand to "192.0.2.1" 1379 and the macro %{ir} would expand to "1.2.0.192". 1381 The DIGIT transformer indicates the number of right-hand parts to 1382 use, after optional reversal. If a DIGIT is specified, the value 1383 MUST be nonzero. If no DIGITs are specified, or if the value 1384 specifies more parts than are available, all the available parts are 1385 used. If the DIGIT was 5, and only 3 parts were available, the macro 1386 interpreter would pretend the DIGIT was 3. Implementations MUST 1387 support at least a value of 127, as that is the maximum number of 1388 labels in a domain name (less the zero-length label at the end). 1390 The "s" macro expands to the argument. It is an email 1391 address with a local-part, an "@" character, and a domain. The "l" 1392 macro expands to just the local-part. The "o" macro expands to just 1393 the domain part. Note that these values remain the same during 1394 recursive and chained evaluations due to "include" and/or "redirect". 1395 Note also that if the original had no local-part, the local- 1396 part was set to "postmaster" in initial processing (see Section 4.3). 1398 For IPv4 addresses, both the "i" and "c" macros expand to the 1399 standard dotted-quad format. 1401 For IPv6 addresses, the "i" macro expands to a dot-format address; it 1402 is intended for use in %{ir}. The "c" macro can expand to any of the 1403 hexadecimal colon-format addresses specified in [RFC4291], Section 1404 2.2. It is intended for humans to read. 1406 The "p" macro expands to the validated domain name of . The 1407 procedure for finding the validated domain name is defined in 1408 Section 5.5. If the is present in the list of validated 1409 domains, it SHOULD be used. Otherwise, if a subdomain of the 1410 is present, it SHOULD be used. Otherwise, any name from the 1411 list can be used. If there are no validated domain names or if a DNS 1412 error occurs, the string "unknown" is used. 1414 This macro SHOULD NOT be published (see Section 5.5 for the 1415 discussion). 1417 The "h" macro expands to the parameter that was provided to the SMTP 1418 server via the HELO or EHLO SMTP verb. For sessions where that verb 1419 was provided more than once, the most recent instance is used. 1421 The "r" macro expands to the name of the receiving MTA. This SHOULD 1422 be a fully qualified domain name, but if one does not exist (as when 1423 the checking is done by a MUA) or if policy restrictions dictate 1424 otherwise, the word "unknown" SHOULD be substituted. The domain name 1425 can be different from the name found in the MX record that the client 1426 MTA used to locate the receiving MTA. 1428 The "t" macro expands to the decimal representation of the 1429 approximate number of seconds since the Epoch (Midnight, January 1, 1430 1970, UTC) at the time of the evaluation. This is the same value as 1431 is returned by the POSIX time() function in most standards-compliant 1432 libraries. 1434 When the result of macro expansion is used in a domain name query, if 1435 the expanded domain name exceeds 253 characters (the maximum length 1436 of a domain name in this format), the left side is truncated to fit, 1437 by removing successive domain labels (and their following dots) until 1438 the total length does not exceed 253 characters. 1440 Uppercase macros expand exactly as their lowercase equivalents, and 1441 are then URL escaped. URL escaping MUST be performed for characters 1442 not in the "unreserved" set, which is defined in [RFC3986]. 1444 Care has to be taken by the sending ADMD so that macro expansion for 1445 legitimate email does not exceed the 63-character limit on DNS 1446 labels. The local-part of email addresses, in particular, can have 1447 more than 63 characters between dots. 1449 To minimize DNS lookup resource requirements, it is better if sending 1450 ADMDs avoid using the "s", "l", "o", or "h" macros in conjunction 1451 with any mechanism directive. Although these macros are powerful and 1452 allow per-user records to be published, they severely limit the 1453 ability of implementations to cache results of check_host() and they 1454 reduce the effectiveness of DNS caches. 1456 If no directive processed during the evaluation of check_host() 1457 contains an "s", "l", "o", or "h" macro, then the results of the 1458 evaluation can be cached on the basis of and alone for 1459 as long as the DNS record involved with the shortest TTL has not 1460 expired. 1462 7.4. Expansion Examples 1464 The is strong-bad@email.example.com. 1465 The IPv4 SMTP client IP is 192.0.2.3. 1466 The IPv6 SMTP client IP is 2001:DB8::CB01. 1467 The PTR domain name of the client IP is mx.example.org. 1469 macro expansion 1470 ------- ---------------------------- 1471 %{s} strong-bad@email.example.com 1472 %{o} email.example.com 1473 %{d} email.example.com 1474 %{d4} email.example.com 1475 %{d3} email.example.com 1476 %{d2} example.com 1477 %{d1} com 1478 %{dr} com.example.email 1479 %{d2r} example.email 1480 %{l} strong-bad 1481 %{l-} strong.bad 1482 %{lr} strong-bad 1483 %{lr-} bad.strong 1484 %{l1r-} strong 1486 macro-string expansion 1487 -------------------------------------------------------------------- 1488 %{ir}.%{v}._spf.%{d2} 3.2.0.192.in-addr._spf.example.com 1489 %{lr-}.lp._spf.%{d2} bad.strong.lp._spf.example.com 1491 %{lr-}.lp.%{ir}.%{v}._spf.%{d2} 1492 bad.strong.lp.3.2.0.192.in-addr._spf.example.com 1494 %{ir}.%{v}.%{l1r-}.lp._spf.%{d2} 1495 3.2.0.192.in-addr.strong.lp._spf.example.com 1497 %{d2}.trusted-domains.example.net 1498 example.com.trusted-domains.example.net 1500 IPv6: 1501 %{ir}.%{v}._spf.%{d2} 1.0.B.C.0.0.0.0. 1502 0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.B.D.0.1.0.0.2.ip6._spf.example.com 1504 8. Result Handling 1506 This section provides guidance for SPF verifier operators in response 1507 to the various possible outputs of check_host() on a message. 1508 Definitions of SPF results are presented in Section 2.6; this section 1509 provides more detail on each for use in developing local policy for 1510 message handling. 1512 Every operating environment is different. There are some receivers 1513 for whom strict adherence to SPF is appropriate, and definitive 1514 treatment of messages that are evaluated to be explicitly 1515 unauthorized ("fail" and sometimes "softfail") is the norm. There 1516 are others for which the "false negative" cases are more of a 1517 concern. This concern is typically handled by merely recording the 1518 result in the header and allowing the message to pass on for 1519 additional processing. There are still others where SPF is one of 1520 several inputs to the message handling decision. As such, there is 1521 no comprehensive normative requirement for message handling in 1522 response to any particular result. This section is provided to 1523 present a complete picture of the likely cause of each result and, 1524 where available, the experience gained during experimental 1525 deployment. 1527 There are essentially two classes of handling choices: 1529 o Handling within the SMTP session that attempted to deliver the 1530 message, such as by returning a permanent SMTP error (rejection) 1531 or temporary SMTP error ("try again later"); 1533 o Permitting the message to pass (a successful SMTP reply code) and 1534 adding an additional header field that indicates the result 1535 returned by check_host() and other salient details; this is 1536 discussed in more detail in Section 9. 1538 8.1. None 1540 With a "none" result, the SPF verifier has no information at all 1541 about the authorization or lack thereof of the client to use the 1542 checked identity or identities. The check_host() function completed 1543 without errors but was not able to reach any conclusion. 1545 8.2. Neutral 1547 A "neutral" result indicates that although a policy for the identity 1548 was discovered, there is no definite assertion (positive or negative) 1549 about the client. 1551 A "neutral" result MUST be treated exactly like the "none" result; 1552 the distinction exists only for informational purposes. Treating 1553 "neutral" more harshly than "none" would discourage ADMDs from 1554 testing the use of SPF records (see Section 10.1). 1556 8.3. Pass 1558 A "pass" result means that the client is authorized to inject mail 1559 with the given identity. The domain can now, in the sense of 1560 reputation, be considered responsible for sending the message. 1561 Further policy checks can now proceed with confidence in the 1562 legitimate use of the identity. This is further discussed in 1563 Appendix H.1. 1565 8.4. Fail 1567 A "fail" result is an explicit statement that the client is not 1568 authorized to use the domain in the given identity. Disposition of 1569 SPF fail messages is a matter of local policy. See Appendix H.2 for 1570 considerations on developing local policy. 1572 If the checking software chooses to reject the mail during the SMTP 1573 transaction, then it SHOULD use an SMTP reply code of 550 (see 1574 [RFC5321]) and, if supported, the 5.7.1 enhanced status code (see 1575 [RFC3463], Section 3.8), in addition to an appropriate reply text. 1576 The check_host() function will return either a default explanation 1577 string or one from the domain that published the SPF records (see 1578 Section 6.2). If the information does not originate with the 1579 checking software, it is good to make it clear that the text is 1580 provided by the sender's domain. For example: 1582 550-5.7.1 SPF MAIL FROM check failed: 1583 550-5.7.1 The domain example.com explains: 1584 550 5.7.1 Please see http://www.example.com/mailpolicy.html 1586 If the checking software chooses not to reject the mail during the 1587 SMTP transaction, then it SHOULD add a Received-SPF or 1588 Authentication-Results header field (see Section 9) to communicate 1589 this result to downstream message processors. While this is true for 1590 all SPF results, it is of particular importance for "fail" results 1591 since the message is explicitly not authorized by the ADMD. 1593 8.5. Softfail 1595 A "softfail" result ought to be treated as somewhere between "fail" 1596 and "neutral"/"none". The ADMD believes the host is not authorized 1597 but is not willing to make a strong policy statement. Receiving 1598 software SHOULD NOT reject the message based solely on this result, 1599 but MAY subject the message to closer scrutiny than normal. 1601 The ADMD wants to discourage the use of this host and thus desires 1602 limited feedback when a "softfail" result occurs. For example, the 1603 recipient's Mail User Agent (MUA) could highlight the "softfail" 1604 status, or the receiving MTA could give the sender a message using 1605 greylisting, [RFC6647], with a note the first time the message is 1606 received, but accept it on a later attempt based on receiver policy. 1608 8.6. Temperror 1610 A "temperror" result means the SPF verifier encountered a transient 1611 (generally DNS) error while performing the check. Checking software 1612 can choose to accept or temporarily reject the message. If the 1613 message is rejected during the SMTP transaction for this reason, the 1614 software SHOULD use an SMTP reply code of 451 and, if supported, the 1615 4.4.3 enhanced status code (see [RFC3463], Section 3.5). These 1616 errors can be caused by problems in either the sender's or receiver's 1617 DNS software. See Appendix H.4 for considerations on developing 1618 local policy. 1620 8.7. Permerror 1622 A "permerror" result means the domain's published records could not 1623 be correctly interpreted. This signals an error condition that 1624 definitely requires DNS operator intervention to be resolved. If the 1625 message is rejected during the SMTP transaction for this reason, the 1626 software SHOULD use an SMTP reply code of 550 and, if supported, the 1627 5.5.2 enhanced status code (see [RFC3463], Section 3.6). Be aware 1628 that if the ADMD uses macros (Section 7), it is possible that this 1629 result is due to the checked identities having an unexpected format. 1630 It is also possible that this result is generated by certain SPF 1631 verifiers due to the input arguments having an unexpected format; see 1632 Section 4.8. See Appendix H.3 for considerations on developing local 1633 policy. 1635 9. Recording the Result 1637 To provide downstream agents, such as MUAs, with the information they 1638 might need in terms of evaluating or representing the apparent safety 1639 of the message content, it is RECOMMENDED that SMTP receivers record 1640 the result of SPF processing in the message header. For SPF verifier 1641 operators that choose to record SPF results in the header of the 1642 message for processing by internal filters or MUAs, two methods are 1643 presented. Section 9.1 defines the Received-SPF field, which is the 1644 results field originally defined for SPF use. Section 9.2 discusses 1645 Authentication-Results [RFC5451] which was specified more recently 1646 and is designed for use by SPF and other authentication methods. 1648 Both are in common use, and hence both are included here. However, 1649 it is important to note that they were designed to serve slightly 1650 different purposes. Received-SPF is intended to include enough 1651 information to enable reconstruction of the SPF evaluation of the 1652 message, while Authentication-Results is designed only to relay the 1653 result itself and related output details of likely use to end users 1654 (e.g., what property of the message was actually authenticated and 1655 what it contained), leaving reconstructive work to the purview of 1656 system logs and the Received field contents. Also, Received-SPF 1657 relies on compliance of agents within the receiving ADMD to adhere to 1658 the header field ordering rules of [RFC5321] and [RFC5322], while 1659 Authentication-Results includes some provisions to protect against 1660 non-compliant implementations. 1662 An SPF verifier operator could choose to use both to serve different 1663 downstream agents. In such cases, care needs to be taken to ensure 1664 both fields are conveying the same details, or unexpected results can 1665 occur. 1667 9.1. The Received-SPF Header Field 1669 The Received-SPF header field is a trace field (see [RFC5322] Section 1670 3.6.7) and SHOULD be prepended to the existing header, above the 1671 Received: field that is generated by the SMTP receiver. It MUST 1672 appear above all other Received-SPF fields in the message. The 1673 header field has the following format: 1675 header-field = "Received-SPF:" [CFWS] result FWS [comment FWS] 1676 [ key-value-list ] CRLF 1678 result = "pass" / "fail" / "softfail" / "neutral" / 1679 "none" / "temperror" / "permerror" 1681 key-value-list = key-value-pair *( ";" [CFWS] key-value-pair ) 1682 [";"] 1684 key-value-pair = key [CFWS] "=" ( dot-atom / quoted-string ) 1686 key = "client-ip" / "envelope-from" / "helo" / 1687 "problem" / "receiver" / "identity" / 1688 "mechanism" / name 1690 identity = "mailfrom" ; for the "MAIL FROM" identity 1691 / "helo" ; for the "HELO" identity 1692 / name ; other identities 1694 dot-atom = 1695 quoted-string = 1696 comment = 1697 CFWS = 1698 FWS = 1699 CRLF = 1701 The header field SHOULD include a "(...)" style comment after the 1702 result, conveying supporting information for the result, such as 1703 , , and . 1705 The following key-value pairs are designed for later machine parsing. 1706 SPF verifiers SHOULD give enough information so that the SPF results 1707 can be verified. That is, at least "client-ip", "helo", and, if the 1708 "MAIL FROM" identity was checked, "envelope-from". 1710 client-ip the IP address of the SMTP client 1712 envelope-from the envelope sender mailbox 1714 helo the host name given in the HELO or EHLO command 1716 mechanism the mechanism that matched (if no mechanisms matched, 1717 substitute the word "default") 1719 problem if an error was returned, details about the error 1720 receiver the host name of the SPF verifier 1722 identity the identity that was checked; see the ABNF 1723 rule 1725 Other keys MAY be defined by SPF verifiers. 1727 SPF verifiers MUST make sure that the Received-SPF header field does 1728 not contain invalid characters, is not excessively long (See 1729 [RFC5322] Section 2.1.1), and does not contain malicious data that 1730 has been provided by the sender. 1732 Examples of various header field styles that could be generated are 1733 the following: 1735 Received-SPF: pass (mybox.example.org: domain of 1736 myname@example.com designates 192.0.2.1 as permitted sender) 1737 receiver=mybox.example.org; client-ip=192.0.2.1; 1738 envelope-from="myname@example.com"; helo=foo.example.com; 1740 Received-SPF: fail (mybox.example.org: domain of 1741 myname@example.com does not designate 1742 192.0.2.1 as permitted sender) 1743 identity=mailfrom; client-ip=192.0.2.1; 1744 envelope-from="myname@example.com"; 1746 Received-SPF: pass (mybox.example.org: domain of 1747 myname@example.com designates 192.0.2.1 as permitted sender) 1748 receiver=mybox.example.org; client-ip=192.0.2.1; 1749 mechanism=ip4:192.0.2.1; envelope-from="myname@example.com"; 1750 helo=foo.example.com; 1752 9.2. SPF Results in the Authentication-Results Header Field 1754 As mentioned in Section 9, the Authentication-Results header field is 1755 designed to communicate lists of tests a border MTA did and their 1756 results. The specified elements of the field provide less 1757 information than the Received-SPF field: 1759 Authentication-Results: myhost.example.org; spf=pass 1760 smtp.mailfrom=example.net 1762 Received-SPF: pass (myhost.example.org: domain of 1763 myname@example.com designates 192.0.2.1 as permitted sender) 1764 receiver=mybox.example.org; client-ip=192.0.2.1; 1765 envelope-from="myname@example.com"; helo=foo.example.com; 1767 It is, however, possible to add CFWS in the "reason" part of an 1768 Authentication-Results header field and provide the equivalent 1769 information, if desired. 1771 As an example, an expanded Authentication-Results header field might 1772 look like (for a "MAIL FROM" check in this example): 1774 Authentication-Results: myhost.example.org; spf=pass 1775 reason="client-ip=192.0.2.1; smtp.helo=foo.example.com" 1776 smtp.mailfrom=user@example.net 1778 10. Effects on Infrastructure 1780 This section outlines the major implications that adoption of this 1781 protocol will have on various entities involved in Internet email. 1782 It is intended to make clear to the reader where this protocol 1783 knowingly affects the operation of such entities. This section is 1784 not a "how-to" manual, or a "best practices" document, and it is not 1785 a comprehensive list of what such entities ought do in light of this 1786 specification. 1788 This section provides operational advice and instruction only. It is 1789 non-normative. 1791 [RFC5598] describes the Internet email architecture. This section is 1792 organized based on the different segments of the architecture. 1794 10.1. Sending Domains 1796 Originating ADMDs (ADministrative Management Domains - [RFC5598] 1797 Section 2.2.1 and Section 2.3) that wish to be compliant with this 1798 specification will need to determine the list of relays ([RFC5598] 1799 Section 2.2.2) that they allow to use their domain name in the "HELO" 1800 and "MAIL FROM" identities when relaying to other ADMDs. It is 1801 recognized that forming such a list is not just a simple technical 1802 exercise, but involves policy decisions with both technical and 1803 administrative considerations. 1805 10.1.1. DNS Resource Considerations 1807 Minimizing the DNS resources needed for SPF lookups can be done by 1808 choosing directives that require less DNS information and by placing 1809 lower-cost mechanisms earlier in the SPF record. 1811 Section 4.6.4 specifies the limits receivers have to use. It is 1812 essential to publish records that do not exceed these requirements. 1813 It is also required to carefully weigh the cost and the 1814 maintainability of licit solutions. 1816 For example, consider a domain set up as follows: 1818 example.com. IN MX 10 mx.example.com. 1819 IN MX 20 mx2.example.com. 1820 mx.example.com. IN A 192.0.2.1 1821 mx2.example.com. IN A 192.0.2.129 1823 Assume the administrative point is to authorize (pass) mx and mx2 1824 while failing every other host. Compare the following solutions: 1826 Best record: 1827 example.com. IN TXT "v=spf1 ip4:192.0.2.1 ip4:192.0.2.129 -all" 1829 Good record: 1830 $ORIGIN example.com. 1831 @ IN TXT "v=spf1 a:authorized-spf.example.com -all" 1832 authorized-spf IN A 192.0.2.1 1833 IN A 192.0.2.129 1835 Expensive record: 1836 example.com. IN TXT "v=spf1 mx:example.com -all" 1838 Wasteful, bad record: 1839 example.com. IN TXT "v=spf1 ip4:192.0.2.0/24 mx -all" 1841 10.1.2. Administrator's Considerations 1843 There might be administrative considerations: using "a" over "ip4" or 1844 "ip6" allows hosts to be renumbered easily at the cost of a DNS query 1845 per receiver. Using "mx" over "a" allows the set of mail hosts to be 1846 changed easily. Unless such changes are common, it is better to use 1847 the less resource intensive mechanisms like "ip4" and "ip6" over "a" 1848 or "a" over "mx". 1850 In some specific cases, standard advice on record content is 1851 appropriate. Publishing SPF records for domains that send no mail is 1852 a well established best practice. The record for a domain that sends 1853 no mail is: 1855 www.example.com. IN TXT "v=spf1 -all" 1857 Publishing SPF records for individual hosts is also best practice. 1858 The hostname is generally the identity used in the 5321.HELO/.EHLO 1859 command. In the case of messages with a null 5321.MailFrom, this is 1860 used as the domain for 5321.MailFrom SPF checks, in addition to being 1861 used in 5321.HELO/.EHLO based SPF checks. The standard SPF record 1862 for an individual host that is involved in mail processing is: 1864 relay.example.com. IN TXT "v=spf1 a -all" 1866 Validating correct deployment is difficult. [RFC6652] describes one 1867 mechanism for soliciting feedback on SPF failures. Another 1868 suggestion can be found in Appendix D. 1870 Regardless of the method used, understanding the ADMD's outbound mail 1871 architecture is essential to effective deployment. 1873 10.1.3. Bounces 1875 As explained in Section 1.1.3, [RFC5321] allows the MAIL FROM to be 1876 null, which is typical of some Delivery Status Notification 1877 [RFC3464], commonly called email bounces. In this case the only 1878 entity available for performing an SPF check is the "HELO" identity 1879 defined in Section 1.1.4. SPF functionality is enhanced by 1880 administrators ensuring this identity is set correctly and has an 1881 appropriate SPF record. It is normal to have the HELO identity set 1882 to the hostname instead of the domain. Zone file generation for 1883 significant numbers of hosts can be consolidated using the redirect 1884 modifier and scripted for initial deployment. Specific deployment 1885 advice is given above in Section 10.1.2. 1887 10.2. Receivers 1889 SPF results can be used in combination with other methods to 1890 determine the final local disposition (either positive or negative) 1891 of a message. It can also be considered dispositive on its own. 1893 An attempt to have one organization (sender) direct the email 1894 handling policies of another (receiver) is inherently challenging and 1895 often controversial. As stated elsewhere in this document, there is 1896 no comprehensive normative requirement for specific handling of a 1897 message based on SPF results. The information presented in Section 8 1898 and in Appendix H is offered for receiver consideration when forming 1899 local handling policies. 1901 The primary considerations are that SPF might return "pass" for mail 1902 that is ultimately harmful (e.g., spammers that arrange for SPF to 1903 pass using disposable domain names, or virus or spam outbreaks from 1904 within trusted sources), and might also return "fail" for mail that 1905 is ultimately legitimate (e.g., legitimate mail that has traversed a 1906 mail alias). It is important take both of these cases under 1907 consideration when establishing local handling policy. 1909 10.3. Mediators 1911 Mediators are a type of User actor [RFC5598]. That is, a mediator 1912 takes 'delivery' of a message and posts a 'submission' of a new 1913 message. The mediator can make the newly-posted message be as 1914 similar or as different from the original message as they wish. 1915 Examples include mailing lists (see [RFC5598] Section 5.3) and 1916 ReSenders ([RFC5598] Section 5.2). This is discussed in [RFC5321], 1917 Section 3.9. For the operation of SPF, the essential concern is the 1918 email address in the 5321.MailFrom command for the new message. 1920 Because SPF evaluation is based on the IP address of the "last" 1921 sending SMTP server, the address of the mediator will be used, rather 1922 than the address of the SMTP server that sent the message to the 1923 mediator. Some mediators retain the email address from the original 1924 message, while some use a new address. 1926 If the address is the same as for the original message, and the 1927 original message had an associated SPF record, then the SPF 1928 evaluation will fail unless mitigations such as those described in 1929 Appendix E are used. 1931 11. Security Considerations 1933 11.1. Processing Limits 1935 As with most aspects of email, there are a number of ways that 1936 malicious parties could use the protocol as an avenue for a 1937 Denial-of-Service (DoS) attack. The processing limits outlined in 1938 Section 4.6.4 are designed to prevent attacks such as the following: 1940 o A malicious party could create an SPF record with many references 1941 to a victim's domain and send many emails to different SPF 1942 verifiers; those SPF verifiers would then create a DoS attack. In 1943 effect, the SPF verifiers are being used to amplify the attacker's 1944 bandwidth by using fewer octets in the SMTP session than are used 1945 by the DNS queries. Using SPF verifiers also allows the attacker 1946 to hide the true source of the attack. This potential attack is 1947 based on large volumes of mail being transmitted. 1949 o Whereas implementations of check_host() are supposed to limit the 1950 number of DNS lookups, malicious domains could publish records 1951 that exceed these limits in an attempt to waste computation effort 1952 at their targets when they send them mail. Malicious domains 1953 could also design SPF records that cause particular 1954 implementations to use excessive memory or CPU usage, or to 1955 trigger bugs. If a receiver is configured to accept mail with an 1956 SPF result of "temperror", such an attack might result in mail 1957 that would otherwise have been rejected due to an SPF "fail" 1958 result being accepted. This potential attack is based on 1959 specially crafted SPF records being used to exhaust DNS resources 1960 of the victim. 1962 o Malicious parties could send a large volume of mail purporting to 1963 come from the intended target to a wide variety of legitimate mail 1964 hosts. These legitimate machines would then present a DNS load on 1965 the target as they fetched the relevant records. 1967 o Malicious parties could, in theory, use SPF records as a vehicle 1968 for DNS lookup amplification for a denial-of-service-attack. In 1969 this scenario, the attacker publishes an SPF record in its own DNS 1970 that uses "a" and "mx" mechanisms directed toward the intended 1971 victim, e.g. "a:example.com a:foo.example.com a:bar.example.com 1972 ..." and then distributes mail with a MAIL FROM value including 1973 its own domain in large volume to a wide variety of destinations. 1974 Any such destination operating an SPF verifier will begin querying 1975 all of the names associated with the "a" mechanisms in that 1976 record. The names used in the record needn't exist for the attack 1977 to be effective. Operational experience since publication of 1978 [RFC4408] suggests that mitigation of this class of attack can be 1979 accomplished with minimal impact on the deployed base by having 1980 the verifier abort processing and return "permerror" 1981 (Section 2.6.7) once more than two "void lookups" have been 1982 encountered (defined in Section 4.6.4). 1984 Of these, the case of a third party referenced in the SPF record is 1985 the easiest for a DoS attack to effectively exploit. As a result, 1986 limits that might seem reasonable for an individual mail server can 1987 still allow an unreasonable amount of bandwidth amplification. 1988 Therefore, the processing limits need to be quite low. 1990 11.2. SPF-Authorized Email May Contain Other False Identities 1992 Do not construe the "MAIL FROM" and "HELO" identity authorizations to 1993 provide more assurance than they do. It is entirely possible for a 1994 malicious sender to inject a message using his own domain in the 1995 identities used by SPF, to have that domain's SPF record authorize 1996 the sending host, and yet the message can easily list other 1997 identities in its header. Unless the user or the MUA takes care to 1998 note that the authorized identity does not match the other more 1999 commonly-presented identities (such as the From: header field), the 2000 user might be lulled into a false sense of security. 2002 11.3. Spoofed DNS and IP Data 2004 There are two aspects of this protocol that malicious parties could 2005 exploit to undermine the validity of the check_host() function: 2007 o The evaluation of check_host() relies heavily on DNS. A malicious 2008 attacker could attack the DNS infrastructure and cause 2009 check_host() to see spoofed DNS data, and then return incorrect 2010 results. This could include returning "pass" for an value 2011 where the actual domain's record would evaluate to "fail". See 2012 [RFC3833] for a description of DNS weaknesses. 2014 o The client IP address, , is assumed to be correct. In a 2015 modern, correctly configured system the risk of this not being 2016 true is nil. 2018 11.4. Cross-User Forgery 2020 By definition, SPF policies just map domain names to sets of 2021 authorized MTAs, not whole email addresses to sets of authorized 2022 users. Although the "l" macro (Section 7) provides a limited way to 2023 define individual sets of authorized MTAs for specific email 2024 addresses, it is generally impossible to verify, through SPF, the use 2025 of specific email addresses by individual users of the same MTA. 2027 It is up to mail services and their MTAs to directly prevent 2028 cross-user forgery: based on SMTP AUTH ([RFC4954]), users have to be 2029 restricted to using only those email addresses that are actually 2030 under their control (see [RFC6409], Section 6.1). Another means to 2031 verify the identity of individual users is message cryptography such 2032 as PGP ([RFC4880]) or S/MIME ([RFC5751]). 2034 11.5. Untrusted Information Sources 2036 An SPF compliant receiver gathers information from the SMTP commands 2037 it receives and from the published DNS records of the sending domain 2038 holder, (e.g., "HELO" domain name, the "MAIL FROM" address from the 2039 envelope, and SPF DNS records published by the domain holder). These 2040 parameters are not validated in the SMTP process. 2042 All of these pieces of information are generated by actors outside of 2043 the authority of the receiver, and thus are not guaranteed to be 2044 accurate or legitimate. 2046 11.5.1. Recorded Results 2048 This information, passed to the receiver in the Received-SPF: or 2049 Authentication-Results: trace fields, can be returned to the client 2050 MTA as an SMTP rejection message. If such an SMTP rejection message 2051 is generated, the information from the trace fields has to be checked 2052 for such problems as invalid characters and excessively long lines. 2054 11.5.2. External Explanations 2056 When the authorization check fails, an explanation string could be 2057 included in the reject response. Both the sender and the rejecting 2058 receiver need to be aware that the explanation was determined by the 2059 publisher of the SPF record checked and, in general, not the 2060 receiver. The explanation can contain malicious URLs, or it might be 2061 offensive or misleading. 2063 Explanations returned to sender domains due to "exp" modifiers 2064 (Section 6.2) were generated by the sender policy published by the 2065 domain holders themselves. As long as messages are only returned 2066 with non-delivery notification ([RFC3464]) to domains publishing the 2067 explanation strings from their own DNS SPF records, the only affected 2068 parties are the original publishers of the domain's SPF records. 2070 In practice, such non-delivery notifications can be misdirected, such 2071 as when an MTA accepts an email and only later generates the 2072 notification to a forged address, or when an email forwarder does not 2073 direct the bounce back to the original sender. 2075 11.5.3. Macro Expansion 2077 Macros (Section 7) allow senders to inject arbitrary text (any non- 2078 null [US-ASCII] character) into receiver DNS queries. It is 2079 necessary to be prepared for hostile or unexpected content. 2081 11.6. Privacy Exposure 2083 Checking SPF records causes DNS queries to be sent to the domain 2084 owner. These DNS queries, especially if they are caused by the 2085 "exists" mechanism, can contain information about who is sending 2086 email and likely to which MTA the email is being sent. This can 2087 introduce some privacy concerns, which are more or less of an issue 2088 depending on local laws and the relationship between the ADMD and the 2089 person sending the email. 2091 11.7. Delivering Mail Producing a 'Fail' Result 2093 Operators that choose to deliver mail for which SPF produces a "fail" 2094 result need to understand that they are admitting content that is 2095 explicitly not authorized by the purported sender. While there are 2096 known failure modes that can be considered "false negatives", the 2097 distinct choice to admit those messages increases end-user exposure 2098 to likely harm. This is especially true for domains belonging to 2099 known good actors that are typically well-behaved; unauthorized mail 2100 from those sources might well be subjected to much higher skepticism 2101 and content analysis. 2103 SPF does not, however, include the capacity for identifying good 2104 actors from bad ones, nor does it handle the concept of known actors 2105 versus unknown ones. Those notions are out of scope for this 2106 specification. 2108 12. Contributors and Acknowledgements 2110 This document is largely based on the work of Meng Weng Wong, Mark 2111 Lentczner, and Wayne Schlitt. Although, as this section 2112 acknowledges, many people have contributed to this document, a very 2113 large portion of the writing and editing are due to Meng, Mark, and 2114 Wayne. 2116 This design owes a debt of parentage to [RMX] by Hadmut Danisch and 2117 to [DMP] by Gordon Fecyk. The idea of using a DNS record to check 2118 the legitimacy of an email address traces its ancestry further back 2119 through messages on the namedroppers mailing list by Paul Vixie 2120 [Vixie] (based on suggestion by Jim Miller) and by David Green 2121 [Green]. 2123 Philip Gladstone contributed the concept of macros to the 2124 specification, multiplying the expressiveness of the language and 2125 making per-user and per-IP lookups possible. 2127 The authors of both this document and [RFC4408] would also like to 2128 thank the literally hundreds of individuals who have participated in 2129 the development of this design. They are far too numerous to name, 2130 but they include the following: 2132 The participants in the SPFbis working group. 2133 The folks on the spf-discuss mailing list. 2134 The folks on the SPAM-L mailing list. 2135 The folks on the IRTF ASRG mailing list. 2136 The folks on the IETF MARID mailing list. 2137 The folks on #perl. 2139 13. IANA Considerations 2141 13.1. The SPF DNS Record Type 2143 Per [RFC4408], the IANA assigned the Resource Record Type and Qtype 2144 from the DNS Parameters Registry for the SPF RR type with code 99. 2145 The format of this type is identical to the TXT RR [RFC1035]. The 2146 character content of the record is encoded as [US-ASCII]. 2148 Studies have shown that RRTYPE 99 has not seen any substantial use, 2149 and in fact its existence and mechanism defined in [RFC4408] has led 2150 to some interoperability issues. Accordingly, its use is now 2151 obsolete, and new implementations are not to use it. 2153 IANA is requested to update the Resource Record (RR) TYPEs registry 2154 to indicate that this document is the reference document for that 2155 RRTYPE. 2157 [NOTE TO RFC EDITOR: (to be changed to " ... has updated ..." upon 2158 publication)] 2160 13.2. The Received-SPF Mail Header Field 2162 Per [RFC3864], the "Received-SPF:" header field is added to the IANA 2163 Permanent Message Header Field Registry. The following is the 2164 registration template: 2166 Header field name: Received-SPF 2167 Applicable protocol: mail ([RFC5322]) 2168 Status: standard 2169 Author/Change controller: IETF 2170 Specification document(s): RFC XXXX 2171 [NOTE TO RFC EDITOR: (this document)] 2173 13.3. SPF Modifier Registry 2175 IANA is requested to change the reference for the exp and redirect 2176 modifiers in the Modifier Names registry, under Sender Policy 2177 Framework Parameters, from [RFC4408] to this document. Their status 2178 is unchanged. 2180 14. References 2182 14.1. Normative References 2184 [RFC1035] Mockapetris, P., "Domain names - implementation and 2185 specification", STD 13, RFC 1035, November 1987. 2187 [RFC1123] Braden, R., "Requirements for Internet Hosts - Application 2188 and Support", STD 3, RFC 1123, October 1989. 2190 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2191 Requirement Levels", BCP 14, RFC 2119, March 1997. 2193 [RFC3463] Vaudreuil, G., "Enhanced Mail System Status Codes", 2194 RFC 3463, January 2003. 2196 [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration 2197 Procedures for Message Header Fields", BCP 90, RFC 3864, 2198 September 2004. 2200 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 2201 Resource Identifier (URI): Generic Syntax", STD 66, 2202 RFC 3986, January 2005. 2204 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 2205 Architecture", RFC 4291, February 2006. 2207 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 2208 Specifications: ABNF", STD 68, RFC 5234, January 2008. 2210 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 2211 October 2008. 2213 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 2214 October 2008. 2216 [RFC5451] Kucherawy, M., "Message Header Field for Indicating 2217 Message Authentication Status", RFC 5451, April 2009. 2219 [RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, 2220 July 2009. 2222 [RFC5890] Klensin, J., "Internationalized Domain Names for 2223 Applications (IDNA): Definitions and Document Framework", 2224 RFC 5890, August 2010. 2226 [US-ASCII] 2227 American National Standards Institute (formerly United 2228 States of America Standards Institute), "USA Code for 2229 Information Interchange, X3.4", 1968. 2231 ANSI X3.4-1968 has been replaced by newer versions with 2232 slight modifications, but the 1968 version remains 2233 definitive for the Internet. 2235 14.2. Informative References 2237 [DMP] Fecyk, G., "Designated Mailers Protocol". 2239 Work In Progress 2241 [Green] Green, D., "Domain-Authorized SMTP Mail", 2002. 2243 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 2244 STD 13, RFC 1034, November 1987. 2246 [RFC1983] Malkin, G., "Internet Users' Glossary", RFC 1983, 2247 August 1996. 2249 [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", 2250 RFC 2671, August 1999. 2252 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 2253 specifying the location of services (DNS SRV)", RFC 2782, 2254 February 2000. 2256 [RFC3464] Moore, K. and G. Vaudreuil, "An Extensible Message Format 2257 for Delivery Status Notifications", RFC 3464, 2258 January 2003. 2260 [RFC3696] Klensin, J., "Application Techniques for Checking and 2261 Transformation of Names", RFC 3696, February 2004. 2263 [RFC3833] Atkins, D. and R. Austein, "Threat Analysis of the Domain 2264 Name System (DNS)", RFC 3833, August 2004. 2266 [RFC3834] Moore, K., "Recommendations for Automatic Responses to 2267 Electronic Mail", RFC 3834, August 2004. 2269 [RFC4408] Wong, M. and W. Schlitt, "Sender Policy Framework (SPF) 2270 for Authorizing Use of Domains in E-Mail, Version 1", 2271 RFC 4408, April 2006. 2273 [RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing 2274 (CIDR): The Internet Address Assignment and Aggregation 2275 Plan", BCP 122, RFC 4632, August 2006. 2277 [RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. 2278 Thayer, "OpenPGP Message Format", RFC 4880, November 2007. 2280 [RFC4954] Siemborski, R. and A. Melnikov, "SMTP Service Extension 2281 for Authentication", RFC 4954, July 2007. 2283 [RFC5507] IAB, Faltstrom, P., Austein, R., and P. Koch, "Design 2284 Choices When Expanding the DNS", RFC 5507, April 2009. 2286 [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet 2287 Mail Extensions (S/MIME) Version 3.2 Message 2288 Specification", RFC 5751, January 2010. 2290 [RFC5782] Levine, J., "DNS Blacklists and Whitelists", RFC 5782, 2291 February 2010. 2293 [RFC6409] Gellens, R. and J. Klensin, "Message Submission for Mail", 2294 STD 72, RFC 6409, November 2011. 2296 [RFC6647] Kucherawy, M. and D. Crocker, "Email Greylisting: An 2297 Applicability Statement for SMTP", RFC 6647, June 2012. 2299 [RFC6648] Saint-Andre, P., Crocker, D., and M. Nottingham, 2300 "Deprecating the "X-" Prefix and Similar Constructs in 2301 Application Protocols", BCP 178, RFC 6648, June 2012. 2303 [RFC6652] Kitterman, S., "Sender Policy Framework (SPF) 2304 Authentication Failure Reporting Using the Abuse Reporting 2305 Format", RFC 6652, June 2012. 2307 [RFC6686] Kucherawy, M., "Resolution of the Sender Policy Framework 2308 (SPF) and Sender ID Experiments", RFC 6686, July 2012. 2310 [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms 2311 for DNS (EDNS(0))", STD 75, RFC 6891, April 2013. 2313 [RMX] Danisch, H., "The RMX DNS RR Type for light weight sender 2314 authentication". 2316 Work In Progress 2318 [Vixie] Vixie, P., "Repudiating MAIL FROM", 2002. 2320 Appendix A. Collected ABNF 2322 This section is normative and any discrepancies with the ABNF 2323 fragments in the preceding text are to be resolved in favor of this 2324 grammar. 2326 See [RFC5234] for ABNF notation. Please note that as per this ABNF 2327 definition, literal text strings (those in quotes) are case- 2328 insensitive. Hence, "mx" matches "mx", "MX", "mX", and "Mx". 2330 record = version terms *SP 2331 version = "v=spf1" 2333 terms = *( 1*SP ( directive / modifier ) ) 2335 directive = [ qualifier ] mechanism 2336 qualifier = "+" / "-" / "?" / "~" 2337 mechanism = ( all / include 2338 / a / mx / ptr / ip4 / ip6 / exists ) 2340 all = "all" 2341 include = "include" ":" domain-spec 2342 a = "a" [ ":" domain-spec ] [ dual-cidr-length ] 2343 mx = "mx" [ ":" domain-spec ] [ dual-cidr-length ] 2344 ptr = "ptr" [ ":" domain-spec ] 2345 ip4 = "ip4" ":" ip4-network [ ip4-cidr-length ] 2346 ip6 = "ip6" ":" ip6-network [ ip6-cidr-length ] 2347 exists = "exists" ":" domain-spec 2349 modifier = redirect / explanation / unknown-modifier 2350 redirect = "redirect" "=" domain-spec 2351 explanation = "exp" "=" domain-spec 2352 unknown-modifier = name "=" macro-string 2353 ; where name is not any known modifier 2355 ip4-cidr-length = "/" ("0" | %x31-39 0*1DIGIT) ; value range 0-32 2356 ip6-cidr-length = "/" ("0" | %x31-39 0*2DIGIT) ; value range 0-128 2357 dual-cidr-length = [ ip4-cidr-length ] [ "/" ip6-cidr-length ] 2359 ip4-network = qnum "." qnum "." qnum "." qnum 2360 qnum = DIGIT ; 0-9 2361 / %x31-39 DIGIT ; 10-99 2362 / "1" 2DIGIT ; 100-199 2363 / "2" %x30-34 DIGIT ; 200-249 2364 / "25" %x30-35 ; 250-255 2365 ; conventional dotted quad notation. e.g., 192.0.2.0 2366 ip6-network = 2367 ; e.g., 2001:DB8::CD30 2369 domain-spec = macro-string domain-end 2370 domain-end = ( "." toplabel [ "." ] ) / macro-expand 2372 toplabel = ( *alphanum ALPHA *alphanum ) / 2373 ( 1*alphanum "-" *( alphanum / "-" ) alphanum ) 2374 ; LDH rule plus additional TLD restrictions 2375 ; (see [RFC3696], Section 2 for background) 2376 alphanum = ALPHA / DIGIT 2378 explain-string = *( macro-string / SP ) 2380 macro-string = *( macro-expand / macro-literal ) 2381 macro-expand = ( "%{" macro-letter transformers *delimiter "}" ) 2382 / "%%" / "%_" / "%-" 2383 macro-literal = %x21-24 / %x26-7E 2384 ; visible characters except "%" 2385 macro-letter = "s" / "l" / "o" / "d" / "i" / "p" / "h" / 2386 "c" / "r" / "t" / "v" 2387 transformers = *DIGIT [ "r" ] 2388 delimiter = "." / "-" / "+" / "," / "/" / "_" / "=" 2390 name = ALPHA *( ALPHA / DIGIT / "-" / "_" / "." ) 2392 header-field = "Received-SPF:" [CFWS] result FWS [comment FWS] 2393 [ key-value-list ] CRLF 2395 result = "pass" / "fail" / "softfail" / "neutral" / 2396 "none" / "temperror" / "permerror" 2398 key-value-list = key-value-pair *( ";" [CFWS] key-value-pair ) 2399 [";"] 2401 key-value-pair = key [CFWS] "=" ( dot-atom / quoted-string ) 2403 key = "client-ip" / "envelope-from" / "helo" / 2404 "problem" / "receiver" / "identity" / 2405 "mechanism" / name 2407 identity = "mailfrom" ; for the "MAIL FROM" identity 2408 / "helo" ; for the "HELO" identity 2409 / name ; other identities 2411 sender = Mailbox 2412 ip = ip4-network / ip6-network 2413 ALPHA = 2414 DIGIT = <0-9 as per [RFC5234]> 2415 SP = 2416 dot-atom = 2417 quoted-string = 2418 comment = 2419 CFWS = 2420 FWS = 2421 CRLF = 2423 Appendix B. Extended Examples 2425 These examples are based on the following DNS setup: 2427 ; A domain with two mail servers, two hosts 2428 ; and two servers at the domain name 2429 $ORIGIN example.com. 2430 @ MX 10 mail-a 2431 MX 20 mail-b 2432 A 192.0.2.10 2433 A 192.0.2.11 2434 amy A 192.0.2.65 2435 bob A 192.0.2.66 2436 mail-a A 192.0.2.129 2437 mail-b A 192.0.2.130 2438 www CNAME example.com. 2440 ; A related domain 2441 $ORIGIN example.org. 2442 @ MX 10 mail-c 2443 mail-c A 192.0.2.140 2445 ; The reverse IP for those addresses 2446 $ORIGIN 2.0.192.in-addr.arpa. 2447 10 PTR example.com. 2448 11 PTR example.com. 2449 65 PTR amy.example.com. 2450 66 PTR bob.example.com. 2451 129 PTR mail-a.example.com. 2452 130 PTR mail-b.example.com. 2453 140 PTR mail-c.example.org. 2455 ; A rogue reverse IP domain that claims to be 2456 ; something it's not 2457 $ORIGIN 0.0.10.in-addr.arpa. 2458 4 PTR bob.example.com. 2460 B.1. Simple Examples 2462 These examples show various possible published records for 2463 example.com and which values if would cause check_host() to 2464 return "pass". Note that is "example.com". 2466 v=spf1 +all 2467 -- any passes 2469 v=spf1 a -all 2470 -- hosts 192.0.2.10 and 192.0.2.11 pass 2472 v=spf1 a:example.org -all 2473 -- no sending hosts pass since example.org has no A records 2475 v=spf1 mx -all 2476 -- sending hosts 192.0.2.129 and 192.0.2.130 pass 2478 v=spf1 mx:example.org -all 2479 -- sending host 192.0.2.140 passes 2481 v=spf1 mx mx:example.org -all 2482 -- sending hosts 192.0.2.129, 192.0.2.130, and 192.0.2.140 pass 2484 v=spf1 mx/30 mx:example.org/30 -all 2485 -- any sending host in 192.0.2.128/30 or 192.0.2.140/30 passes 2487 v=spf1 ptr -all 2488 -- sending host 192.0.2.65 passes (reverse DNS is valid and is in 2489 example.com) 2490 -- sending host 192.0.2.140 fails (reverse DNS is valid, but not 2491 in example.com) 2492 -- sending host 10.0.0.4 fails (reverse IP is not valid) 2494 v=spf1 ip4:192.0.2.128/28 -all 2495 -- sending host 192.0.2.65 fails 2496 -- sending host 192.0.2.129 passes 2498 B.2. Multiple Domain Example 2500 These examples show the effect of related records: 2502 example.org: "v=spf1 include:example.com include:example.net -all" 2504 This record would be used if mail from example.org actually came 2505 through servers at example.com and example.net. Example.org's 2506 designated servers are the union of example.com's and example.net's 2507 designated servers. 2509 la.example.org: "v=spf1 redirect=example.org" 2510 ny.example.org: "v=spf1 redirect=example.org" 2511 sf.example.org: "v=spf1 redirect=example.org" 2513 These records allow a set of domains that all use the same mail 2514 system to make use of that mail system's record. In this way, only 2515 the mail system's record needs to be updated when the mail setup 2516 changes. These domains' records never have to change. 2518 B.3. DNSBL Style Example 2520 Imagine that, in addition to the domain records listed above, there 2521 are these (see [RFC5782]): 2523 $ORIGIN _spf.example.com. 2524 mary.mobile-users A 127.0.0.2 2525 fred.mobile-users A 127.0.0.2 2526 15.15.168.192.joel.remote-users A 127.0.0.2 2527 16.15.168.192.joel.remote-users A 127.0.0.2 2529 The following records describe users at example.com who mail from 2530 arbitrary servers, or who mail from personal servers. 2532 example.com: 2534 v=spf1 mx 2535 include:mobile-users._spf.%{d} 2536 include:remote-users._spf.%{d} 2537 -all 2539 mobile-users._spf.example.com: 2541 v=spf1 exists:%{l1r+}.%{d} 2543 remote-users._spf.example.com: 2545 v=spf1 exists:%{ir}.%{l1r+}.%{d} 2547 B.4. Multiple Requirements Example 2549 Say that your sender policy requires both that the IP address is 2550 within a certain range and that the reverse DNS for the IP matches. 2551 This can be done several ways, including the following: 2553 example.com. SPF ( "v=spf1 " 2554 "-include:ip4._spf.%{d} " 2555 "-include:ptr._spf.%{d} " 2556 "+all" ) 2557 ip4._spf.example.com. SPF "v=spf1 -ip4:192.0.2.0/24 +all" 2558 ptr._spf.example.com. SPF "v=spf1 -ptr +all" 2560 This example shows how the "-include" mechanism can be useful, how an 2561 SPF record that ends in "+all" can be very restrictive, and the use 2562 of De Morgan's Law. 2564 Appendix C. Changes in implementation requirements from RFC 4408 2566 The modifications to implementation requirements from [RFC4408] are 2567 all either (a) corrections to errors in [RFC4408], or (b) additional 2568 documentation based on consensus of operational experience acquired 2569 since publication of [RFC4408]. 2571 o Use of DNS RR type SPF (99) has been removed from the protocol, 2572 see [RFC6686] for background. 2574 o A new DNS related processing limit based on "void lookups" has 2575 been added (Section 4.6.4). 2577 o Use of the ptr mechanism and the %p macro have been strongly 2578 discouraged Section 5.5 and Section 7.2. They remain part of the 2579 protocol because they were found to be in use, but records ought 2580 to be updated to avoid them. 2582 o Use of the "Authentication-Results" header field [RFC5451] as a 2583 possible alternative to use of the "Received-SPF" header field is 2584 discussed (Section 9.2). 2586 o There have been a number of minor corrections to the ABNF to make 2587 it more clear and correct Appendix A. SPF library implementers 2588 should give the revised ABNF a careful review to determine if 2589 implementation changes are needed. 2591 o Use of X- fields in the ABNF has been removed see [RFC6648] for 2592 background. 2594 o Ambiguity about how to deal with invalid domain-spec after macro 2595 expansion has been documented. Depending on one specific behavior 2596 has to be avoided (Section 4.8). 2598 o General operational information has been updated and expanded 2599 based on eight years of post [RFC4408] operations experience. See 2600 Section 10 and Appendices D - H below. 2602 o Security considerations have been reviewed and updated 2603 (Section 11). 2605 Appendix D. Further Testing Advice 2607 Another approach that can be helpful to publish records that include 2608 a "tracking exists:" mechanism. By looking at the name server logs, 2609 a rough list can then be generated. For example: 2611 v=spf1 exists:_h.%{h}._l.%{l}._o.%{o}._i.%{i}._spf.%{d} ?all 2613 Appendix E. SPF/Mediator Interactions 2615 There are three places that techniques can be used to ameliorate 2616 unintended SPF failures with mediators. 2618 E.1. Originating ADMDs 2620 The beginning, when email is first sent: 2622 o "Neutral" results could be given for IP addresses that might be 2623 forwarders, instead of "fail" results based on a list of known 2624 reliable forwarders. For example: 2626 "v=spf1 mx ?exists:%{ir}.whitlist.example.org -all" 2628 This would cause a lookup on an DNS white list (DNSWL) and cause a 2629 result of "fail" only for email not either coming from the 2630 domain's mx host(s) (SPF pass) or white listed sources (SPF 2631 neutral). This, in effect, outsources an element of sender policy 2632 to the maintainer of the whitelist. 2634 o The "MAIL FROM" identity could have additional information in the 2635 local-part that cryptographically identifies the mail as coming 2636 from an authorized source. In this case, such an SPF record could 2637 be used: 2639 "v=spf1 mx exists:%{l}._spf_verify.%{d} -all" 2641 Then, a specialized DNS server can be set up to serve the 2642 _spf_verify subdomain that validates the local-part. Although 2643 this requires an extra DNS lookup, this happens only when the 2644 email would otherwise be rejected as not coming from a known good 2645 source. 2646 Note that due to the 63-character limit for domain labels, this 2647 approach only works reliably if the local-part signature scheme is 2648 guaranteed either to only produce local-parts with a maximum of 63 2649 characters or to gracefully handle truncated local-parts. 2651 o Similarly, a specialized DNS server could be set up that will 2652 rate-limit the email coming from unexpected IP addresses. 2654 "v=spf1 mx exists:%{ir}._spf_rate.%{d} -all" 2656 o SPF allows the creation of per-user policies for special cases. 2657 For example, the following SPF record and appropriate wildcard DNS 2658 records can be used: 2660 "v=spf1 mx redirect=%{l1r+}._at_.%{o}._spf.%{d}" 2662 E.2. Mediators 2664 The middle, when email is forwarded:. 2666 o Mediators can solve the problem by rewriting the "MAIL FROM" to be 2667 in their own domain. This means mail rejected from the external 2668 mailbox will have to be forwarded back to the original sender by 2669 the forwarding service. Various schemes to do this exist though 2670 they vary widely in complexity and resource requirements on the 2671 part of the mediator. 2673 o Several popular MTAs can be forced from "alias" semantics to 2674 "mailing list" semantics by configuring an additional alias with 2675 "owner-" prepended to the original alias name (e.g., an alias of 2676 "friends: george@example.com, fred@example.org" would need another 2677 alias of the form "owner-friends: localowner"). 2679 o Mediators could reject mail that would "fail" SPF if forwarded 2680 using an SMTP reply code of 551, User not local, (see [RFC5321] 2681 section 3.4) to communicate the correct target address to resend 2682 the mail to. 2684 E.3. Receving ADMDs 2686 The end, when email is received: 2688 o If the owner of the external mailbox wishes to trust the mediator, 2689 he can direct the external mailbox's MTA to skip SPF tests when 2690 the client host belongs to the mediator. 2692 o Tests against other identities, such as the "HELO" identity, can 2693 be used to override a failed test against the "MAIL FROM" 2694 identity. 2696 o For larger domains, it might not be possible to have a complete or 2697 accurate list of forwarding services used by the owners of the 2698 domain's mailboxes. In such cases, whitelists of generally- 2699 recognized forwarding services could be employed. 2701 Appendix F. Mail Services 2703 MSPs (Mail Service Providers - [RFC5598] Section 2.3) that offer mail 2704 services to third-party domains, such as sending of bulk mail, might 2705 want to adjust their configurations in light of the authorization 2706 check described in this document. If the domain part of the "MAIL 2707 FROM" identity used for such email uses the domain of one of the MSPs 2708 domain, then the provider needs only to ensure that its sending host 2709 is authorized by its own SPF record, if any. 2711 If the "MAIL FROM" identity does not use the MSP's domain, then extra 2712 care has to be taken. The SPF record format has several options for 2713 the third-party domain to authorize the service provider's MTAs to 2714 send mail on its behalf. For MSPs, such as ISPs, that have a wide 2715 variety of customers using the same MTA, steps are required to 2716 mitigate the risk of cross-customer forgery (see Section 11.4). 2718 Appendix G. MTA Relays 2720 Relays are described in [RFC5598] Section 2.2.2. The authorization 2721 check generally precludes the use of arbitrary MTA relays between 2722 sender and receiver of an email message. 2724 Within an organization, MTA relays can be effectively deployed. 2725 However, for purposes of this document, such relays are effectively 2726 transparent. The SPF authorization check is a check between border 2727 MTAs of different ADMDs. 2729 For mail senders, this means that published SPF records have to 2730 authorize any MTAs that actually send across the Internet. Usually, 2731 these are just the border MTAs as internal MTAs simply forward mail 2732 to these MTAs for relaying. 2734 The receiving ADMD will generally want to perform the authorization 2735 check at the boundary MTAs, including all secondary MXs. Internal 2736 MTAs (including MTAs that might serve both as boundary MTAs and 2737 internal relays from secondary MXs when they are processing the 2738 relayed mail stream) then do not perform the authorization test. To 2739 perform the authorization test other than at the boundary, the host 2740 that first transferred the message to the receiving ADMD have to be 2741 determined, which can be difficult to extract from the message header 2742 because (a) header fields can be forged or malformed, and (b) there's 2743 no standard way to encode that information such that it can be 2744 reliably extracted. Testing other than at the boundary is likely to 2745 produce unreliable results. This is described further in Appendix C 2746 of [RFC5451]. 2748 Appendix H. Local Policy Considerations 2750 SPF results can be used in combination with other methods to 2751 determine the final local disposition (either positive or negative of 2752 a message. It can also be considered dispositive on its own. 2754 H.1. Policy For SPF Pass 2756 SPF pass results can be used in combination with "white lists" of 2757 known "good" domains to bypass some or all additional pre-delivery 2758 email checks. Exactly which checks and how to determine appropriate 2759 white list entries has to be based on local conditions and 2760 requirements. 2762 H.2. Policy For SPF Fail 2764 SPF fail results can be used to reject messages during the SMTP 2765 transaction based on either "MAIL FROM" or "HELO" identity results. 2766 This reduces resource requirements for various content filtering 2767 methods and conserves bandwidth since rejection can be done before 2768 the SMTP content is transferred. It also gives immediate feedback to 2769 the sender who might then be able to resolve the issue. Due to some 2770 of the issues described above in this section (Section 10), SPF based 2771 rejection does present some risk of rejecting legitimate email when 2772 rejecting based on "MAIL FROM" results. 2774 SPF fail results can alternately be used as one input into a larger 2775 set of evaluations which might, based on a combination with other 2776 evaluation techniques, result in the email being marked negatively in 2777 some way (this might be via delivery to a special spam folder, 2778 modifying subject lines, or other locally determined means). 2779 Developing the details of such an approach have to be based on local 2780 conditions and requirements. Using SPF results in this way does not 2781 have the advantages of resource conservation and immediate feedback 2782 to the sender associated with SMTP rejection, but could produce fewer 2783 undesirable rejections in a well designed system. Such an approach 2784 might result in email that was not authorized by the sending ADMD 2785 being unknowingly delivered to end users. 2787 Either general approach can be used as they both leave a clear 2788 disposition of emails. They are either delivered in some manner or 2789 the sender is notified of the failure. Other dispositions such as 2790 "dropping" or deleting email after acceptance are inappropriate 2791 because they leave uncertainty and reduce the overall reliability and 2792 utility of email across the Internet. 2794 H.3. Policy For SPF Permerror 2796 The "permerror" result (see Section 2.6.7) indicates the SPF 2797 processing module at the receiver determined that the retrieved SPF 2798 policy record could not be interpreted. This gives no true 2799 indication about the authorized use of the data found in the 2800 envelope. 2802 As with all results, implementers have a choice to make regarding 2803 what to do with a message that yields this result. SMTP allows only 2804 a few basic options. 2806 Rejection of the message is an option, in that it is the one thing a 2807 receiver can do to draw attention to the difficulty encountered while 2808 protecting itself from messages that do not have a definite SPF 2809 result of some kind. However, if the SPF implementation is defective 2810 and returns spurious "permerror" results, only the sender is actively 2811 notified of the defect (in the form of rejected mail), and not the 2812 receiver making use of SPF. 2814 The less intrusive handling choice is to deliver the message, perhaps 2815 with some kind of annotation of the difficulty encountered and/or 2816 logging of a similar nature. However, this will not be desirable to 2817 SPF verifier operators that wish to implement SPF checking as 2818 strictly as possible, nor is this sort of passive problem reporting 2819 typically effective. 2821 There is of course the option placing this choice in the hands of the 2822 SPF verifier operator rather than the implementer since this kind of 2823 choice is often a matter of local policy rather than a condition with 2824 a universal solution, but this adds one more piece of complexity to 2825 an already non-trivial environment. 2827 Both implementers and SPF verfier operators need to be cautious of 2828 all choices and outcomes when handling SPF results. 2830 H.4. Policy For SPF Temperror 2832 The "temperror" result (see Section 2.6.6) indicates the SPF 2833 processing module at the receiver could not retrieve and SPF policy 2834 record due to a (probably) transient condition. This gives no true 2835 indication about the authorized use of the data found in the 2836 envelope. 2838 As with all results, implementers have a choice to make regarding 2839 what to do with a message that yields this result. SMTP allows only 2840 a few basic options. 2842 Deferring the message is an option, in that it is the one thing a 2843 receiver can do to draw attention to the difficulty encountered while 2844 protecting itself from messages that do not have a definite SPF 2845 result of some kind. However, if the SPF implementation is defective 2846 and returns spurious "temperror" results, only the sender is actively 2847 notified of the defect (in the form of mail rejected after it times 2848 out of the sending queue), and not the receiver making use of SPF. 2850 Because of long queue lifetimes, it is possible that mail will be 2851 repeatedly deferred for several days and so any awareness by the 2852 sender of a problem could be quite delayed. If "temperrors" persist 2853 for multiple delivery attempts, it might be preferable to treat the 2854 error as permanent and reduce the amount of time the message is in 2855 transit. 2857 The less intrusive handling choice is to deliver the message, perhaps 2858 with some kind of annotation of the difficulty encountered and/or 2859 logging of a similar nature. However, this will not be desirable to 2860 SPF verifier operators that wish to implement SPF checking as 2861 strictly as possible, nor is this sort of passive problem reporting 2862 typically effective. 2864 There is of course the option placing this choice in the hands of the 2865 SPF verifier operator rather than the implementer since this kind of 2866 choice is often a matter of local policy rather than a condition with 2867 a universal solution, but this adds one more piece of complexity to 2868 an already non-trivial environment. 2870 Both implementers and SPF verifier operators need to be cautious of 2871 all choices and outcomes when handling SPF results. 2873 Appendix I. Protocol Status 2875 NOTE TO RFC EDITOR: To be removed prior to publication. 2877 SPF has been in development since the summer of 2003 and has seen 2878 deployment beyond the developers beginning in December 2003. The 2879 design of SPF slowly evolved until the spring of 2004 and has since 2880 stabilized. There have been quite a number of forms of SPF, some 2881 written up as documents, some submitted as Internet Drafts, and many 2882 discussed and debated in development forums. The protocol was 2883 originally defined in [RFC4408], which this document replaces. 2885 [RFC4408] was designed to clearly document the protocol defined by 2886 earlier draft specifications of SPF as used in existing 2887 implementations. This updated specification is intended to clarify 2888 identified ambiguities in [RFC4408], resolve technical issues 2889 identified in post-RFC 4408 deployment experience, and document 2890 widely deployed extensions to SPF that have been developed since 2891 [RFC4408] was published. 2893 This document updates and replaces RFC 4408 that was part of a group 2894 of simultaneously published Experimental RFCs (RFC 4405, RFC 4406, 2895 RFC 4407, and RFC 4408) in 2006. At that time the IESG requested the 2896 community observe the success or failure of the two approaches 2897 documented in these RFCs during the two years following publication, 2898 in order that a community consensus could be reached in the future. 2900 SPF is widely deployed by large and small email providers alike. 2901 There are multiple, interoperable implementations. 2903 For SPF (as documented in RFC 4408) a careful effort was made to 2904 collect and document lessons learned and errata during the two year 2905 period. The errata list has been stable (no new submissions) and 2906 only minor protocol lessons learned were identified. Resolution of 2907 the IESG's experiment is documented in [RFC6686]. 2909 Appendix J. Change History 2911 NOTE TO RFC EDITOR: Changes since RFC 4408 (to be removed prior to 2912 publication) 2914 Moved to standards track 2916 Authors updated 2918 IESG Note regarding experimental use replaced with discussion of 2919 results 2921 Process errata: 2923 Resolved Section 2.5.7 PermError on invalid domains after macro 2924 expansion errata in favor of documenting that different verifiers 2925 produce different results. 2927 Add %v macro to ABNF grammar 2929 Replace "uric" by "unreserved" 2931 Recommend an SMTP reply code for optional permerror rejections 2933 Correct syntax in Received-SPF examples 2935 Fix unknown-modifier clause is too greedy in ABNF 2937 Correct use of empty domain-spec on exp modifier 2939 Fix minor typo errata 2941 Convert to spfbis working group draft, 2942 draft-ietf-spfbis-4408bis-00 2944 Clarified text about IPv4 mapped addresses to resolve test suite 2945 ambiguity 2947 Clarified ambiguity about result when more than 10 "mx" or "ptr" 2948 records are returned for lookup to specify permerror. This 2949 resolves one of the test suite ambiguities 2951 Made all references to result codes lower case per issue #7 2953 Adjusted section 2.2 Requirement to check mail from per issue #15 2955 Added missing "v" element in macro-letter in the collected ABNF 2956 per issue #16 - section 8.1 was already fixed in the pre-WG draft 2957 Marked ptr and "p" macro SHOULD NOT use per issue #27 2959 Expunged lower case may from the draft per issue #8 2961 Expunged "x-" name as an obsolete concept 2963 Updated obslete references: RFC2821 to RFC5321, RFC2822 to 2964 RFC5322, and RFC4234 to RFC5234 2966 Refer to RFC6647 to describe greylisting instead of trying to 2967 describe it directly. 2969 Updated informative references to the current versions. 2971 Start to rework section 9 with some RFC5598 terms. 2973 Added mention of RFC 6552 feedback reports in section 9. 2975 Added draft-ietf-spfbis-experiment as an informational reference. 2977 Drop Type SPF. 2979 Try and clarify informational nature of RFC3696 2981 Fix ABNF nits and add missing definitions per Bill's ABNF checker. 2983 Make DNS lookup time limit SHOULD instead of MAY. 2985 Reorganize and clarify processing limits. Move hard limits to new 2986 section 4.6.4, Evaluation Limits. Move advice to non-normative 2987 section 10. 2989 Removed paragraph in section 11.1 about limiting total data 2990 volumes as it is unused (and removable per the charter) and serves 2991 no purpose (it isn't something that actually can be implemented in 2992 any reasonable way). 2994 Added text from Alessandro Vesely in section 10.1 to better 2995 explain DNS resource limits. 2997 Multiple editorial fixes from Murray Kucherawy's review. 2999 Also based on Murray's review, reworked SMTP identity definitions 3000 and made RFC 5598 a normative reference instead of informative. 3001 This is a downref that will have to be mentioned in the last call. 3003 Added RFC 3834 as an informative reference about backscatter. 3005 Added IDN requirements and normative reference to RFC 5890 to deal 3006 with the question "like DKIM did it.: 3008 Added informative reference to RFC 4632 for CIDR and use CIDR 3009 prefix length instead of CIDR-length to match its terminology. 3011 Simplified the exists description. 3013 Added text on creating a Authentication-Results header field that 3014 matches the Received-SPF header field information and added a 3015 normative reference to RFC 5451. 3017 Added informative reference to RFC 2782 due to SRV mention. 3019 Added informative reference to RFC 3464 due to DSN mention. 3021 Added informative reference to RFC 5617 for its DNS wildcard use. 3023 Clarified the intended match/no-match method for exists. 3025 Added new sections on Receiver policy for SPF pass, fail, and 3026 permerror. 3028 Added new section 10 discussion on treatment of bounces and the 3029 significance of HELO records. 3031 Added request to IANA to update the SPF modifier registry. 3033 Substantially reorganized the document for improved readability 3034 for new users based on WG consensus. 3036 Added new DNS "void lookup" processing limit to mitigate potential 3037 future risk of SPF being used as a DDoS vector. 3039 Author's Address 3041 Scott Kitterman 3042 Kitterman Technical Services 3043 3611 Scheel Dr 3044 Ellicott City, MD 21042 3045 United States of America 3047 Email: scott@kitterman.com