Internet Engineering Task Force (IETF) S. Kitterman
Request for Comments: 7208 Kitterman Technical Services
Obsoletes: 4408 April 2014
Category: Standards Track
ISSN: 2070-1721
Internet Engineering Task Force (IETF) S. Kitterman
Request for Comments: 7208 Kitterman Technical Services
Obsoletes: 4408 April 2014
Category: Standards Track
ISSN: 2070-1721
Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1
用于授权在电子邮件中使用域的发件人策略框架（SPF），版本1
Abstract
摘要
Email on the Internet can be forged in a number of ways. In particular, existing protocols place no restriction on what a sending host can use as the "MAIL FROM" of a message or the domain given on the SMTP HELO/EHLO commands. This document describes version 1 of the Sender Policy Framework (SPF) protocol, whereby ADministrative Management Domains (ADMDs) can explicitly authorize the hosts that are allowed to use their domain names, and a receiving host can check such authorization.
互联网上的电子邮件可以通过多种方式伪造。特别是，现有的协议对发送主机可以用作消息的“邮件发件人”或SMTP HELO/EHLO命令中给定的域没有任何限制。本文档介绍了发送方策略框架（SPF）协议的第1版，其中，管理管理域（ADMD）可以显式授权允许使用其域名的主机，并且接收主机可以检查此类授权。
This document obsoletes RFC 4408.
本文件淘汰了RFC 4408。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7208.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7208.
Copyright Notice
版权公告
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2014 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。
Table of Contents
目录
1. Introduction ....................................................5
1.1. Terminology ................................................5
1.1.1. Key Words ...........................................5
1.1.2. Imported Definitions ................................5
1.1.3. MAIL FROM Definition ................................6
1.1.4. HELO Definition .....................................6
1.2. check_host() ...............................................6
2. Operational Overview ............................................6
2.1. Publishing Authorization ...................................6
2.2. Checking Authorization .....................................7
2.3. The "HELO" Identity ........................................8
2.4. The "MAIL FROM" Identity ...................................9
2.5. Location of Checks .........................................9
2.6. Results of Evaluation ......................................9
2.6.1. None ...............................................10
2.6.2. Neutral ............................................10
2.6.3. Pass ...............................................10
2.6.4. Fail ...............................................10
1. Introduction ....................................................5
1.1. Terminology ................................................5
1.1.1. Key Words ...........................................5
1.1.2. Imported Definitions ................................5
1.1.3. MAIL FROM Definition ................................6
1.1.4. HELO Definition .....................................6
1.2. check_host() ...............................................6
2. Operational Overview ............................................6
2.1. Publishing Authorization ...................................6
2.2. Checking Authorization .....................................7
2.3. The "HELO" Identity ........................................8
2.4. The "MAIL FROM" Identity ...................................9
2.5. Location of Checks .........................................9
2.6. Results of Evaluation ......................................9
2.6.1. None ...............................................10
2.6.2. Neutral ............................................10
2.6.3. Pass ...............................................10
2.6.4. Fail ...............................................10
2.6.5. Softfail ...........................................10
2.6.6. Temperror ..........................................10
2.6.7. Permerror ..........................................10
3. SPF Records ....................................................11
3.1. DNS Resource Records ......................................11
3.2. Multiple DNS Records ......................................12
3.3. Multiple Strings in a Single DNS Record ...................12
3.4. Record Size ...............................................13
3.5. Wildcard Records ..........................................13
4. The check_host() Function ......................................14
4.1. Arguments .................................................14
4.2. Results ...................................................15
4.3. Initial Processing ........................................15
4.4. Record Lookup .............................................15
4.5. Selecting Records .........................................15
4.6. Record Evaluation .........................................16
4.6.1. Term Evaluation ....................................16
4.6.2. Mechanisms .........................................16
4.6.3. Modifiers ..........................................17
4.6.4. DNS Lookup Limits ..................................17
4.7. Default Result ............................................18
4.8. Domain Specification ......................................19
5. Mechanism Definitions ..........................................20
5.1. "all" .....................................................21
5.2. "include" .................................................21
5.3. "a" .......................................................23
5.4. "mx" ......................................................23
5.5. "ptr" (do not use) ........................................23
5.6. "ip4" and "ip6" ...........................................25
5.7. "exists" ..................................................25
6. Modifier Definitions ...........................................26
6.1. redirect: Redirected Query ................................26
6.2. exp: Explanation ..........................................27
7. Macros .........................................................28
7.1. Formal Specification ......................................29
7.2. Macro Definitions .........................................29
7.3. Macro Processing Details ..................................30
7.4. Expansion Examples ........................................32
8. Result Handling ................................................33
8.1. None ......................................................34
8.2. Neutral ...................................................34
8.3. Pass ......................................................34
8.4. Fail ......................................................35
8.5. Softfail ..................................................35
8.6. Temperror .................................................36
8.7. Permerror .................................................36
2.6.5. Softfail ...........................................10
2.6.6. Temperror ..........................................10
2.6.7. Permerror ..........................................10
3. SPF Records ....................................................11
3.1. DNS Resource Records ......................................11
3.2. Multiple DNS Records ......................................12
3.3. Multiple Strings in a Single DNS Record ...................12
3.4. Record Size ...............................................13
3.5. Wildcard Records ..........................................13
4. The check_host() Function ......................................14
4.1. Arguments .................................................14
4.2. Results ...................................................15
4.3. Initial Processing ........................................15
4.4. Record Lookup .............................................15
4.5. Selecting Records .........................................15
4.6. Record Evaluation .........................................16
4.6.1. Term Evaluation ....................................16
4.6.2. Mechanisms .........................................16
4.6.3. Modifiers ..........................................17
4.6.4. DNS Lookup Limits ..................................17
4.7. Default Result ............................................18
4.8. Domain Specification ......................................19
5. Mechanism Definitions ..........................................20
5.1. "all" .....................................................21
5.2. "include" .................................................21
5.3. "a" .......................................................23
5.4. "mx" ......................................................23
5.5. "ptr" (do not use) ........................................23
5.6. "ip4" and "ip6" ...........................................25
5.7. "exists" ..................................................25
6. Modifier Definitions ...........................................26
6.1. redirect: Redirected Query ................................26
6.2. exp: Explanation ..........................................27
7. Macros .........................................................28
7.1. Formal Specification ......................................29
7.2. Macro Definitions .........................................29
7.3. Macro Processing Details ..................................30
7.4. Expansion Examples ........................................32
8. Result Handling ................................................33
8.1. None ......................................................34
8.2. Neutral ...................................................34
8.3. Pass ......................................................34
8.4. Fail ......................................................35
8.5. Softfail ..................................................35
8.6. Temperror .................................................36
8.7. Permerror .................................................36
9. Recording the Result ...........................................36
9.1. The Received-SPF Header Field .............................37
9.2. SPF Results in the Authentication-Results Header Field ....39
10. Effects on Infrastructure .....................................39
10.1. Sending Domains ..........................................40
10.1.1. DNS Resource Considerations .......................40
10.1.2. Administrator's Considerations ....................41
10.1.3. Bounces ...........................................41
10.2. Receivers ................................................42
10.3. Mediators ................................................42
11. Security Considerations .......................................43
11.1. Processing Limits ........................................43
11.2. SPF-Authorized Email May Contain Other False Identities ..44
11.3. Spoofed DNS and IP Data ..................................44
11.4. Cross-User Forgery .......................................44
11.5. Untrusted Information Sources ............................45
11.5.1. Recorded Results ..................................45
11.5.2. External Explanations .............................45
11.5.3. Macro Expansion ...................................46
11.6. Privacy Exposure .........................................46
11.7. Delivering Mail Producing a "Fail" Result ................46
12. Collected ABNF ................................................46
13. Contributors and Acknowledgements .............................48
14. IANA Considerations ...........................................49
14.1. The SPF DNS Record Type ..................................49
14.2. The Received-SPF Mail Header Field .......................50
14.3. SPF Modifier Registry ....................................50
15. References ....................................................50
15.1. Normative References .....................................50
15.2. Informative References ...................................51
Appendix A. Extended Examples .....................................54
A.1. Simple Examples ............................................55
A.2. Multiple Domain Example ....................................56
A.3. DNS Blacklist (DNSBL) Style Example ........................56
A.4. Multiple Requirements Example ..............................57
Appendix B. Changes in Implementation Requirements from RFC 4408 ..57
Appendix C. Further Testing Advice ................................58
Appendix D. SPF/Mediator Interactions .............................59
D.1. Originating ADMDs ..........................................59
D.2. Mediators ..................................................60
D.3. Receiving ADMDs ............................................60
Appendix E. Mail Services .........................................61
Appendix F. MTA Relays ............................................61
Appendix G. Local Policy Considerations ...........................62
G.1. Policy for SPF Pass ........................................62
G.2. Policy for SPF Fail ........................................62
G.3. Policy for SPF Permerror ...................................63
G.4. Policy for SPF Temperror ...................................63
9. Recording the Result ...........................................36
9.1. The Received-SPF Header Field .............................37
9.2. SPF Results in the Authentication-Results Header Field ....39
10. Effects on Infrastructure .....................................39
10.1. Sending Domains ..........................................40
10.1.1. DNS Resource Considerations .......................40
10.1.2. Administrator's Considerations ....................41
10.1.3. Bounces ...........................................41
10.2. Receivers ................................................42
10.3. Mediators ................................................42
11. Security Considerations .......................................43
11.1. Processing Limits ........................................43
11.2. SPF-Authorized Email May Contain Other False Identities ..44
11.3. Spoofed DNS and IP Data ..................................44
11.4. Cross-User Forgery .......................................44
11.5. Untrusted Information Sources ............................45
11.5.1. Recorded Results ..................................45
11.5.2. External Explanations .............................45
11.5.3. Macro Expansion ...................................46
11.6. Privacy Exposure .........................................46
11.7. Delivering Mail Producing a "Fail" Result ................46
12. Collected ABNF ................................................46
13. Contributors and Acknowledgements .............................48
14. IANA Considerations ...........................................49
14.1. The SPF DNS Record Type ..................................49
14.2. The Received-SPF Mail Header Field .......................50
14.3. SPF Modifier Registry ....................................50
15. References ....................................................50
15.1. Normative References .....................................50
15.2. Informative References ...................................51
Appendix A. Extended Examples .....................................54
A.1. Simple Examples ............................................55
A.2. Multiple Domain Example ....................................56
A.3. DNS Blacklist (DNSBL) Style Example ........................56
A.4. Multiple Requirements Example ..............................57
Appendix B. Changes in Implementation Requirements from RFC 4408 ..57
Appendix C. Further Testing Advice ................................58
Appendix D. SPF/Mediator Interactions .............................59
D.1. Originating ADMDs ..........................................59
D.2. Mediators ..................................................60
D.3. Receiving ADMDs ............................................60
Appendix E. Mail Services .........................................61
Appendix F. MTA Relays ............................................61
Appendix G. Local Policy Considerations ...........................62
G.1. Policy for SPF Pass ........................................62
G.2. Policy for SPF Fail ........................................62
G.3. Policy for SPF Permerror ...................................63
G.4. Policy for SPF Temperror ...................................63
The current email infrastructure has the property that any host injecting mail into the system can use any DNS domain name it wants in each of the various identifiers specified by [RFC5321] and [RFC5322]. Although this feature is desirable in some circumstances, it is a major obstacle to reducing Unsolicited Bulk Email (UBE, aka spam). Furthermore, ADMDs (as described in [RFC5598]) are understandably concerned about the ease with which other entities can make use of their domain names, often with malicious intent.
当前的电子邮件基础结构具有这样的属性：任何将邮件注入系统的主机都可以在[RFC5321]和[RFC5322]指定的各种标识符中使用它想要的任何DNS域名。虽然这一功能在某些情况下是可取的，但它是减少未经请求的批量电子邮件（UBE，又称垃圾邮件）的主要障碍。此外，ADMD（如[RFC5598]中所述）担心其他实体很容易利用其域名，这是可以理解的，通常是出于恶意目的。
This document defines a protocol by which ADMDs can authorize hosts to use their domain names in the "MAIL FROM" or "HELO" identities. Compliant ADMDs publish Sender Policy Framework (SPF) records in the DNS specifying which hosts are permitted to use their names, and compliant mail receivers use the published SPF records to test the authorization of sending Mail Transfer Agents (MTAs) using a given "HELO" or "MAIL FROM" identity during a mail transaction.
本文档定义了一个协议，通过该协议，ADMD可以授权主机在“邮件发件人”或“直升机”身份中使用其域名。符合要求的ADMD在DNS中发布发件人策略框架（SPF）记录，指定允许哪些主机使用其名称，符合要求的邮件收件人使用发布的SPF记录在邮件事务期间使用给定的“HELO”或“mail FROM”标识测试发送邮件传输代理（MTA）的授权。
An additional benefit to mail receivers is that after the use of an identity is verified, local policy decisions about the mail can be made based on the sender's domain, rather than the host's IP address. This is advantageous because reputation of domain names is likely to be more accurate than reputation of host IP addresses since domains are likely to be more stable over a longer period. Furthermore, if a claimed identity fails verification, local policy can take stronger action against such email, such as rejecting it.
邮件接收者的另一个好处是，在验证身份的使用后，可以根据发件人的域而不是主机的IP地址来做出有关邮件的本地策略决策。这是有利的，因为域名的信誉可能比主机IP地址的信誉更准确，因为域可能在更长的时间内更稳定。此外，如果声明的身份验证失败，当地政策可以对此类电子邮件采取更有力的措施，如拒绝。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”应按照[RFC2119]中的说明进行解释。
ABNF (Augmented Backus-Naur Form) ABNF is defined in [RFC5234], as are the tokens "ALPHA", "DIGIT", and "SP" (space).
[RFC5234]中定义了ABNF（增强的巴科斯-诺尔形式），以及标记“ALPHA”、“DIGIT”和“SP”（空格）。
The tokens "Local-part", "Domain", and "Mailbox" are defined in [RFC5321].
标记“本地部分”、“域”和“邮箱”在[RFC5321]中定义。
"dot-atom", "quoted-string", "comment", "CFWS" (comment folded white space), "FWS" (folded white space), and "CRLF" (carriage-return/ line-feed) are defined in [RFC5322].
[RFC5322]中定义了“点原子”、“引用字符串”、“注释”、“CFWS”（注释折叠空白）、“FWS”（折叠空白）和“CRLF”（回车/换行符）。
This document is concerned with the identity of the sender of a mail message, as referred to in [RFC5321]:
本文档涉及[RFC5321]中提到的邮件消息发送者的身份：
The transaction starts with a MAIL command that gives the sender identification.
事务以一个提供发件人标识的邮件命令开始。
Since there are many other names for this identity, it is important to choose a name that is:
由于此标识还有许多其他名称，因此选择以下名称非常重要：
1. commonly used
1. 常用
2. well defined
2. 明确的
As such, throughout this document the term "MAIL FROM" will be used, which is defined as the RFC5321.MailFrom (reverse-path) identity described in [RFC5598].
因此，在本文件中，将使用术语“邮件发件人”，其定义为[RFC5598]中所述的RFC5321.MailFrom（反向路径）标识。
This document also makes use of the HELO/EHLO identity. The "HELO" identity derives from either the SMTP HELO or EHLO command (see [RFC5321]). Since HELO and EHLO can, in many cases, be used interchangeably, they are identified commonly as "HELO" in this document. This means RFC5321.HELO/.EHLO as defined in [RFC5598]. These commands supply the identity of the SMTP client (sending host) for the SMTP session.
本文件还使用HELO/EHLO标识。“HELO”标识来自SMTP HELO或EHLO命令（请参阅[RFC5321]）。由于HELO和EHLO在许多情况下可以互换使用，因此在本文件中通常将其标识为“HELO”。这意味着[RFC5598]中定义的RFC5321.HELO/.EHLO。这些命令为SMTP会话提供SMTP客户端（发送主机）的标识。
Section 4 introduces an algorithm to evaluate an SPF policy against an arriving email transaction. In an early implementation, this algorithm was encoded in a function called check_host(). That name is used in this document as symbolic of the SPF evaluation algorithm, but of course implementers are not required to use this name.
第4节介绍了一种针对到达的电子邮件事务评估SPF策略的算法。在早期的实现中，该算法编码在一个名为check_host（）的函数中。该名称在本文档中用作SPF评估算法的符号，但当然，实现者不需要使用该名称。
An SPF-compliant domain publishes valid SPF records as described in Section 3. These records authorize the use of the relevant domain names in the "HELO" and "MAIL FROM" identities by the MTAs specified therein.
符合SPF的域发布有效的SPF记录，如第3节所述。这些记录授权其中指定的MTA使用“HELO”和“MAIL FROM”身份中的相关域名。
SPF results can be used to make both positive (source is authorized) and negative (source is not authorized) determinations. If ADMDs choose to publish SPF records and want to support receivers making negative authorization determinations, it is necessary for them to publish records that end in "-all", or redirect to other records that do; otherwise, no definitive determination of authorization can be made. Potential issues and mitigations associated with negative determinations are discussed in Section 10.
SPF结果可用于进行阳性（来源已授权）和阴性（来源未授权）测定。如果ADMD选择发布SPF记录并希望支持接收者做出否定授权决定，则有必要发布以“-all”结尾的记录，或重定向到其他以“-all”结尾的记录；否则，无法确定授权。第10节讨论了与负面决定相关的潜在问题和缓解措施。
ADMDs that wish to declare that no hosts are authorized to use their DNS domain names in the HELO or MAIL FROM commands during SMTP sessions can publish SPF records that say so for domain names that are neither used in the domain part of email addresses nor expected to originate mail.
如果ADMD希望声明没有主机被授权在SMTP会话期间在HELO或MAIL FROM命令中使用其DNS域名，则ADMD可以发布SPF记录，这些SPF记录对既不在电子邮件地址的域部分中使用也不希望发起邮件的域名是这样说的。
When changing SPF records, care has to be taken to ensure that there is a transition period so that the old policy remains valid until all legitimate email can reasonably expect to have been checked. [RFC5321], Section 4.5.4.1 discusses how long a message might be in transit. While offline checks are possible, the closer to the original transmission time checks are performed, the more likely they are to get an SPF result that matches the sending ADMD intent at the time the message was sent.
在更改SPF记录时，必须注意确保有一个过渡期，以便旧政策保持有效，直到所有合法电子邮件都可以合理预期得到检查。[RFC5321]，第4.5.4.1节讨论了消息在传输过程中的时间长度。虽然可以进行脱机检查，但执行的传输时间检查越接近原始传输时间，就越有可能获得与发送消息时发送ADMD意图相匹配的SPF结果。
A mail receiver can perform a set of SPF checks for each mail message it receives. An SPF check tests the authorization of a client host to emit mail with a given identity. Typically, such checks are done by a receiving MTA, but can be performed elsewhere in the mail processing chain so long as the required information is available and reliable. The "MAIL FROM" and "HELO" identities are checked as described in Sections 2.4 and 2.3, respectively.
邮件接收者可以对收到的每封邮件执行一组SPF检查。SPF检查测试客户端主机发出具有给定标识的邮件的授权。通常，此类检查由接收MTA完成，但只要所需信息可用且可靠，就可以在邮件处理链的其他位置执行。分别按照第2.4节和第2.3节所述检查“邮件发件人”和“直升机”身份。
Without explicit approval of the publishing ADMD, checking other identities against SPF version 1 records is NOT RECOMMENDED because there are cases that are known to give incorrect results. For example, almost all mailing lists rewrite the "MAIL FROM" identity (see Section 10.3), but some do not change any other identities in the message. Documents that define other identities will have to define the method for explicit approval.
未经发布ADMD的明确批准，不建议根据SPF版本1记录检查其他身份，因为存在已知结果不正确的情况。例如，几乎所有邮件列表都会重写“邮件发件人”标识（请参见第10.3节），但有些列表不会更改邮件中的任何其他标识。定义其他标识的文档必须定义明确批准的方法。
It is possible that mail receivers will use the SPF check as part of a larger set of tests on incoming mail. The results of other tests might influence whether or not a particular SPF check is performed. For example, finding the sending host's IP address on a local whitelist might cause all other tests to be skipped and all mail from that host to be accepted.
邮件接收者可能会使用SPF检查作为对传入邮件的一组更大测试的一部分。其他测试的结果可能会影响是否执行特定SPF检查。例如，在本地白名单上查找发送主机的IP地址可能会导致跳过所有其他测试，并接受来自该主机的所有邮件。
When a mail receiver decides to perform an SPF check, it has to use a correctly implemented check_host() function (Section 4) evaluated with the correct parameters. Although the test as a whole is optional, once it has been decided to perform a test it has to be performed as specified so that the correct semantics are preserved between publisher and receiver.
当邮件接收者决定执行SPF检查时，必须使用正确实现的check_host（）函数（第4节），并使用正确的参数进行计算。尽管测试作为一个整体是可选的，但一旦决定执行测试，就必须按照指定的方式执行，以便在发布者和接收者之间保留正确的语义。
To make the test, the mail receiver MUST evaluate the check_host() function with the arguments described in Section 4.1.
为了进行测试，邮件接收者必须使用第4.1节中描述的参数计算check_host（）函数。
Although invalid, malformed, or non-existent domains cause SPF checks to return "none" because no SPF record can be found, it has long been the policy of many MTAs to reject email from such domains, especially in the case of invalid "MAIL FROM". Rejecting email will prevent one method of circumventing of SPF records.
尽管无效、格式错误或不存在的域会导致SPF检查返回“无”，因为找不到SPF记录，但长期以来，许多MTA的策略是拒绝来自此类域的电子邮件，尤其是在“来自”的邮件无效的情况下。拒绝电子邮件将防止一种规避SPF记录的方法。
Implementations have to take care to correctly extract the <domain> from the data given with the SMTP MAIL FROM command as many MTAs will still accept such things as source routes (see Appendix C of [RFC5321]), the %-hack (see [RFC1123]), and bang paths (see [RFC1983]). These archaic features have been maliciously used to bypass security systems.
实现必须注意从SMTP MAIL from命令提供的数据中正确提取<domain>，因为许多MTA仍然会接受诸如源路由（请参见[RFC5321]的附录C）、%-hack（请参见[RFC1123]）和bang路径（请参见[RFC1983]）。这些过时的功能被恶意用于绕过安全系统。
It is RECOMMENDED that SPF verifiers not only check the "MAIL FROM" identity but also separately check the "HELO" identity by applying the check_host() function (Section 4) to the "HELO" identity as the <sender>. Checking "HELO" promotes consistency of results and can reduce DNS resource usage. If a conclusive determination about the message can be made based on a check of "HELO", then the use of DNS resources to process the typically more complex "MAIL FROM" can be avoided. Additionally, since SPF records published for "HELO" identities refer to a single host, when available, they are a very reliable source of host authorization status. Checking "HELO" before "MAIL FROM" is the RECOMMENDED sequence if both are checked.
建议SPF验证器不仅检查“邮件发件人”身份，还通过将check_host（）函数（第4节）应用于作为<sender>的“HELO”身份来单独检查“HELO”身份。检查“HELO”可以提高结果的一致性，并可以减少DNS资源的使用。如果可以基于对“HELO”的检查做出关于消息的结论性确定，那么可以避免使用DNS资源来处理通常更复杂的“来自”的邮件。此外，由于为“HELO”标识发布的SPF记录指的是单个主机，因此在可用时，它们是主机授权状态的非常可靠的来源。如果同时选中“HELO”和“MAIL FROM”，则建议先选中“HELO”再选中“MAIL FROM”。
Note that requirements for the domain presented in the EHLO or HELO command are not always clear to the sending party, and SPF verifiers have to be prepared for the identity to be an IP address literal (see [RFC5321], Section 4.1.3) or simply be malformed. This SPF check can only be performed when the "HELO" string is a valid, multi-label domain name.
请注意，发送方并不总是清楚EHLO或HELO命令中提出的域要求，SPF验证器必须准备好将身份作为IP地址文本（请参见[RFC5321]，第4.1.3节）或只是格式错误。只有当“HELO”字符串是有效的多标签域名时，才能执行此SPF检查。
SPF verifiers MUST check the "MAIL FROM" identity if a "HELO" check either has not been performed or has not reached a definitive policy result by applying the check_host() function to the "MAIL FROM" identity as the <sender>.
如果“HELO”检查未执行或未通过将check_host（）函数应用于作为<发件人>的“MAIL FROM”标识来达到最终策略结果，SPF验证器必须检查“MAIL FROM”标识。
[RFC5321] allows the reverse-path to be null (see Section 4.5.5 in [RFC5321]). In this case, there is no explicit sender mailbox, and such a message can be assumed to be a notification message from the mail system itself. When the reverse-path is null, this document defines the "MAIL FROM" identity to be the mailbox composed of the local-part "postmaster" and the "HELO" identity (which might or might not have been checked separately before).
[RFC5321]允许反向路径为空（参见[RFC5321]中的第4.5.5节）。在这种情况下，没有显式的发件人邮箱，可以假定这样的消息是来自邮件系统本身的通知消息。当反向路径为空时，本文档将“邮件发件人”标识定义为由本地部分“邮局主管”和“直升机”标识（以前可能会或可能不会单独检查）组成的邮箱。
The authorization check SHOULD be performed during the processing of the SMTP transaction that receives the mail. This reduces the complexity of determining the correct IP address to use as an input to check_host() and allows errors to be returned directly to the sending MTA by way of SMTP replies. Appendix D of [RFC7001] provides a more thorough discussion of this topic.
应在处理接收邮件的SMTP事务期间执行授权检查。这降低了确定要用作check_host（）输入的正确IP地址的复杂性，并允许通过SMTP回复将错误直接返回给发送MTA。[RFC7001]的附录D对此主题进行了更深入的讨论。
The authorization check is performed during the SMTP transaction at the time of the MAIL command, and uses the MAIL FROM value and the client IP address. Performing the check at later times or with other input can cause problems such as the following:
授权检查在执行MAIL命令时的SMTP事务期间执行，并使用MAIL FROM值和客户端IP地址。稍后执行检查或使用其他输入可能会导致以下问题：
o It might be difficult to accurately extract the required information from potentially deceptive headers.
o 从可能具有欺骗性的标题中准确提取所需的信息可能很困难。
o Legitimate email might fail the authorization check because the sender's policy has since changed.
o 合法电子邮件可能无法通过授权检查，因为发件人的策略已更改。
Generating non-delivery notifications to forged identities that have failed the authorization check often constitutes backscatter, i.e., nuisance rejection notices that are not actionable. Operators are strongly advised to avoid such practices. Section 2 of [RFC3834] describes backscatter and the problems it causes.
向未通过授权检查的伪造身份生成未送达通知通常构成反向散射，即不可采取行动的妨害性拒绝通知。强烈建议运营商避免此类做法。[RFC3834]第2节描述了后向散射及其引起的问题。
Section 4 defines check_host(), a model function definition that uses the inputs defined above and the sender's policy published in the DNS to reach a conclusion about client authorization. An SPF verifier implements something semantically equivalent to the function defined there.
第4节定义了check_host（），这是一个模型函数定义，它使用上面定义的输入和DNS中发布的发送方策略来得出有关客户端授权的结论。SPF验证器在语义上实现与此处定义的函数等价的东西。
This section enumerates and briefly defines the possible outputs of that function. Note, however, that the protocol establishes no normative requirements for handling any particular result. Discussion of handling options for each result can be found in Section 8.
本节列举并简要定义该功能的可能输出。然而，请注意，该协议没有规定处理任何特定结果的规范性要求。关于每个结果的处理选项的讨论见第8节。
A result of "none" means either (a) no syntactically valid DNS domain name was extracted from the SMTP session that could be used as the one to be authorized, or (b) no SPF records were retrieved from the DNS.
“无”的结果表示（A）未从SMTP会话提取语法有效的DNS域名，该域名可用作要授权的域名，或（b）未从DNS检索到SPF记录。
A "neutral" result means the ADMD has explicitly stated that it is not asserting whether the IP address is authorized.
“中立”结果意味着ADMD已明确声明它未断言IP地址是否已授权。
A "pass" result is an explicit statement that the client is authorized to inject mail with the given identity.
“通过”结果是一个明确的声明，表明客户端有权使用给定的身份注入邮件。
A "fail" result is an explicit statement that the client is not authorized to use the domain in the given identity.
“失败”结果是一个明确的声明，表明客户端无权使用给定标识中的域。
A "softfail" result is a weak statement by the publishing ADMD that the host is probably not authorized. It has not published a stronger, more definitive policy that results in a "fail".
“softfail”结果是发布ADMD发出的关于主机可能未经授权的弱声明。它还没有公布一项更强有力、更明确的政策，导致“失败”。
A "temperror" result means the SPF verifier encountered a transient (generally DNS) error while performing the check. A later retry may succeed without further DNS operator action.
“temperror”结果表示SPF验证器在执行检查时遇到暂时（通常为DNS）错误。以后的重试可能会成功，而无需DNS操作员进一步操作。
A "permerror" result means the domain's published records could not be correctly interpreted. This signals an error condition that definitely requires DNS operator intervention to be resolved.
“permerror”结果意味着无法正确解释域的已发布记录。这表明存在一个错误情况，需要DNS操作员干预才能解决。
An SPF record is a DNS record that declares which hosts are, and are not, authorized to use a domain name for the "HELO" and "MAIL FROM" identities. Loosely, the record partitions hosts into permitted and not-permitted sets (though some hosts might fall into neither category).
SPF记录是一个DNS记录，它声明哪些主机被授权或未被授权为“HELO”和“MAIL FROM”标识使用域名。松散地说，该记录将主机划分为允许集和不允许集（尽管有些主机可能不属于这两个类别）。
The SPF record is expressed as a single string of text found in the RDATA of a single DNS TXT resource record; multiple SPF records are not permitted for the same owner name. The record format and the process for selecting records are described below in Section 4. An example record is the following:
SPF记录表示为单个DNS TXT资源记录的RDATA中的单个文本字符串；同一所有者名称不允许有多个SPF记录。记录格式和选择记录的过程在下文第4节中描述。下面是一个示例记录：
v=spf1 +mx a:colo.example.com/28 -all
v=spf1 +mx a:colo.example.com/28 -all
This record has a version of "spf1" and three directives: "+mx", "a:colo.example.com/28" (the "+" is implied), and "-all".
该记录有一个版本的“spf1”和三个指令：“+mx”、“a:colo.example.com/28”（暗含“+”）和“-all”。
Each SPF record is placed in the DNS tree at the owner name it pertains to, not in a subdomain under the owner name. This is similar to how SRV records [RFC2782] are done.
每个SPF记录都以其所属的所有者名称放置在DNS树中，而不是位于所有者名称下的子域中。这类似于SRV记录[RFC2782]的处理方式。
The example in this section might be published via these lines in a domain zone file:
本节中的示例可能通过域区域文件中的以下行发布：
example.com. TXT "v=spf1 +mx a:colo.example.com/28 -all"
example.com. TXT "v=spf1 +mx a:colo.example.com/28 -all"
Since TXT records have multiple uses, beware of other TXT records published there for other purposes. They might cause problems with size limits (see Section 3.4), and care has to be taken to ensure that only SPF records are used for SPF processing.
由于TXT记录有多种用途，请注意出于其他目的发布的其他TXT记录。它们可能会导致大小限制问题（见第3.4节），必须注意确保SPF处理仅使用SPF记录。
ADMDs publishing SPF records ought to keep the amount of DNS information needed to evaluate a record to a minimum. Sections 4.6.4 and 10.1.1 provide some suggestions about "include" mechanisms and chained "redirect" modifiers.
发布SPF记录的ADMD应将评估记录所需的DNS信息量保持在最低限度。第4.6.4节和第10.1.1节提供了一些关于“包括”机制和链式“重定向”修饰符的建议。
SPF records MUST be published as a DNS TXT (type 16) Resource Record (RR) [RFC1035] only. The character content of the record is encoded as [US-ASCII]. Use of alternative DNS RR types was supported in SPF's experimental phase but has been discontinued.
SPF记录必须仅作为DNS TXT（类型16）资源记录（RR）[RFC1035]发布。记录的字符内容编码为[US-ASCII]。SPF的实验阶段支持使用替代DNS RR类型，但已停止使用。
In 2003, when SPF was first being developed, the requirements for assignment of a new DNS RR type were considerably more stringent than they are now. Additionally, support for easy deployment of new DNS
2003年，当SPF首次开发时，分配新DNS RR类型的要求比现在严格得多。此外，支持轻松部署新的DNS
RR types was not widely deployed in DNS servers and provisioning systems. As a result, developers of SPF found it easier and more practical to use the TXT RR type for SPF records.
RR类型未广泛部署在DNS服务器和供应系统中。因此，SPF的开发人员发现对SPF记录使用TXT RR类型更容易、更实用。
In its review of [RFC4408], the SPFbis working group concluded that its dual RR type transition model was fundamentally flawed since it contained no common RR type that implementers were required to serve and required to check. Many alternatives were considered to resolve this issue, but ultimately the working group concluded that significant migration to the SPF RR type in the foreseeable future was very unlikely and that the best solution for resolving this interoperability issue was to drop support for the SPF RR type from SPF version 1. See Appendix A of [RFC6686] for further information.
在对[RFC4408]的审查中，SPFbis工作组得出结论，其双RR类型转换模型存在根本性缺陷，因为它不包含要求实施者服务和检查的通用RR类型。考虑了许多替代方案来解决此问题，但工作组最终得出结论，在可预见的未来，不太可能大量迁移到SPF RR类型，解决此互操作性问题的最佳解决方案是从SPF版本1中放弃对SPF RR类型的支持。更多信息，请参见[RFC6686]的附录A。
The circumstances surrounding SPF's initial deployment a decade ago are unique. If a future update to SPF were developed that did not reuse existing SPF records, it could use the SPF RR type. SPF's use of the TXT RR type for structured data should in no way be taken as precedent for future protocol designers. Further discussion of design considerations when using new DNS RR types can be found in [RFC5507].
十年前SPF最初部署的环境是独一无二的。如果开发的SPF未来更新不重用现有SPF记录，则可以使用SPF RR类型。SPF对结构化数据使用TXT RR类型决不能作为未来协议设计者的先例。在[RFC5507]中可以找到关于使用新DNS RR类型时设计注意事项的进一步讨论。
A domain name MUST NOT have multiple records that would cause an authorization check to select more than one record. See Section 4.5 for the selection rules.
域名不能有多个记录，这会导致授权检查选择多个记录。选择规则见第4.5节。
As defined in [RFC1035], Sections 3.3 and 3.3.14, a single text DNS record can be composed of more than one string. If a published record contains multiple character-strings, then the record MUST be treated as if those strings are concatenated together without adding spaces. For example:
如[RFC1035]第3.3节和第3.3.14节所定义，单个文本DNS记录可以由多个字符串组成。如果发布的记录包含多个字符串，则必须将该记录视为将这些字符串连接在一起而不添加空格。例如：
IN TXT "v=spf1 .... first" "second string..."
IN TXT "v=spf1 .... first" "second string..."
is equivalent to:
相当于：
IN TXT "v=spf1 .... firstsecond string..."
IN TXT "v=spf1 .... firstsecond string..."
TXT records containing multiple strings are useful in constructing records that would exceed the 255-octet maximum length of a character-string within a single TXT record.
包含多个字符串的TXT记录有助于在单个TXT记录中构造超过字符串最大长度255个八位字节的记录。
The published SPF record for a given domain name SHOULD remain small enough that the results of a query for it will fit within 512 octets. Otherwise, there is a possibility of exceeding a DNS protocol limit. This UDP limit is defined in [RFC1035], Section 2.3.4, although it was raised by [RFC2671]. Staying below 512 octets ought to prevent older DNS implementations from failing over to TCP and will work with UDP in the absence of EDNS0 [RFC6891] support. Since the answer size is dependent on many things outside the scope of this document, it is only possible to give this guideline: If the size of the DNS message, the combined length of the DNS name and the text of all the records of a given type is under 450 octets, then DNS answers ought to fit in UDP packets. Records that are too long to fit in a single UDP packet could be silently ignored by SPF verifiers due to firewall and other issues that interfere with the operation of DNS over TCP or using ENDS0.
给定域名的已发布SPF记录应保持足够小，以便查询结果在512个八位字节以内。否则，可能会超过DNS协议限制。该UDP限制在[RFC1035]第2.3.4节中定义，尽管[RFC2671]提出了该限制。保持在512个八位字节以下应该可以防止旧的DNS实现故障转移到TCP，并且在没有EDNS0[RFC6891]支持的情况下可以使用UDP。由于答案大小取决于本文档范围之外的许多内容，因此只能给出以下指导原则：如果DNS消息的大小、DNS名称和给定类型的所有记录的文本的组合长度小于450个八位字节，则DNS答案应该适合UDP包。由于防火墙和其他干扰通过TCP或使用ENDS0的DNS操作的问题，SPF验证器可能会悄悄忽略太长而无法放入单个UDP数据包的记录。
Note that when computing the sizes for replies to queries of the TXT format, one has to take into account any other TXT records published at the domain name. Similarly, the sizes for replies to all queries related to SPF have to be evaluated to fit in a single 512-octet UDP packet (i.e., DNS message size limited to 450 octets).
请注意，在计算TXT格式查询的回复大小时，必须考虑在域名上发布的任何其他TXT记录。类似地，必须评估与SPF相关的所有查询的回复大小，以适合单个512个八位字节的UDP数据包（即，DNS消息大小限制为450个八位字节）。
Use of wildcard records for publishing is discouraged, and care has to be taken if they are used. If a zone includes wildcard MX records, it might want to publish wildcard declarations, subject to the same requirements and problems. In particular, the declaration MUST be repeated for any host that has any RR records at all, and for subdomains thereof. Consider the example in [RFC1034], Section 4.3.3. Based on that, we can do the following:
不鼓励使用通配符记录进行发布，如果使用通配符记录，必须小心。如果一个区域包含通配符MX记录，它可能希望根据相同的要求和问题发布通配符声明。特别是，必须对具有任何RR记录的任何主机及其子域重复该声明。考虑一下[RCF1034 ]，4.4.3节中的例子。基于此，我们可以做以下工作：
EXAMPLE.COM. MX 10 A.EXAMPLE.COM EXAMPLE.COM. TXT "v=spf1 a:A.EXAMPLE.COM -all"
EXAMPLE.COM。MX 10 A.EXAMPLE.COM EXAMPLE.COM。TXT“v=spf1 a:a.EXAMPLE.COM-全部”
*.EXAMPLE.COM. MX 10 A.EXAMPLE.COM
*.EXAMPLE.COM. TXT "v=spf1 a:A.EXAMPLE.COM -all"
*.EXAMPLE.COM. MX 10 A.EXAMPLE.COM
*.EXAMPLE.COM. TXT "v=spf1 a:A.EXAMPLE.COM -all"
A.EXAMPLE.COM. A 203.0.113.1 A.EXAMPLE.COM. MX 10 A.EXAMPLE.COM A.EXAMPLE.COM. TXT "v=spf1 a:A.EXAMPLE.COM -all"
A.EXAMPLE.COM。A 203.0.113.1 A.EXAMPLE.COM。MX 10 A.EXAMPLE.COM A.EXAMPLE.COM。TXT“v=spf1 a:a.EXAMPLE.COM-全部”
*.A.EXAMPLE.COM. MX 10 A.EXAMPLE.COM
*.A.EXAMPLE.COM. TXT "v=spf1 a:A.EXAMPLE.COM -all"
*.A.EXAMPLE.COM. MX 10 A.EXAMPLE.COM
*.A.EXAMPLE.COM. TXT "v=spf1 a:A.EXAMPLE.COM -all"
SPF records have to be listed twice for every name within the zone: once for the name, and once with a wildcard to cover the tree under the name, in order to cover all domains in use in outgoing mail.
对于区域内的每个名称，SPF记录必须列出两次：一次用于名称，一次使用通配符覆盖名称下的树，以覆盖传出邮件中使用的所有域。
This description is not an application programming interface definition, but rather a function description used to illustrate the algorithm. A compliant SPF implementation MUST produce results semantically equivalent to this description.
此描述不是应用程序编程接口定义，而是用于说明算法的函数描述。兼容的SPF实现必须产生语义上与此描述等效的结果。
The check_host() function fetches SPF records, parses them, and evaluates them to determine whether a particular host is or is not permitted to send mail with a given identity. Receiving ADMDs that perform this check MUST correctly evaluate the check_host() function as described here.
函数的作用是：获取SPF记录，对其进行解析，并对其进行求值，以确定是否允许特定主机发送具有给定标识的邮件。接收执行此检查的ADMD时，必须正确计算check_host（）函数，如下所述。
Implementations MAY use a different algorithm than the canonical algorithm defined here, so long as the results are the same in all cases.
实现可能使用与此处定义的规范算法不同的算法，只要结果在所有情况下都相同。
The check_host() function takes these arguments:
check_host（）函数接受以下参数：
<ip> - the IP address of the SMTP client that is emitting the mail, either IPv4 or IPv6.
<ip>-发送邮件的SMTP客户端的ip地址，IPv4或IPv6。
<domain> - the domain that provides the sought-after authorization information; initially, the domain portion of the "MAIL FROM" or "HELO" identity.
<domain>-提供所需授权信息的域；最初，“邮件发件人”或“HELO”标识的域部分。
<sender> - the "MAIL FROM" or "HELO" identity.
<sender>“邮件发件人”或“HELO”标识。
For recursive evaluations, the domain portion of <sender> might not be the same as the <domain> argument when check_host() is initially evaluated. In most other cases it will be the same (see Section 5.2 below). The overall DNS lookup limit for SPF terms described below in Section 4.6.4 must be tracked as a single global limit for all evaluations, not just for a single instance of a recursive evaluation.
对于递归计算，<sender>的域部分可能与最初计算check_host（）时的<domain>参数不同。在大多数其他情况下，情况相同（见下文第5.2节）。第4.6.4节中描述的SPF术语的总体DNS查找限制必须作为所有评估的单个全局限制进行跟踪，而不仅仅是递归评估的单个实例。
Note that the <domain> argument might not be a well-formed domain name. For example, if the reverse-path was null, then the EHLO/HELO domain is used, with its associated problems (see Section 2.3). In these cases, check_host() is defined in Section 4.3 to return a "none" result.
请注意，<domain>参数可能不是格式正确的域名。例如，如果反向路径为null，则使用EHLO/HELO域及其相关问题（参见第2.3节）。在这些情况下，第4.3节中定义了check_host（）以返回“none”结果。
The check_host() function can return one of several results described in Section 2.6. Based on the result, the action to be taken is determined by the local policies of the receiver. This is discussed in Section 8.
check_host（）函数可以返回第2.6节中描述的几个结果之一。根据结果，要采取的行动由接收方的本地策略决定。第8节对此进行了讨论。
If the <domain> is malformed (e.g., label longer than 63 characters, zero-length label not at the end, etc.) or is not a multi-label domain name, or if the DNS lookup returns "Name Error" (RCODE 3, also known as "NXDOMAIN" [RFC2308]), check_host() immediately returns the result "none". DNS RCODEs are defined in [RFC1035]. Properly formed domains are fully qualified domains as defined in [RFC1983]. That is, in the DNS they are implicitly qualified relative to the root (see Section 3.1 of [RFC1034]). Internationalized domain names MUST be encoded as A-labels, as described in Section 2.3 of [RFC5890].
如果<domain>格式不正确（例如，标签长度超过63个字符，零长度标签不在末尾等），或者不是多标签域名，或者如果DNS查找返回“名称错误”（RCODE 3，也称为“NXDOMAIN”[RFC2308]），则check_host（）立即返回结果“无”。DNS代码在[RFC1035]中定义。正确形成的域是[RFC1983]中定义的完全限定域。也就是说，在DNS中，它们相对于根进行隐式限定（参见[RFC1034]第3.1节）。如[RFC5890]第2.3节所述，国际化域名必须编码为A标签。
If the <sender> has no local-part, substitute the string "postmaster" for the local-part.
如果<sender>没有本地部分，则用字符串“postmaster”替换本地部分。
In accordance with how the records are published (see Section 3 above), a DNS query needs to be made for the <domain> name, querying for type TXT only.
根据记录的发布方式（见上文第3节），需要对<domain>名称进行DNS查询，仅查询TXT类型。
If the DNS lookup returns a server failure (RCODE 2) or some other error (RCODE other than 0 or 3), or if the lookup times out, then check_host() terminates immediately with the result "temperror".
如果DNS查找返回服务器故障（RCODE 2）或其他错误（RCODE不是0或3），或者如果查找超时，则check_host（）立即终止，结果为“temperror”。
Records begin with a version section:
记录以版本部分开始：
record = version terms *SP
version = "v=spf1"
record = version terms *SP
version = "v=spf1"
Starting with the set of records that were returned by the lookup, discard records that do not begin with a version section of exactly "v=spf1". Note that the version section is terminated by either an SP character or the end of the record. As an example, a record with a version section of "v=spf10" does not match and is discarded.
从查找返回的记录集开始，放弃不以“v=spf1”版本节开头的记录。请注意，版本部分以SP字符或记录结尾终止。例如，版本部分为“v=spf10”的记录不匹配，将被丢弃。
If the resultant record set includes no records, check_host() produces the "none" result. If the resultant record set includes more than one record, check_host() produces the "permerror" result.
如果结果记录集不包含任何记录，则check_host（）将生成“none”结果。如果结果记录集包含多个记录，则check_host（）将生成“permerror”结果。
The check_host() function parses and interprets the SPF record to find a result for the current test. The syntax of the record is validated first, and if there are any syntax errors anywhere in the record, check_host() returns immediately with the result "permerror", without further interpretation or evaluation.
函数的作用是：解析并解释SPF记录，以查找当前测试的结果。首先验证记录的语法，如果记录中的任何地方有语法错误，则check_host（）立即返回结果“permerror”，无需进一步解释或计算。
There are two types of terms: mechanisms (defined in Section 5) and modifiers (defined in Section 6). A record contains an ordered list of these as specified in the following Augmented Backus-Naur Form (ABNF).
有两种类型的术语：机制（定义见第5节）和修饰语（定义见第6节）。一个记录包含一个有序的列表，这些列表在下面的扩展的Backus Naur表单（ABNF）中指定。
terms = *( 1*SP ( directive / modifier ) )
terms = *( 1*SP ( directive / modifier ) )
directive = [ qualifier ] mechanism
qualifier = "+" / "-" / "?" / "~"
mechanism = ( all / include
/ a / mx / ptr / ip4 / ip6 / exists )
modifier = redirect / explanation / unknown-modifier
unknown-modifier = name "=" macro-string
; where name is not any known modifier
directive = [ qualifier ] mechanism
qualifier = "+" / "-" / "?" / "~"
mechanism = ( all / include
/ a / mx / ptr / ip4 / ip6 / exists )
modifier = redirect / explanation / unknown-modifier
unknown-modifier = name "=" macro-string
; where name is not any known modifier
name = ALPHA *( ALPHA / DIGIT / "-" / "_" / "." )
name = ALPHA *( ALPHA / DIGIT / "-" / "_" / "." )
Most mechanisms allow a ":" or "/" character after the name.
大多数机制允许在名称后使用“：”或“/”字符。
Modifiers always contain an equals ('=') character immediately after the name, and before any ":" or "/" characters that might be part of the macro-string.
修饰符总是在名称后面紧跟着一个等于（'='）字符，在可能是宏字符串一部分的任何“：”或“/”字符之前。
Terms that do not contain any of "=", ":", or "/" are mechanisms, as defined in Section 5.
不包含任何“=”、“：”或“/”的术语是第5节中定义的机制。
As per the definition of the ABNF notation in [RFC5234], mechanism and modifier names are case-insensitive.
根据[RFC5234]中ABNF符号的定义，机制和修饰符名称不区分大小写。
Each mechanism is considered in turn from left to right. If there are no more mechanisms, the result is the default result as described in Section 4.7.
从左到右依次考虑每个机构。如果没有其他机制，则结果为第4.7节所述的默认结果。
When a mechanism is evaluated, one of three things can happen: it can match, not match, or return an exception.
评估机制时，可能会发生以下三种情况之一：匹配、不匹配或返回异常。
If it matches, processing ends and the qualifier value is returned as the result of that record. If it does not match, processing continues with the next mechanism. If it returns an exception, mechanism processing ends and the exception value is returned.
如果匹配，则处理结束，并返回限定符值作为该记录的结果。如果不匹配，处理将继续下一个机制。如果返回异常，则机制处理结束并返回异常值。
The possible qualifiers, and the results they cause check_host() to return, are as follows:
可能的限定符及其导致check_host（）返回的结果如下：
"+" pass "-" fail "~" softfail "?" neutral
“+”通过“-”失败“~”软失败“？”中性
The qualifier is optional and defaults to "+".
限定符是可选的，默认为“+”。
When a mechanism matches and the qualifier is "-", then a "fail" result is returned and the explanation string is computed as described in Section 6.2.
当机制匹配且限定符为“-”时，将返回“失败”结果，并按照第6.2节中的说明计算解释字符串。
The specific mechanisms are described in Section 5.
具体机制见第5节。
Modifiers are not mechanisms. They do not return match or not-match. Instead, they provide additional information. Although modifiers do not directly affect the evaluation of the record, the "redirect" modifier has an effect after all the mechanisms have been evaluated.
修饰语不是机制。他们不返回匹配或不匹配。相反，它们提供了额外的信息。虽然修饰符不会直接影响记录的求值，但“重定向”修饰符在所有机制求值后都会起作用。
Some mechanisms and modifiers (collectively, "terms") cause DNS queries at the time of evaluation, and some do not. The following terms cause DNS queries: the "include", "a", "mx", "ptr", and "exists" mechanisms, and the "redirect" modifier. SPF implementations MUST limit the total number of those terms to 10 during SPF evaluation, to avoid unreasonable load on the DNS. If this limit is exceeded, the implementation MUST return "permerror". The other terms -- the "all", "ip4", and "ip6" mechanisms, and the "exp" modifier -- do not cause DNS queries at the time of SPF evaluation (the "exp" modifier only causes a lookup at a later time), and their use is not subject to this limit.
某些机制和修饰符（统称为“术语”）在评估时会导致DNS查询，而有些则不会。以下术语导致DNS查询：“包括”、“a”、“mx”、“ptr”和“存在”机制，以及“重定向”修饰符。在SPF评估期间，SPF实现必须将这些术语的总数限制为10个，以避免DNS上的不合理负载。如果超过此限制，则实现必须返回“permerror”。其他术语——“all”、“ip4”和“ip6”机制以及“exp”修饰符在SPF评估时不会引起DNS查询（“exp”修饰符只会在以后引起查找），它们的使用不受此限制。
When evaluating the "mx" mechanism, the number of "MX" resource records queried is included in the overall limit of 10 mechanisms/ modifiers that cause DNS lookups as described above. In addition to that limit, the evaluation of each "MX" record MUST NOT result in
在评估“mx”机制时，查询的“mx”资源记录的数量包含在导致如上所述DNS查找的10个机制/修改器的总限制中。除此限制外，对每个“MX”记录的评估不得导致
querying more than 10 address records -- either "A" or "AAAA" resource records. If this limit is exceeded, the "mx" mechanism MUST produce a "permerror" result.
查询10个以上的地址记录——“A”或“AAAA”资源记录。如果超过此限制，“mx”机制必须产生“permerror”结果。
When evaluating the "ptr" mechanism or the %{p} macro, the number of "PTR" resource records queried is included in the overall limit of 10 mechanisms/modifiers that cause DNS lookups as described above. In addition to that limit, the evaluation of each "PTR" record MUST NOT result in querying more than 10 address records -- either "A" or "AAAA" resource records. If this limit is exceeded, all records other than the first 10 MUST be ignored.
在评估“ptr”机制或%{p}宏时，查询的“ptr”资源记录的数量包含在导致如上所述DNS查找的10个机制/修饰符的总限制中。除此之外，对每个“PTR”记录的求值不得导致查询超过10个地址记录——“A”或“AAAA”资源记录。如果超过此限制，则必须忽略前10条以外的所有记录。
The reason for the disparity is that the set of and contents of the MX record are under control of the publishing ADMD, while the set of and contents of PTR records are under control of the owner of the IP address actually making the connection.
造成差异的原因是MX记录的集合和内容由发布ADMD控制，而PTR记录的集合和内容由实际进行连接的IP地址的所有者控制。
These limits are per mechanism or macro in the record, and are in addition to the lookup limits specified above.
这些限制是记录中每个机制或宏的限制，并且是上述查找限制之外的限制。
MTAs or other processors SHOULD impose a limit on the maximum amount of elapsed time to evaluate check_host(). Such a limit SHOULD allow at least 20 seconds. If such a limit is exceeded, the result of authorization SHOULD be "temperror".
MTA或其他处理器应限制评估check_host（）所用的最长时间。该限制应至少允许20秒。如果超过此限制，则授权结果应为“temperror”。
As described at the end of Section 11.1, there may be cases where it is useful to limit the number of "terms" for which DNS queries return either a positive answer (RCODE 0) with an answer count of 0, or a "Name Error" (RCODE 3) answer. These are sometimes collectively referred to as "void lookups". SPF implementations SHOULD limit "void lookups" to two. An implementation MAY choose to make such a limit configurable. In this case, a default of two is RECOMMENDED. Exceeding the limit produces a "permerror" result.
如第11.1节末尾所述，在某些情况下，限制DNS查询返回答案计数为0的肯定答案（RCODE 0）或“名称错误”（RCODE 3）答案的“术语”数量是有用的。这些有时统称为“无效查找”。SPF实现应将“无效查找”限制为两个。实现可以选择使这样的限制可配置。在这种情况下，建议默认值为2。超过该限制将产生“permerror”结果。
If none of the mechanisms match and there is no "redirect" modifier, then the check_host() returns a result of "neutral", just as if "?all" were specified as the last directive. If there is a "redirect" modifier, check_host() proceeds as defined in Section 6.1.
如果没有匹配的机制，并且没有“重定向”修饰符，那么check_host（）将返回一个“neutral”结果，就像将“？all”指定为最后一个指令一样。如果有“重定向”修饰符，请检查_host（）是否按照第6.1节中的定义进行。
It is better to use either a "redirect" modifier or an "all" mechanism to explicitly terminate processing. Although there is an implicit "?all" at the end of every record that is not explicitly terminated, it aids debugging efforts when it is explicitly provided.
最好使用“重定向”修饰符或“全部”机制来显式终止处理。虽然在每个未显式终止的记录的末尾都有一个隐式的“？all”，但当显式提供它时，它有助于调试工作。
For example:
例如：
v=spf1 +mx -all
v=spf1 +mx -all
or
或
v=spf1 +mx redirect=_spf.example.com
v=spf1 +mx redirect=_spf.example.com
Several of these mechanisms and modifiers have a <domain-spec> section. The <domain-spec> string is subject to macro expansion (see Section 7). The resulting string is the common presentation form of a fully qualified DNS name: a series of labels separated by periods. This domain is called the <target-name> in the rest of this document.
其中一些机制和修饰符具有<domain spec>部分。<domain spec>字符串需要进行宏扩展（参见第7节）。结果字符串是完全限定DNS名称的常见表示形式：由句点分隔的一系列标签。在本文档的其余部分中，此域称为<target name>。
Note: The result of the macro expansion is not subject to any further escaping. Hence, this facility cannot produce all characters that are legal in a DNS label (e.g., the control characters). However, this facility is powerful enough to express legal host names and common utility labels (such as "_spf") that are used in DNS.
注意：宏扩展的结果不受任何进一步转义的影响。因此，此功能无法生成DNS标签中的所有合法字符（例如，控制字符）。但是，此功能强大到足以表示DNS中使用的合法主机名和通用实用程序标签（如“_spf”）。
For several mechanisms, the <domain-spec> is optional. If it is not provided, the <domain> from the check_host() arguments (see Section 4.1) is used as the <target-name>. "domain" and <domain-spec> are syntactically identical after macro expansion. "domain" is an input value for check_host(), while <domain-spec> is computed by check_host().
对于几种机制，<domain spec>是可选的。如果未提供，则使用check_host（）参数（参见第4.1节）中的<domain>作为<target name>。宏扩展后，“域”和<domain spec>在语法上相同。“域”是check_host（）的输入值，而<domain spec>由check_host（）计算。
The result of evaluating check_host() with a syntactically invalid domain is undefined.
使用语法无效的域计算check_host（）的结果未定义。
Note: This document and its predecessors make no provisions for defining correct handling of a syntactically invalid <domain-spec> (which might be the result of macro expansion), per [RFC1035]. Examples include names with empty labels, such as "foo..example.com", and labels that are longer than 63 characters. Some implementations choose to treat such errors as not-match and therefore ignore such names, while others return a "permerror" exception.
注：根据[RFC1035]，本文档及其前身没有规定如何定义语法无效的<domain spec>（可能是宏扩展的结果）的正确处理。示例包括带有空标签的名称，如“foo..example.com”，以及长度超过63个字符的标签。一些实现选择将此类错误视为不匹配，因此忽略此类名称，而其他实现则返回“permerro”异常。
This section defines two types of mechanisms: basic language framework mechanisms and designated sender mechanisms.
本节定义了两种类型的机制：基本语言框架机制和指定发送方机制。
Basic mechanisms contribute to the language framework. They do not specify a particular type of authorization scheme. The basic mechanisms are as follows:
基本机制有助于语言框架。它们没有指定特定类型的授权方案。基本机制如下：
all include
全部包括
Designated sender mechanisms are used to identify a set of <ip> addresses as being permitted or not permitted to use the <domain> for sending mail. The designated sender mechanisms are as follows:
指定的发件人机制用于标识一组<ip>地址是否允许使用<domain>发送邮件。指定的发送方机制如下所示：
a mx ptr (do not use) ip4 ip6 exists
存在mx ptr（不使用）ip4 ip6
The following conventions apply to all mechanisms that perform a comparison between <ip> and an IP address at any point:
以下约定适用于在任何点执行<ip>和ip地址之间比较的所有机制：
If no CIDR prefix length is given in the directive, then <ip> and the IP address are compared for equality. (Here, CIDR is Classless Inter-Domain Routing, described in [RFC4632].)
如果指令中未给出CIDR前缀长度，则比较<ip>和ip地址是否相等。（这里，CIDR是无类域间路由，如[RFC4632]所述。）
If a CIDR prefix length is specified, then only the specified number of high-order bits of <ip> and the IP address are compared for equality.
如果指定了CIDR前缀长度，则仅比较指定数量的<ip>高阶位和ip地址是否相等。
When any mechanism fetches host addresses to compare with <ip>, when <ip> is an IPv4, "A" records are fetched; when <ip> is an IPv6 address, "AAAA" records are fetched. SPF implementations on IPv6 servers need to handle both "AAAA" and "A" records, for clients on IPv4-mapped IPv6 addresses [RFC4291]. IPv4 <ip> addresses are only listed in an SPF record using the "ip4" mechanism.
当任何机制获取主机地址以与<ip>进行比较时，当<ip>是IPv4时，将获取“A”记录；当<ip>是IPv6地址时，将获取“AAAA”记录。IPv6服务器上的SPF实现需要处理IPv4映射IPv6地址上的客户端的“AAAA”和“A”记录[RFC4291]。IPv4<ip>地址仅使用“ip4”机制列在SPF记录中。
Several mechanisms rely on information fetched from the DNS. For these DNS queries, except where noted, if the DNS server returns an error (RCODE other than 0 or 3) or the query times out, the mechanism stops and the topmost check_host() returns "temperror". If the server returns "Name Error" (RCODE 3), then evaluation of the mechanism continues as if the server returned no error (RCODE 0) and zero answer records.
有几种机制依赖于从DNS获取的信息。对于这些DNS查询，除非另有说明，否则如果DNS服务器返回错误（RCODE不是0或3）或查询超时，则机制将停止，最顶端的check_host（）将返回“temperror”。如果服务器返回“名称错误”（RCODE 3），则继续评估该机制，就像服务器未返回任何错误（RCODE 0）和零应答记录一样。
all = "all"
all = "all"
The "all" mechanism is a test that always matches. It is used as the rightmost mechanism in a record to provide an explicit default.
“全部”机制是一个始终匹配的测试。它用作记录中最右边的机制，以提供显式默认值。
For example:
例如：
v=spf1 a mx -all
v=spf1 a mx-全部
Mechanisms after "all" will never be tested. Mechanisms listed after "all" MUST be ignored. Any "redirect" modifier (Section 6.1) MUST be ignored when there is an "all" mechanism in the record, regardless of the relative ordering of the terms.
“所有”之后的机制永远不会被测试。必须忽略“所有”后面列出的机制。当记录中存在“全部”机制时，无论术语的相对顺序如何，必须忽略任何“重定向”修饰符（第6.1节）。
include = "include" ":" domain-spec
include=“include”“：”域规范
The "include" mechanism triggers a recursive evaluation of check_host().
“include”机制触发check_host（）的递归计算。
1. The <domain-spec> is expanded as per Section 7.
1. <domain spec>根据第7节进行扩展。
2. check_host() is evaluated with the resulting string as the <domain>. The <ip> and <sender> arguments remain the same as in the current evaluation of check_host().
2. check_host（）的计算结果为<domain>。<ip>和<sender>参数与check_host（）当前计算中的参数保持相同。
3. The recursive evaluation returns match, not-match, or an error.
3. 递归计算返回匹配、不匹配或错误。
4. If it returns match, then the appropriate result for the "include" mechanism is used (e.g., include or +include produces a "pass" result and -include produces "fail").
4. 如果返回match，则使用“include”机制的适当结果（例如，include或+include生成“通过”结果，-include生成“失败”）。
5. If it returns not-match or an error, the parent check_host() resumes processing as per the table below, with the previous value of <domain> restored.
5. 如果返回not match（不匹配）或错误，则父check_host（）将按照下表恢复处理，并恢复以前的值<domain>。
In hindsight, the name "include" was poorly chosen. Only the evaluated result of the referenced SPF record is used, rather than literally including the mechanisms of the referenced record in the first. For example, evaluating a "-all" directive in the referenced record does not terminate the overall processing and does not necessarily result in an overall "fail". (Better names for this mechanism would have been "if-match", "on-match", etc.)
事后看来，“包括”这个名字选得不好。仅使用引用SPF记录的评估结果，而不是在第一个记录中包含引用记录的机制。例如，评估引用记录中的“-all”指令不会终止整体处理，也不一定会导致整体“失败”。（这种机制的更好名称应该是“如果匹配”、“匹配时”等）
The "include" mechanism makes it possible for one domain to designate multiple administratively independent domains. For example, a vanity domain "example.net" might send mail using the servers of administratively independent domains example.com and example.org.
“包含”机制使一个域可以指定多个管理上独立的域。例如，虚荣域“example.net”可能使用管理独立域example.com和example.org的服务器发送邮件。
Example.net could say
net可以这样说
IN TXT "v=spf1 include:example.com include:example.org -all"
IN TXT "v=spf1 include:example.com include:example.org -all"
This would direct check_host() to, in effect, check the records of example.com and example.org for a "pass" result. Only if the host were not permitted for either of those domains would the result be "fail".
这将指示check_host（）实际上检查example.com和example.org的记录以获得“通过”结果。只有当这些域中的任何一个都不允许主机时，结果才会是“失败”。
Whether this mechanism matches, does not match, or returns an exception depends on the result of the recursive evaluation of check_host():
此机制是否匹配、不匹配或返回异常取决于check_host（）的递归计算结果：
+---------------------------------+---------------------------------+
| A recursive check_host() result | Causes the "include" mechanism |
| of: | to: |
+---------------------------------+---------------------------------+
| pass | match |
| | |
| fail | not match |
| | |
| softfail | not match |
| | |
| neutral | not match |
| | |
| temperror | return temperror |
| | |
| permerror | return permerror |
| | |
| none | return permerror |
+---------------------------------+---------------------------------+
+---------------------------------+---------------------------------+
| A recursive check_host() result | Causes the "include" mechanism |
| of: | to: |
+---------------------------------+---------------------------------+
| pass | match |
| | |
| fail | not match |
| | |
| softfail | not match |
| | |
| neutral | not match |
| | |
| temperror | return temperror |
| | |
| permerror | return permerror |
| | |
| none | return permerror |
+---------------------------------+---------------------------------+
The "include" mechanism is intended for crossing administrative boundaries. When remaining within one administrative authority, "include" is usually not the best choice. For example, if example.com and example.org were managed by the same entity, and if the permitted set of hosts for both domains was "mx:example.com", it would be possible for example.org to specify "include:example.com", but it would be preferable to specify "redirect=example.com" or even "mx:example.com".
“包括”机制旨在跨越行政界限。在一个管理权限内，“包括”通常不是最佳选择。例如，如果example.com和example.org由同一实体管理，并且如果两个域允许的主机集是“mx:example.com”，example.org可以指定“include:example.com”，但最好指定“redirect=example.com”甚至“mx:example.com”。
With the "include" mechanism, an administratively external set of hosts can be authorized, but determination of sender policy is still a function of the original domain's SPF record (as determined by the "all" mechanism in that record). The "redirect" modifier is more suitable for consolidating both authorizations and policy into a common set to be shared within an ADMD. Redirect is much more like a common code element to be shared among records in a single ADMD. It is possible to control both authorized hosts and policy for an arbitrary number of domains from a single record.
使用“include”机制，可以授权管理外部主机集，但发送方策略的确定仍然是原始域的SPF记录的功能（由该记录中的“all”机制确定）。“重定向”修饰符更适合将授权和策略合并到要在ADMD中共享的公共集合中。重定向更像是在单个ADMD中的记录之间共享的公共代码元素。可以从单个记录控制任意数量域的授权主机和策略。
This mechanism matches if <ip> is one of the <target-name>'s IP addresses. For clarity, this means the "a" mechanism also matches AAAA records.
如果<ip>是<target name>的ip地址之一，则此机制匹配。为清楚起见，这意味着“a”机制也匹配AAAA记录。
a = "a" [ ":" domain-spec ] [ dual-cidr-length ]
a=“a”[“：”域规范][双cidr长度]
An address lookup is done on the <target-name> using the type of lookup (A or AAAA) appropriate for the connection type (IPv4 or IPv6). The <ip> is compared to the returned address(es). If any address matches, the mechanism matches.
使用适合于连接类型（IPv4或IPv6）的查找类型（A或AAAA），在<target name>上执行地址查找。将<ip>与返回的地址进行比较。如果任何地址匹配，则机制匹配。
This mechanism matches if <ip> is one of the MX hosts for a domain name.
如果<ip>是域名的MX主机之一，则此机制匹配。
mx = "mx" [ ":" domain-spec ] [ dual-cidr-length ]
mx=“mx”[”：“域规范][双cidr长度]
check_host() first performs an MX lookup on the <target-name>. Then it performs an address lookup on each MX name returned. The <ip> is compared to each returned IP address. To prevent denial-of-service (DoS) attacks, the processing limits defined in Section 4.6.4 MUST be followed. If the MX lookup limit is exceeded, then "permerror" is returned and the evaluation is terminated. If any address matches, the mechanism matches.
check_host（）首先对<target name>执行MX查找。然后，它对返回的每个MX名称执行地址查找。将<ip>与每个返回的ip地址进行比较。为防止拒绝服务（DoS）攻击，必须遵守第4.6.4节中定义的处理限制。如果超出MX查找限制，则返回“permerror”并终止计算。如果任何地址匹配，则机制匹配。
Note regarding implicit MXes: If the <target-name> has no MX record, check_host() MUST NOT apply the implicit MX rules of [RFC5321] by querying for an A or AAAA record for the same name.
关于隐式MXE的注意事项：如果<target name>没有MX记录，则check_host（）不得通过查询相同名称的A或AAAA记录来应用[RFC5321]的隐式MX规则。
This mechanism tests whether the DNS reverse-mapping for <ip> exists and correctly points to a domain name within a particular domain. This mechanism SHOULD NOT be published. See the note at the end of this section for more information.
此机制测试<ip>的DNS反向映射是否存在并正确指向特定域中的域名。这一机制不应公布。有关更多信息，请参阅本节末尾的注释。
ptr = "ptr" [ ":" domain-spec ]
ptr=“ptr”[“：”域规范]
The <ip>'s name is looked up using this procedure:
使用以下步骤查找<ip>的名称：
o Perform a DNS reverse-mapping for <ip>: Look up the corresponding PTR record in "in-addr.arpa." if the address is an IPv4 address and in "ip6.arpa." if it is an IPv6 address.
o 执行<ip>的DNS反向映射：如果地址是IPv4地址，请在“in addr.arpa.”中查找相应的PTR记录；如果地址是IPv6地址，请在“ip6.arpa.”中查找相应的PTR记录。
o For each record returned, validate the domain name by looking up its IP addresses. To prevent DoS attacks, the PTR processing limits defined in Section 4.6.4 MUST be applied. If they are exceeded, processing is terminated and the mechanism does not match.
o 对于返回的每个记录，通过查找其IP地址来验证域名。为防止DoS攻击，必须应用第4.6.4节中定义的PTR处理限制。如果超过这些值，则终止处理，机制不匹配。
o If <ip> is among the returned IP addresses, then that domain name is validated.
o 如果<ip>在返回的ip地址中，则验证该域名。
Check all validated domain names to see if they either match the <target-name> domain or are a subdomain of the <target-name> domain. If any do, this mechanism matches. If no validated domain name can be found, or if none of the validated domain names match or are a subdomain of the <target-name>, this mechanism fails to match. If a DNS error occurs while doing the PTR RR lookup, then this mechanism fails to match. If a DNS error occurs while doing an A RR lookup, then that domain name is skipped and the search continues.
检查所有已验证的域名，查看它们是否与<target name>域匹配，或者是<target name>域的子域。如果有，则此机制匹配。若找不到已验证的域名，或者若所有已验证的域名都不匹配，或者都不是<target name>的子域，则此机制将无法匹配。如果在执行PTR RR查找时发生DNS错误，则此机制无法匹配。如果在执行RR查找时发生DNS错误，则跳过该域名并继续搜索。
This mechanism matches if
此机制与以下情况匹配：
o the <target-name> is a subdomain of a validated domain name, or
o <target name>是已验证域名的子域，或
o the <target-name> and a validated domain name are the same.
o <target name>和已验证的域名是相同的。
For example, "mail.example.com" is within the domain "example.com", but "mail.bad-example.com" is not.
例如，“mail.example.com”在域“example.com”内，但“mail.bad example.com”不在域“example.com”内。
Note: This mechanism is slow, it is not as reliable as other mechanisms in cases of DNS errors, and it places a large burden on the .arpa name servers. If used, proper PTR records have to be in place for the domain's hosts and the "ptr" mechanism SHOULD be one of the last mechanisms checked. After many years of SPF deployment experience, it has been concluded that it is unnecessary and more reliable alternatives should be used instead. It is, however, still in use as part of the SPF protocol, so compliant check_host() implementations MUST support it.
注意：此机制速度较慢，在DNS错误的情况下，它不如其他机制可靠，并且会给.arpa名称服务器带来很大负担。如果使用，必须为域的主机准备适当的PTR记录，“PTR”机制应该是最后检查的机制之一。经过多年的SPF部署经验，我们得出结论认为，这是不必要的，应该使用更可靠的替代方案。但是，它仍然作为SPF协议的一部分使用，因此兼容的check_host（）实现必须支持它。
These mechanisms test whether <ip> is contained within a given IP network.
这些机制测试<ip>是否包含在给定的ip网络中。
ip4 = "ip4" ":" ip4-network [ ip4-cidr-length ]
ip6 = "ip6" ":" ip6-network [ ip6-cidr-length ]
ip4 = "ip4" ":" ip4-network [ ip4-cidr-length ]
ip6 = "ip6" ":" ip6-network [ ip6-cidr-length ]
ip4-cidr-length = "/" ("0" / %x31-39 0*1DIGIT) ; value range 0-32
ip6-cidr-length = "/" ("0" / %x31-39 0*2DIGIT) ; value range 0-128
dual-cidr-length = [ ip4-cidr-length ] [ "/" ip6-cidr-length ]
ip4-cidr-length = "/" ("0" / %x31-39 0*1DIGIT) ; value range 0-32
ip6-cidr-length = "/" ("0" / %x31-39 0*2DIGIT) ; value range 0-128
dual-cidr-length = [ ip4-cidr-length ] [ "/" ip6-cidr-length ]
ip4-network = qnum "." qnum "." qnum "." qnum
qnum = DIGIT ; 0-9
/ %x31-39 DIGIT ; 10-99
/ "1" 2DIGIT ; 100-199
/ "2" %x30-34 DIGIT ; 200-249
/ "25" %x30-35 ; 250-255
; as per conventional dotted-quad notation, e.g., 192.0.2.0
ip4-network = qnum "." qnum "." qnum "." qnum
qnum = DIGIT ; 0-9
/ %x31-39 DIGIT ; 10-99
/ "1" 2DIGIT ; 100-199
/ "2" %x30-34 DIGIT ; 200-249
/ "25" %x30-35 ; 250-255
; as per conventional dotted-quad notation, e.g., 192.0.2.0
ip6-network = <as per Section 2.2 of [RFC4291]>
; e.g., 2001:db8::cd30
ip6-network = <as per Section 2.2 of [RFC4291]>
; e.g., 2001:db8::cd30
The <ip> is compared to the given network. If CIDR prefix length high-order bits match, the mechanism matches.
将<ip>与给定网络进行比较。如果CIDR前缀长度高阶位匹配，则机制匹配。
If ip4-cidr-length is omitted, it is taken to be "/32". If ip6-cidr-length is omitted, it is taken to be "/128". It is not permitted to omit parts of the IP address instead of using CIDR notations. That is, use 192.0.2.0/24 instead of 192.0.2.
如果省略ip4 cidr长度，则取“/32”。如果省略ip6 cidr长度，则取“/128”。不允许省略部分IP地址而不是使用CIDR符号。也就是说，使用192.0.2.0/24而不是192.0.2。
This mechanism is used to construct an arbitrary domain name that is used for a DNS A record query. It allows for complicated schemes involving arbitrary parts of the mail envelope to determine what is permitted.
此机制用于构造用于DNS a记录查询的任意域名。它允许涉及邮件信封任意部分的复杂方案来确定允许的内容。
exists = "exists" ":" domain-spec
exists=“exists”“：”域规范
The <domain-spec> is expanded as per Section 7. The resulting domain name is used for a DNS A RR lookup (even when the connection type is IPv6). If any A record is returned, this mechanism matches.
<domain spec>根据第7节进行扩展。生成的域名用于DNS a RR查找（即使连接类型为IPv6）。如果返回任何A记录，则此机制匹配。
Domains can use this mechanism to specify arbitrarily complex queries. For example, suppose example.com publishes the record:
域可以使用此机制指定任意复杂的查询。例如，假设example.com发布记录：
v=spf1 exists:%{ir}.%{l1r+-}._spf.%{d} -all
v=spf1 exists:%{ir}.%{l1r+-}._spf.%{d} -all
The <target-name> might expand to "1.2.0.192.someuser._spf.example.com". This makes fine-grained decisions possible at the level of the user and client IP address.
<target name>可能会扩展到“1.2.0.192.someuser.\u spf.example.com”。这使得在用户和客户端IP地址级别进行细粒度决策成为可能。
Modifiers are name/value pairs that provide additional information. Modifiers always have an "=" separating the name and the value.
修饰符是提供附加信息的名称/值对。修饰符始终有一个“=”分隔名称和值。
The modifiers defined in this document ("redirect" and "exp") SHOULD appear at the end of the record, after all mechanisms, though syntactically they can appear anywhere in the record. Ordering of these two modifiers does not matter. These two modifiers MUST NOT appear in a record more than once each. If they do, then check_host() exits with a result of "permerror".
本文档中定义的修饰符（“redirect”和“exp”）应该出现在记录的末尾，尽管它们在语法上可以出现在记录的任何地方。这两个修饰符的顺序无关紧要。这两个修饰符在记录中的出现次数不得超过一次。如果是，则检查_host（）是否退出，结果为“permerror”。
Unrecognized modifiers MUST be ignored no matter where, or how often, they appear in a record. This allows implementations conforming to this document to gracefully handle records with modifiers that are defined in other specifications.
无论未识别的修饰符出现在记录中的位置或频率如何，都必须忽略它们。这使得符合本文档的实现能够使用其他规范中定义的修饰符优雅地处理记录。
The "redirect" modifier is intended for consolidating both authorizations and policy into a common set to be shared within a single ADMD. It is possible to control both authorized hosts and policy for an arbitrary number of domains from a single record.
“重定向”修饰符用于将授权和策略合并到一个公共集合中，以便在单个ADMD中共享。可以从单个记录控制任意数量域的授权主机和策略。
redirect = "redirect" "=" domain-spec
redirect=“redirect”“=”域规范
If all mechanisms fail to match, and a "redirect" modifier is present, then processing proceeds as follows:
如果所有机制都不匹配，并且存在“重定向”修饰符，则处理过程如下：
The <domain-spec> portion of the redirect section is expanded as per the macro rules in Section 7. Then check_host() is evaluated with the resulting string as the <domain>. The <ip> and <sender> arguments remain the same as in the current evaluation of check_host().
重定向部分的<domain spec>部分根据第7节中的宏规则展开。然后，check_host（）将使用结果字符串作为<domain>进行计算。<ip>和<sender>参数与check_host（）当前计算中的参数保持相同。
The result of this new evaluation of check_host() is then considered the result of the current evaluation with the exception that if no SPF record is found, or if the <target-name> is malformed, the result is a "permerror" rather than "none".
然后，check_host（）的新求值结果将被视为当前求值的结果，但如果未找到SPF记录，或者如果<target name>格式不正确，则结果将是“permerror”而不是“none”。
Note that the newly queried domain can itself specify redirect processing.
请注意，新查询的域本身可以指定重定向处理。
This facility is intended for use by organizations that wish to apply the same record to multiple domains. For example:
此功能旨在供希望将同一记录应用于多个域的组织使用。例如：
la.example.com. TXT "v=spf1 redirect=_spf.example.com"
ny.example.com. TXT "v=spf1 redirect=_spf.example.com"
sf.example.com. TXT "v=spf1 redirect=_spf.example.com"
_spf.example.com. TXT "v=spf1 mx:example.com -all"
la.example.com. TXT "v=spf1 redirect=_spf.example.com"
ny.example.com. TXT "v=spf1 redirect=_spf.example.com"
sf.example.com. TXT "v=spf1 redirect=_spf.example.com"
_spf.example.com. TXT "v=spf1 mx:example.com -all"
In this example, mail from any of the three domains is described by the same record. This can be an administrative advantage.
在本例中，来自三个域中任意一个域的邮件由同一记录描述。这可能是一种管理优势。
Note: In general, the domain "A" cannot reliably use a redirect to another domain "B" not under the same administrative control. Since the <sender> stays the same, there is no guarantee that the record at domain "B" will correctly work for mailboxes in domain "A", especially if domain "B" uses mechanisms involving local-parts. An "include" directive will generally be more appropriate.
注意：通常，域“A”无法可靠地使用重定向到不在同一管理控制下的另一个域“B”。由于<sender>保持不变，因此无法保证域“B”中的记录将正确用于域“A”中的邮箱，特别是如果域“B”使用涉及本地部分的机制。“包含”指令通常更合适。
For clarity, any "redirect" modifier SHOULD appear as the very last term in a record. Any "redirect" modifier MUST be ignored if there is an "all" mechanism anywhere in the record.
为清楚起见，任何“重定向”修饰符都应该作为记录中的最后一个术语出现。如果记录中的任何地方都有“全部”机制，则必须忽略任何“重定向”修饰符。
explanation = "exp" "=" domain-spec
解释=“exp”“=”域规范
If check_host() results in a "fail" due to a mechanism match (such as "-all"), and the "exp" modifier is present, then the explanation string returned is computed as described below. If no "exp" modifier is present, then either a default explanation string or an empty explanation string MUST be returned to the calling application.
如果check_host（）由于机制匹配（例如“-all”）而导致“失败”，并且存在“exp”修饰符，则返回的解释字符串将按如下所述进行计算。如果不存在“exp”修饰符，则必须将默认解释字符串或空解释字符串返回给调用应用程序。
The <domain-spec> is macro expanded (see Section 7) and becomes the <target-name>. The DNS TXT RRset for the <target-name> is fetched.
<domain spec>被宏扩展（参见第7节），并成为<target name>。已获取<target name>的DNS TXT RRset。
If there are any DNS processing errors (any RCODE other than 0), or if no records are returned, or if more than one record is returned, or if there are syntax errors in the explanation string, then proceed as if no "exp" modifier was given.
如果存在任何DNS处理错误（除0以外的任何RCODE），或者如果没有返回任何记录，或者如果返回了多个记录，或者如果解释字符串中存在语法错误，则继续操作，就像没有给出“exp”修饰符一样。
The fetched TXT record's strings are concatenated with no spaces, and then treated as an explain-string, which is macro-expanded. This final result is the explanation string. Implementations MAY limit the length of the resulting explanation string to allow for other protocol constraints and/or reasonable processing limits. Since the explanation string is intended for an SMTP response and Section 2.4 of [RFC5321] says that responses are in [US-ASCII], the explanation string MUST be limited to [US-ASCII].
获取的TXT记录的字符串被连接起来，没有空格，然后被视为解释字符串，该字符串被宏扩展。最后的结果就是解释字符串。实现可能会限制结果解释字符串的长度，以允许其他协议约束和/或合理的处理限制。由于解释字符串用于SMTP响应，[RFC5321]第2.4节规定响应为[US-ASCII]，因此解释字符串必须限制为[US-ASCII]。
Software evaluating check_host() can use this string to communicate information from the publishing domain in the form of a short message or URL. Software SHOULD make it clear that the explanation string comes from a third party. For example, it can prepend the macro string "%{o} explains: " to the explanation, as shown in the example in Section 8.4.
软件可以使用此字符串以短消息或URL的形式从发布域传递信息。软件应明确说明解释字符串来自第三方。例如，它可以在解释前面加上宏字符串“{o}explains:”，如第8.4节中的示例所示。
Suppose example.com has this record:
假设example.com有以下记录：
v=spf1 mx -all exp=explain._spf.%{d}
v=spf1 mx -all exp=explain._spf.%{d}
Here are some examples of possible explanation TXT records at explain._spf.example.com:
以下是explain.spf.EXPLACE.com上可能的解释TXT记录的一些示例：
"Mail from example.com should only be sent by its own servers."
“example.com的邮件只能由其自己的服务器发送。”
-- a simple, constant message
--一个简单、不变的信息
"%{i} is not one of %{d}'s designated mail servers."
"%{i} is not one of %{d}'s designated mail servers."
-- a message with a little more information, including the IP address that failed the check
--包含更多信息的消息，包括检查失败的IP地址
"See http://%{d}/why.html?s=%{S}&i=%{I}"
"See http://%{d}/why.html?s=%{S}&i=%{I}"
-- a complicated example that constructs a URL with the arguments to check_host() so that a web page can be generated with detailed, custom instructions
--这是一个复杂的示例，它使用check_host（）的参数构造URL，以便生成带有详细自定义说明的网页
Note: During recursion into an "include" mechanism, an "exp" modifier from the <target-name> MUST NOT be used. In contrast, when executing a "redirect" modifier, an "exp" modifier from the original domain MUST NOT be used. This is because "include" is meant to cross administrative boundaries and the explanation provided should be the one from the receiving ADMD, while "redirect" is meant to operate as a tool to consolidate policy records within an ADMD so the redirected explanation is the one that ought to have priority.
注意：在递归到“include”机制期间，不能使用<target name>中的“exp”修饰符。相反，当执行“重定向”修饰符时，不能使用来自原始域的“exp”修饰符。这是因为“包含”意味着跨越管理边界，提供的解释应该是接收ADMD的解释，而“重定向”意味着作为一种工具来整合ADMD中的策略记录，因此重定向的解释应该具有优先权。
When evaluating an SPF policy record, certain character sequences are intended to be replaced by parameters of the message or of the connection. These character sequences are referred to as "macros".
在评估SPF策略记录时，某些字符序列将被消息或连接的参数替换。这些字符序列称为“宏”。
The ABNF description for a macro is as follows:
宏的ABNF描述如下：
domain-spec = macro-string domain-end
domain-end = ( "." toplabel [ "." ] ) / macro-expand
domain-spec = macro-string domain-end
domain-end = ( "." toplabel [ "." ] ) / macro-expand
toplabel = ( *alphanum ALPHA *alphanum ) /
( 1*alphanum "-" *( alphanum / "-" ) alphanum )
alphanum = ALPHA / DIGIT
toplabel = ( *alphanum ALPHA *alphanum ) /
( 1*alphanum "-" *( alphanum / "-" ) alphanum )
alphanum = ALPHA / DIGIT
explain-string = *( macro-string / SP )
explain-string = *( macro-string / SP )
macro-string = *( macro-expand / macro-literal )
macro-expand = ( "%{" macro-letter transformers *delimiter "}" )
/ "%%" / "%_" / "%-"
macro-literal = %x21-24 / %x26-7E
; visible characters except "%"
macro-letter = "s" / "l" / "o" / "d" / "i" / "p" / "h" /
"c" / "r" / "t" / "v"
transformers = *DIGIT [ "r" ]
delimiter = "." / "-" / "+" / "," / "/" / "_" / "="
macro-string = *( macro-expand / macro-literal )
macro-expand = ( "%{" macro-letter transformers *delimiter "}" )
/ "%%" / "%_" / "%-"
macro-literal = %x21-24 / %x26-7E
; visible characters except "%"
macro-letter = "s" / "l" / "o" / "d" / "i" / "p" / "h" /
"c" / "r" / "t" / "v"
transformers = *DIGIT [ "r" ]
delimiter = "." / "-" / "+" / "," / "/" / "_" / "="
The "toplabel" construction is subject to the letter-digit-hyphen (LDH) rule plus additional top-level domain (TLD) restrictions. See Section 2 of [RFC3696] for background.
“toplabel”构造受字母-数字连字符（LDH）规则和其他顶级域（TLD）限制的约束。背景见[RFC3696]第2节。
Some special cases:
一些特殊情况：
o A literal "%" is expressed by "%%".
o 文字“%”用“%”表示。
o "%_" expands to a single " " space.
o “%”扩展到单个“”空间。
o "%-" expands to a URL-encoded space, viz., "%20".
o “%-”扩展为URL编码的空间，即“%20”。
The following macro letters are expanded in term arguments:
以下宏字母在术语参数中展开：
s = <sender>
l = local-part of <sender>
o = domain of <sender>
d = <domain>
i = <ip>
p = the validated domain name of <ip> (do not use)
v = the string "in-addr" if <ip> is ipv4, or "ip6" if <ip> is ipv6
h = HELO/EHLO domain
s = <sender>
l = local-part of <sender>
o = domain of <sender>
d = <domain>
i = <ip>
p = the validated domain name of <ip> (do not use)
v = the string "in-addr" if <ip> is ipv4, or "ip6" if <ip> is ipv6
h = HELO/EHLO domain
<domain>, <sender>, and <ip> are defined in Section 4.1.
<domain>、<sender>和<ip>在第4.1节中有定义。
The following macro letters are allowed only in "exp" text:
以下宏字母仅允许在“exp”文本中使用：
c = SMTP client IP (easily readable format) r = domain name of host performing the check t = current timestamp
c=SMTP客户端IP（易读格式）r=执行检查的主机的域名t=当前时间戳
A '%' character not followed by a '{', '%', '-', or '_' character is a syntax error. So:
“%”字符后面没有“{'、“%”、“-”或“"”字符是语法错误。因此：
-exists:%(ir).sbl.example.org
-存在：%（ir）.sbl.example.org
is incorrect and will cause check_host() to yield a "permerror". Instead, the following is legal:
不正确，将导致check_host（）产生“permerror”。相反，以下内容是合法的：
-exists:%{ir}.sbl.example.org
-exists:%{ir}.sbl.example.org
Optional transformers are the following:
可选变压器如下所示：
*DIGIT = zero or more digits
*数字=零个或多个数字
'r' = reverse value, splitting on dots by default
“r”=反向值，默认情况下在点上拆分
If transformers or delimiters are provided, the replacement value for a macro letter is split into parts separated by one or more of the specified delimiter characters. After performing any reversal operation and/or removal of left-hand parts, the parts are rejoined using "." and not the original splitting characters.
如果提供了转换符或分隔符，则宏字母的替换值将拆分为由一个或多个指定分隔符字符分隔的部分。执行任何反转操作和/或移除左侧零件后，零件将使用“.”而不是原始拆分字符重新连接。
By default, strings are split on "." (dots). Note that no special treatment is given to leading, trailing, or consecutive delimiters in input strings, and so the list of parts might contain empty strings. Some older implementations of SPF prohibit trailing dots in domain names, so trailing dots SHOULD NOT be published, although they MUST be accepted by implementations conforming to this document. Macros can specify delimiter characters that are used instead of ".".
默认情况下，字符串在“.”（点）上拆分。请注意，没有对输入字符串中的前导、尾随或连续分隔符进行特殊处理，因此部件列表可能包含空字符串。一些旧的SPF实现禁止域名中的尾随点，因此不应发布尾随点，尽管它们必须被符合本文档的实现所接受。宏可以指定用来代替“.”的分隔符字符。
The "r" transformer indicates a reversal operation: if the client IP address were 192.0.2.1, the macro %{i} would expand to "192.0.2.1" and the macro %{ir} would expand to "1.2.0.192".
“r”转换器表示反转操作：如果客户端IP地址为192.0.2.1，则宏%{i}将扩展到“192.0.2.1”，宏%{ir}将扩展到“1.2.0.192”。
The DIGIT transformer indicates the number of right-hand parts to use, after optional reversal. If a DIGIT is specified, the value MUST be nonzero. If no DIGITs are specified, or if the value specifies more parts than are available, all the available parts are
数字转换器指示可选反转后要使用的右侧部件的数量。如果指定了数字，则该值必须为非零。如果未指定任何数字，或者如果该值指定的零件数超过可用零件数，则所有可用零件均为空
used. If the DIGIT was 5, and only 3 parts were available, the macro interpreter would pretend the DIGIT was 3. Implementations MUST support at least a value of 127, as that is the maximum number of labels in a domain name (less the zero-length label at the end).
习惯于如果数字是5，并且只有3个部分可用，宏解释器将假装数字是3。实现必须至少支持127的值，因为这是域名中标签的最大数量（减去末尾的零长度标签）。
The "s" macro expands to the <sender> argument. It is an email address with a local-part, an "@" character, and a domain. The "l" macro expands to just the local-part. The "o" macro expands to just the domain part. Note that these values remain the same during recursive and chained evaluations due to "include" and/or "redirect". Note also that if the original <sender> had no local-part, the local-part was set to "postmaster" in initial processing (see Section 4.3).
“s”宏展开为<sender>参数。它是一个包含本地部分、“@”字符和域的电子邮件地址。“l”宏仅扩展到局部零件。“o”宏仅扩展到域部分。请注意，由于“包含”和/或“重定向”，这些值在递归和链式计算期间保持不变。还请注意，如果原始<sender>没有本地部分，则在初始处理中将本地部分设置为“postmaster”（参见第4.3节）。
For IPv4 addresses, both the "i" and "c" macros expand to the standard dotted-quad format.
对于IPv4地址，“i”和“c”宏都扩展为标准的虚线四元格式。
For IPv6 addresses, the "i" macro expands to a dot-format address; it is intended for use in %{ir}. The "c" macro can expand to any of the hexadecimal colon-format addresses specified in Section 2.2 of [RFC4291]. It is intended for humans to read.
对于IPv6地址，“i”宏扩展为点格式地址；它用于%{ir}。“c”宏可以扩展到[RFC4291]第2.2节中指定的任何十六进制冒号格式地址。它是供人类阅读的。
The "p" macro expands to the validated domain name of <ip>. The procedure for finding the validated domain name is defined in Section 5.5. If the <domain> is present in the list of validated domains, it SHOULD be used. Otherwise, if a subdomain of the <domain> is present, it SHOULD be used. Otherwise, any name from the list can be used. If there are no validated domain names or if a DNS error occurs, the string "unknown" is used.
“p”宏将扩展到已验证的域名<ip>。第5.5节定义了查找已验证域名的程序。如果验证域列表中存在<domain>，则应使用它。否则，如果存在<domain>的子域，则应使用它。否则，可以使用列表中的任何名称。如果没有经过验证的域名或发生DNS错误，则使用字符串“未知”。
This macro SHOULD NOT be published (see Section 5.5 for the discussion).
不应发布此宏（有关讨论，请参阅第5.5节）。
The "h" macro expands to the parameter that was provided to the SMTP server via the HELO or EHLO SMTP verb. For sessions where that verb was provided more than once, the most recent instance is used.
“h”宏扩展为通过HELO或EHLO SMTP谓词提供给SMTP服务器的参数。对于多次提供该动词的会话，将使用最近的实例。
The "r" macro expands to the name of the receiving MTA. This SHOULD be a fully qualified domain name, but if one does not exist (as when the checking is done by a Mail User Agent (MUA)) or if policy restrictions dictate otherwise, the word "unknown" SHOULD be substituted. The domain name can be different from the name found in the MX record that the client MTA used to locate the receiving MTA.
“r”宏扩展为接收MTA的名称。这应该是一个完全限定的域名，但如果一个域名不存在（如由邮件用户代理（MUA）进行检查时），或者如果策略限制另有规定，则应替换“未知”一词。域名可能与客户端MTA用于定位接收MTA的MX记录中的名称不同。
The "t" macro expands to the decimal representation of the approximate number of seconds since the Epoch (Midnight, January 1, 1970, UTC) at the time of the evaluation. This is the same value as the value that is returned by the Portable Operating System Interface (POSIX) time() function in most standards-compliant libraries.
“t”宏扩展为十进制表示，表示自评估时的历元（1970年1月1日午夜，UTC）起的大约秒数。这与大多数符合标准的库中的Portable Operating System Interface（POSIX）time（）函数返回的值相同。
When the result of macro expansion is used in a domain name query, if the expanded domain name exceeds 253 characters (the maximum length of a domain name in this format), the left side is truncated to fit, by removing successive domain labels (and their following dots) until the total length does not exceed 253 characters.
当在域名查询中使用宏扩展的结果时，如果扩展的域名超过253个字符（此格式中域名的最大长度），则通过删除连续的域标签（及其下面的点）来截断左侧，直到总长度不超过253个字符。
Uppercase macros expand exactly as their lowercase equivalents, and are then URL escaped. URL escaping MUST be performed for characters not in the "unreserved" set, which is defined in [RFC3986].
大写宏与小写宏完全一样展开，然后进行URL转义。必须对不在[RFC3986]中定义的“未保留”集中的字符执行URL转义。
Care has to be taken by the sending ADMD so that macro expansion for legitimate email does not exceed the 63-character limit on DNS labels. The local-part of email addresses, in particular, can have more than 63 characters between dots.
发送ADMD时必须小心，以便合法电子邮件的宏扩展不会超过DNS标签上63个字符的限制。特别是电子邮件地址的本地部分，点与点之间的字符数可以超过63个。
To minimize DNS lookup resource requirements, it is better if sending ADMDs avoid using the "s", "l", "o", or "h" macros in conjunction with any mechanism directive. Although these macros are powerful and allow per-user records to be published, they severely limit the ability of implementations to cache results of check_host() and they reduce the effectiveness of DNS caches.
为了最大限度地减少DNS查找资源需求，发送ADMD时最好避免将“s”、“l”、“o”或“h”宏与任何机制指令结合使用。尽管这些宏功能强大，允许发布每用户记录，但它们严重限制了实现缓存check_host（）结果的能力，并降低了DNS缓存的有效性。
If no directive processed during the evaluation of check_host() contains an "s", "l", "o", or "h" macro, then the results of the evaluation can be cached on the basis of <domain> and <ip> alone for as long as the DNS record involved with the shortest Time to Live (TTL) has not expired.
如果在check_host（）求值期间处理的任何指令都不包含“s”、“l”、“o”或“h”宏，则只要涉及最短生存时间（TTL）的DNS记录尚未过期，就可以仅基于<domain>和<ip>缓存求值结果。
The <sender> is strong-bad@email.example.com. The IPv4 SMTP client IP is 192.0.2.3. The IPv6 SMTP client IP is 2001:db8::cb01. The PTR domain name of the client IP is mx.example.org.
<sender>很强-bad@email.example.com. IPv4 SMTP客户端IP为192.0.2.3。IPv6 SMTP客户端IP为2001:db8:：cb01。客户端IP的PTR域名是mx.example.org。
macro expansion
------- ----------------------------
%{s} strong-bad@email.example.com
%{o} email.example.com
%{d} email.example.com
%{d4} email.example.com
%{d3} email.example.com
%{d2} example.com
%{d1} com
%{dr} com.example.email
%{d2r} example.email
%{l} strong-bad
%{l-} strong.bad
%{lr} strong-bad
%{lr-} bad.strong
%{l1r-} strong
macro expansion
------- ----------------------------
%{s} strong-bad@email.example.com
%{o} email.example.com
%{d} email.example.com
%{d4} email.example.com
%{d3} email.example.com
%{d2} example.com
%{d1} com
%{dr} com.example.email
%{d2r} example.email
%{l} strong-bad
%{l-} strong.bad
%{lr} strong-bad
%{lr-} bad.strong
%{l1r-} strong
macro-string expansion
--------------------------------------------------------------------
%{ir}.%{v}._spf.%{d2} 3.2.0.192.in-addr._spf.example.com
%{lr-}.lp._spf.%{d2} bad.strong.lp._spf.example.com
macro-string expansion
--------------------------------------------------------------------
%{ir}.%{v}._spf.%{d2} 3.2.0.192.in-addr._spf.example.com
%{lr-}.lp._spf.%{d2} bad.strong.lp._spf.example.com
%{lr-}.lp.%{ir}.%{v}._spf.%{d2}
bad.strong.lp.3.2.0.192.in-addr._spf.example.com
%{lr-}.lp.%{ir}.%{v}._spf.%{d2}
bad.strong.lp.3.2.0.192.in-addr._spf.example.com
%{ir}.%{v}.%{l1r-}.lp._spf.%{d2}
3.2.0.192.in-addr.strong.lp._spf.example.com
%{ir}.%{v}.%{l1r-}.lp._spf.%{d2}
3.2.0.192.in-addr.strong.lp._spf.example.com
%{d2}.trusted-domains.example.net example.com.trusted-domains.example.net
%{d2}.trusted-domains.example.net example.com.trusted-domains.example.net
IPv6:
%{ir}.%{v}._spf.%{d2} 1.0.b.c.0.0.0.0.
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
IPv6:
%{ir}.%{v}._spf.%{d2} 1.0.b.c.0.0.0.0.
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
This section provides guidance for SPF verifier operators in response to the various possible outputs of check_host() on a message. Definitions of SPF results are presented in Section 2.6; this section provides more detail on each for use in developing local policy for message handling.
本节为SPF验证器操作员提供指导，以响应消息上check_host（）的各种可能输出。SPF结果的定义见第2.6节；本节详细介绍了在制定本地消息处理策略时使用的每种策略。
Every operating environment is different. There are some receivers for whom strict adherence to SPF is appropriate, and definitive treatment of messages that are evaluated to be explicitly unauthorized ("fail" and sometimes "softfail") is the norm. There are others for which the "false negative" cases are more of a
每个操作环境都是不同的。对于某些接收者来说，严格遵守SPF是合适的，对被评估为明确未经授权的消息的最终处理（“失败”，有时是“软失败”）是规范。还有一些“假阴性”案例更具争议性
concern. This concern is typically handled by merely recording the result in the header and allowing the message to pass on for additional processing. There are still others where SPF is one of several inputs to the message-handling decision. As such, there is no comprehensive normative requirement for message handling in response to any particular result. This section is provided to present a complete picture of the likely cause of each result and, where available, the experience gained during experimental deployment.
涉及通常，只需将结果记录在报头中并允许消息传递以进行额外处理，即可解决此问题。还有一些情况下，SPF是消息处理决策的几个输入之一。因此，对于响应任何特定结果的消息处理，没有全面的规范性要求。本节旨在提供每个结果的可能原因的完整图片，以及在实验部署期间获得的经验（如果可用）。
There are essentially two classes of handling choices:
基本上有两类处理选择：
o Handling within the SMTP session that attempted to deliver the message, such as by returning a permanent SMTP error (rejection) or temporary SMTP error ("try again later");
o 尝试传递邮件的SMTP会话内的处理，例如返回永久SMTP错误（拒绝）或临时SMTP错误（“稍后重试”）；
o Permitting the message to pass (a successful SMTP reply code) and adding an additional header field that indicates the result returned by check_host() and other salient details; this is discussed in more detail in Section 9.
o 允许邮件传递（一个成功的SMTP回复代码），并添加一个额外的标头字段，该字段指示check_host（）返回的结果和其他显著的详细信息；第9节对此进行了更详细的讨论。
With a "none" result, the SPF verifier has no information at all about the authorization or lack thereof of the client to use the checked identity or identities. The check_host() function completed without errors but was not able to reach any conclusion.
如果结果为“无”，则SPF验证者完全没有关于客户使用已检查身份的授权或缺乏授权的信息。check_host（）函数已完成，没有错误，但无法得出任何结论。
A "neutral" result indicates that although a policy for the identity was discovered, there is no definite assertion (positive or negative) about the client.
“中立”结果表明，尽管发现了身份的策略，但没有关于客户端的明确断言（肯定或否定）。
A "neutral" result MUST be treated exactly like the "none" result; the distinction exists only for informational purposes. Treating "neutral" more harshly than "none" would discourage ADMDs from testing the use of SPF records (see Section 10.1).
“中性”结果必须与“无”结果完全相同；这种区别仅用于提供信息。与“无”相比，更严厉地对待“中性”将阻止ADMD测试SPF记录的使用（见第10.1节）。
A "pass" result means the client is authorized to inject mail with the given identity. The domain can now, in the sense of reputation, be considered responsible for sending the message. Further policy checks can now proceed with confidence in the legitimate use of the identity. This is further discussed in Appendix G.1.
“通过”结果意味着客户端被授权使用给定的身份注入邮件。从声誉的角度来看，域现在可以被视为负责发送消息。进一步的政策检查现在可以在对合法使用身份有信心的情况下进行。附录G.1对此进行了进一步讨论。
A "fail" result is an explicit statement that the client is not authorized to use the domain in the given identity. Disposition of SPF fail messages is a matter of local policy. See Appendix G.2 for considerations on developing local policy.
“失败”结果是一个明确的声明，表明客户端无权使用给定标识中的域。SPF失败消息的处置取决于本地策略。关于制定当地政策的考虑，请参见附录G.2。
If the checking software chooses to reject the mail during the SMTP transaction, then it SHOULD use an SMTP reply code of 550 (see [RFC5321]) and, if supported, the 5.7.1 enhanced status code (see [RFC3463], Section 3.8), in addition to an appropriate reply text. The check_host() function will return either a default explanation string or one from the domain that published the SPF records (see Section 6.2). If the information does not originate with the checking software, it is good to make it clear that the text is provided by the sender's domain. For example:
如果检查软件选择在SMTP事务期间拒绝邮件，则除了适当的回复文本外，还应使用SMTP回复代码550（请参见[RFC5321]），以及5.7.1增强状态代码（请参见[RFC3463]，第3.8节），如果支持的话。check_host（）函数将返回默认解释字符串或发布SPF记录的域中的解释字符串（参见第6.2节）。如果信息不是源于检查软件，最好明确文本是由发件人的域提供的。例如：
550 5.7.1 SPF MAIL FROM check failed:
550 5.7.1 The domain example.com explains:
550 5.7.1 Please see http://www.example.com/mailpolicy.html
550 5.7.1 SPF MAIL FROM check failed:
550 5.7.1 The domain example.com explains:
550 5.7.1 Please see http://www.example.com/mailpolicy.html
If the checking software chooses not to reject the mail during the SMTP transaction, then it SHOULD add a Received-SPF or Authentication-Results header field (see Section 9) to communicate this result to downstream message processors. While this is true for all SPF results, it is of particular importance for "fail" results since the message is explicitly not authorized by the ADMD.
如果检查软件选择在SMTP事务期间不拒绝邮件，则应添加接收到的SPF或身份验证结果标头字段（请参阅第9节），以将此结果传达给下游消息处理器。虽然这适用于所有SPF结果，但对于“失败”结果尤其重要，因为消息未经ADMD明确授权。
A "softfail" result ought to be treated as somewhere between "fail" and "neutral"/"none". The ADMD believes the host is not authorized but is not willing to make a strong policy statement. Receiving software SHOULD NOT reject the message based solely on this result, but MAY subject the message to closer scrutiny than normal.
“软失败”结果应被视为介于“失败”和“中性”/“无”之间。ADMD认为东道主未经授权，但不愿意发表强硬的政策声明。接收软件不应仅基于此结果拒绝消息，但可能会对消息进行比正常情况更仔细的检查。
The ADMD wants to discourage the use of this host and thus desires limited feedback when a "softfail" result occurs. For example, the recipient's MUA could highlight the "softfail" status, or the receiving MTA could give the sender a message using greylisting [RFC6647], with a note the first time the message is received, but accept it on a later attempt based on receiver policy.
ADMD希望阻止使用此主机，因此在出现“softfail”结果时希望得到有限的反馈。例如，收件人的MUA可以突出显示“softfail”状态，或者接收MTA可以使用灰色列表[RFC6647]向发件人发送邮件，并在第一次收到邮件时附上备注，但在以后根据收件人策略尝试时接受。
A "temperror" result means the SPF verifier encountered a transient (generally DNS) error while performing the check. Checking software can choose to accept or temporarily reject the message. If the message is rejected during the SMTP transaction for this reason, the software SHOULD use an SMTP reply code of 451 and, if supported, the 4.4.3 enhanced status code (see Section 3.5 of [RFC3463]). These errors can be caused by problems in either the sender's or receiver's DNS software. See Appendix G.4 for considerations on developing local policy.
“temperror”结果表示SPF验证器在执行检查时遇到暂时（通常为DNS）错误。检查软件可以选择接受或暂时拒绝消息。如果邮件在SMTP交易期间因此原因被拒绝，软件应使用SMTP回复代码451，如果支持，应使用4.4.3增强状态代码（参见[RFC3463]第3.5节）。这些错误可能由发送方或接收方DNS软件中的问题引起。关于制定当地政策的考虑因素，请参见附录G.4。
A "permerror" result means the domain's published records could not be correctly interpreted. This signals an error condition that definitely requires DNS operator intervention to be resolved. If the message is rejected during the SMTP transaction for this reason, the software SHOULD use an SMTP reply code of 550 and, if supported, the 5.5.2 enhanced status code (see [RFC3463], Section 3.6). Be aware that if the ADMD uses macros (Section 7), it is possible that this result is due to the checked identities having an unexpected format. It is also possible that this result is generated by certain SPF verifiers due to the input arguments having an unexpected format; see Section 4.8. See Appendix G.3 for considerations on developing local policy.
“permerror”结果意味着无法正确解释域的已发布记录。这表明存在一个错误情况，需要DNS操作员干预才能解决。如果邮件在SMTP事务期间因此原因被拒绝，软件应使用SMTP回复代码550，如果支持，应使用5.5.2增强状态代码（请参阅[RFC3463]，第3.6节）。请注意，如果ADMD使用宏（第7节），则此结果可能是由于选中的标识具有意外的格式。由于输入参数具有意外的格式，该结果也可能由某些SPF验证器生成；见第4.8节。关于制定当地政策的考虑因素，请参见附录G.3。
To provide downstream agents, such as MUAs, with the information they might need in terms of evaluating or representing the apparent safety of the message content, it is RECOMMENDED that SMTP receivers record the result of SPF processing in the message header. For SPF verifier operators that choose to record SPF results in the header of the message for processing by internal filters or MUAs, two methods are presented: Section 9.1 defines the Received-SPF field, which is the results field originally defined for SPF use. Section 9.2 discusses the Authentication-Results header field [RFC7001], which was specified more recently and is designed for use by SPF and other authentication methods.
为了向下游代理（如MUA）提供其在评估或表示邮件内容的表面安全性方面可能需要的信息，建议SMTP接收方在邮件头中记录SPF处理的结果。对于选择在消息头中记录SPF结果以供内部筛选器或MUA处理的SPF验证器运算符，提供了两种方法：第9.1节定义了接收的SPF字段，这是最初为SPF使用定义的结果字段。第9.2节讨论了身份验证结果标题字段[RFC7001]，该字段是最近指定的，旨在供SPF和其他身份验证方法使用。
Both are in common use, and hence both are included here. However, it is important to note that they were designed to serve slightly different purposes. Received-SPF is intended to include enough information to enable reconstruction of the SPF evaluation of the message, while Authentication-Results is designed only to relay the result itself and related output details of likely use to end users (e.g., what property of the message was actually authenticated and
两者都是常用的，因此都包含在这里。然而，需要注意的是，它们的设计目的略有不同。接收到的SPF旨在包括足够的信息，以便能够重建消息的SPF评估，而认证结果仅设计为将结果本身和可能使用的相关输出细节转发给最终用户（例如，消息的哪些属性实际经过认证，以及
what it contained), leaving reconstructive work to the purview of system logs and the Received field contents. Also, Received-SPF relies on compliance of agents within the receiving ADMD to adhere to the header field ordering rules of [RFC5321] and [RFC5322], while Authentication-Results includes some provisions to protect against non-compliant implementations.
将重建工作留给系统日志和接收字段内容的权限。此外，接收到的SPF依赖于接收ADMD中的代理的合规性，以遵守[RFC5321]和[RFC5322]的头字段排序规则，而身份验证结果包括一些防止不合规实现的规定。
An SPF verifier operator could choose to use both to serve different downstream agents. In such cases, care needs to be taken to ensure that both fields are conveying the same details, or unexpected results can occur.
SPF验证器操作员可以选择使用两者来服务不同的下游代理。在这种情况下，需要注意确保两个字段传递相同的细节，否则可能会出现意外结果。
The Received-SPF header field is a trace field (see [RFC5322], Section 3.6.7) and SHOULD be prepended to the existing header, above the Received: field that is generated by the SMTP receiver. It MUST appear above all other Received-SPF fields in the message. The header field has the following format:
接收到的SPF标头字段是跟踪字段（请参阅[RFC5322]，第3.6.7节），并且应在现有标头之前，位于SMTP接收器生成的Received:字段上方。它必须出现在消息中所有其他收到的SPF字段的上方。标题字段的格式如下：
header-field = "Received-SPF:" [CFWS] result FWS [comment FWS] [ key-value-list ] CRLF
header field=“Received SPF:[CFWS]结果FWS[注释FWS][键值列表]CRLF
result = "pass" / "fail" / "softfail" / "neutral" /
"none" / "temperror" / "permerror"
result = "pass" / "fail" / "softfail" / "neutral" /
"none" / "temperror" / "permerror"
key-value-list = key-value-pair *( ";" [CFWS] key-value-pair )
[";"]
key-value-list = key-value-pair *( ";" [CFWS] key-value-pair )
[";"]
key-value-pair = key [CFWS] "=" ( dot-atom / quoted-string )
key-value-pair = key [CFWS] "=" ( dot-atom / quoted-string )
key = "client-ip" / "envelope-from" / "helo" /
"problem" / "receiver" / "identity" /
"mechanism" / name
key = "client-ip" / "envelope-from" / "helo" /
"problem" / "receiver" / "identity" /
"mechanism" / name
identity = "mailfrom" ; for the "MAIL FROM" identity
/ "helo" ; for the "HELO" identity
/ name ; other identities
identity = "mailfrom" ; for the "MAIL FROM" identity
/ "helo" ; for the "HELO" identity
/ name ; other identities
dot-atom = <unquoted word as per [RFC5322]>
quoted-string = <quoted string as per [RFC5322]>
comment = <comment string as per [RFC5322]>
CFWS = <comment or folding white space as per [RFC5322]>
FWS = <folding white space as per [RFC5322]>
CRLF = <standard end-of-line token as per [RFC5322]>
dot-atom = <unquoted word as per [RFC5322]>
quoted-string = <quoted string as per [RFC5322]>
comment = <comment string as per [RFC5322]>
CFWS = <comment or folding white space as per [RFC5322]>
FWS = <folding white space as per [RFC5322]>
CRLF = <standard end-of-line token as per [RFC5322]>
The header field SHOULD include a "(...)" style comment after the result, conveying supporting information for the result, such as <ip>, <sender>, and <domain>.
标题字段应在结果后包含一个“（…）”样式的注释，用于传递结果的支持信息，如<ip>、<sender>和<domain>。
The following key-value pairs are designed for later machine parsing. SPF verifiers SHOULD give enough information so that the SPF results can be verified -- that is, at least "client-ip", "helo", and, if the "MAIL FROM" identity was checked, "envelope-from".
以下键值对是为以后的机器解析而设计的。SPF验证者应该提供足够的信息，以便能够验证SPF结果——即，至少“客户端ip”、“helo”，如果“邮件发件人”身份被选中，“信封发件人”。
client-ip the IP address of the SMTP client
客户端ip SMTP客户端的ip地址
envelope-from the envelope sender mailbox
信封发件人邮箱中的信封
helo the host name given in the HELO or EHLO command
helo在helo或EHLO命令中给出的主机名
mechanism the mechanism that matched (if no mechanisms matched, substitute the word "default")
机制匹配的机制（如果没有匹配的机制，则替换“默认”一词）
problem if an error was returned, details about the error
问题如果返回错误，请提供有关错误的详细信息
receiver the host name of the SPF verifier
接收方SPF验证器的主机名
identity the identity that was checked; see the <identity> ABNF rule
标识已检查的标识；请参阅<identity>ABNF规则
Other keys MAY be defined by SPF verifiers.
其他密钥可由SPF验证器定义。
SPF verifiers MUST make sure that the Received-SPF header field does not contain invalid characters, is not excessively long (see [RFC5322], Section 2.1.1), and does not contain malicious data that has been provided by the sender.
SPF验证器必须确保接收到的SPF标头字段不包含无效字符、不过长（请参阅[RFC5322]，第2.1.1节），并且不包含发送方提供的恶意数据。
Examples of various header field styles that could be generated are the following:
可以生成的各种标题字段样式的示例如下：
Received-SPF: pass (mybox.example.org: domain of
myname@example.com designates 192.0.2.1 as permitted sender)
receiver=mybox.example.org; client-ip=192.0.2.1;
envelope-from="myname@example.com"; helo=foo.example.com;
Received-SPF: pass (mybox.example.org: domain of
myname@example.com designates 192.0.2.1 as permitted sender)
receiver=mybox.example.org; client-ip=192.0.2.1;
envelope-from="myname@example.com"; helo=foo.example.com;
Received-SPF: fail (mybox.example.org: domain of
myname@example.com does not designate
192.0.2.1 as permitted sender)
identity=mailfrom; client-ip=192.0.2.1;
envelope-from="myname@example.com";
Received-SPF: fail (mybox.example.org: domain of
myname@example.com does not designate
192.0.2.1 as permitted sender)
identity=mailfrom; client-ip=192.0.2.1;
envelope-from="myname@example.com";
Received-SPF: pass (mybox.example.org: domain of
myname@example.com designates 192.0.2.1 as permitted sender)
receiver=mybox.example.org; client-ip=192.0.2.1;
mechanism=ip4:192.0.2.1; envelope-from="myname@example.com";
helo=foo.example.com;
Received-SPF: pass (mybox.example.org: domain of
myname@example.com designates 192.0.2.1 as permitted sender)
receiver=mybox.example.org; client-ip=192.0.2.1;
mechanism=ip4:192.0.2.1; envelope-from="myname@example.com";
helo=foo.example.com;
As mentioned in Section 9, the Authentication-Results header field is designed to communicate lists of tests a border MTA did and their results. The specified elements of the field provide less information than the Received-SPF field:
如第9节所述，Authentication Results header字段用于传递border MTA执行的测试列表及其结果。字段的指定元素提供的信息少于收到的SPF字段：
Authentication-Results: myhost.example.org; spf=pass
smtp.mailfrom=example.net
Authentication-Results: myhost.example.org; spf=pass
smtp.mailfrom=example.net
Received-SPF: pass (myhost.example.org: domain of
myname@example.com designates 192.0.2.1 as permitted sender)
receiver=mybox.example.org; client-ip=192.0.2.1;
envelope-from="myname@example.com"; helo=foo.example.com;
Received-SPF: pass (myhost.example.org: domain of
myname@example.com designates 192.0.2.1 as permitted sender)
receiver=mybox.example.org; client-ip=192.0.2.1;
envelope-from="myname@example.com"; helo=foo.example.com;
It is, however, possible to add CFWS in the "reason" part of an Authentication-Results header field and provide the equivalent information, if desired.
但是，如果需要，可以在身份验证结果标头字段的“原因”部分添加CFW，并提供等效信息。
As an example, an expanded Authentication-Results header field might look like (for a "MAIL FROM" check in this example):
例如，扩展的身份验证结果标题字段可能如下所示（对于本例中的“邮件发件人”检查）：
Authentication-Results: myhost.example.org; spf=pass
reason="client-ip=192.0.2.1; smtp.helo=foo.example.com"
smtp.mailfrom=user@example.net
Authentication-Results: myhost.example.org; spf=pass
reason="client-ip=192.0.2.1; smtp.helo=foo.example.com"
smtp.mailfrom=user@example.net
This section outlines the major implications that adoption of this protocol will have on various entities involved in Internet email. It is intended to make clear to the reader where this protocol knowingly affects the operation of such entities. This section is not a "how-to" manual, or a "best practices" document, and it is not a comprehensive list of what such entities ought to do in light of this specification.
本节概述了采用本协议将对互联网电子邮件中涉及的各种实体产生的主要影响。本协议旨在向读者明确本协议在何处故意影响此类实体的运行。本节不是“操作”手册或“最佳实践”文件，也不是此类实体根据本规范应做什么的综合列表。
This section provides operational advice and instruction only. It is non-normative.
本节仅提供操作建议和说明。这是不规范的。
[RFC5598] describes the Internet email architecture. This section is organized based on the different segments of the architecture.
[RFC5598]描述了Internet电子邮件体系结构。本节根据体系结构的不同部分进行组织。
Originating ADMDs (ADministrative Management Domains -- Sections 2.2.1 and 2.3 of [RFC5598]) that wish to be compliant with this specification will need to determine the list of relays ([RFC5598], Section 2.2.2) that they allow to use their domain name in the "HELO" and "MAIL FROM" identities when relaying to other ADMDs. It is recognized that forming such a list is not just a simple technical exercise, but involves policy decisions with both technical and administrative considerations.
希望符合本规范的原始ADMD（管理管理域--[RFC5598]第2.2.1节和第2.3节）需要确定中继列表（[RFC5598]第2.2.2节），它们允许在中继到其他ADMD时在“HELO”和“MAIL FROM”标识中使用其域名。人们认识到，形成这样一份清单不仅是一项简单的技术工作，而且涉及到技术和行政考虑的政策决定。
Minimizing the DNS resources needed for SPF lookups can be done by choosing directives that require less DNS information and by placing lower-cost mechanisms earlier in the SPF record.
通过选择需要较少DNS信息的指令，并在SPF记录中较早地放置成本较低的机制，可以最小化SPF查找所需的DNS资源。
Section 4.6.4 specifies the limits receivers have to use. It is essential to publish records that do not exceed these requirements. It is also required to carefully weigh the cost and the maintainability of licit solutions.
第4.6.4节规定了接收器必须使用的限制。必须发布不超过这些要求的记录。还需要仔细权衡合法解决方案的成本和可维护性。
For example, consider a domain set up as follows:
例如，考虑以下设置的域：
example.com. IN MX 10 mx.example.com. IN MX 20 mx2.example.com. mx.example.com. IN A 192.0.2.1 mx2.example.com. IN A 192.0.2.129
example.com。在MX 10 MX.example.com中。在MX 20 mx2.example.com中。mx.example.com。在192.0.2.1 mx2.example.com中。在192.0.2.129中
Assume the administrative point is to authorize (pass) mx and mx2 while failing every other host. Compare the following solutions:
假设管理点是授权（通过）mx和mx2，同时使其他主机发生故障。比较以下解决方案：
Best record:
example.com. IN TXT "v=spf1 ip4:192.0.2.1 ip4:192.0.2.129 -all"
Best record:
example.com. IN TXT "v=spf1 ip4:192.0.2.1 ip4:192.0.2.129 -all"
Good record: $ORIGIN example.com. @ IN TXT "v=spf1 a:authorized-spf.example.com -all" authorized-spf IN A 192.0.2.1 IN A 192.0.2.129
良好记录：$ORIGIN example.com@在TXT“v=spf1 a:authorized-spf.example.com-all”中，在192.0.2.129中的192.0.2.1中使用授权spf
Expensive record:
example.com. IN TXT "v=spf1 mx:example.com -all"
Expensive record:
example.com. IN TXT "v=spf1 mx:example.com -all"
Wasteful, bad record:
example.com. IN TXT "v=spf1 ip4:192.0.2.0/24 mx -all"
Wasteful, bad record:
example.com. IN TXT "v=spf1 ip4:192.0.2.0/24 mx -all"
There might be administrative considerations: using "a" over "ip4" or "ip6" allows hosts to be renumbered easily at the cost of a DNS query per receiver. Using "mx" over "a" allows the set of mail hosts to be changed easily. Unless such changes are common, it is better to use the less resource-intensive mechanisms like "ip4" and "ip6" over "a" or "a" over "mx".
可能存在管理方面的考虑：在“ip4”或“ip6”上使用“a”可以轻松地对主机重新编号，但代价是每个接收器进行DNS查询。在“a”上使用“mx”可以轻松更改邮件主机集。除非这种变化很普遍，否则最好使用资源密集度较低的机制，如“ip4”和“ip6”而不是“a”或“a”而不是“mx”。
In some specific cases, standard advice on record content is appropriate. Publishing SPF records for domains that send no mail is a well-established best practice. The record for a domain that sends no mail is:
在某些特定情况下，关于记录内容的标准建议是合适的。为不发送邮件的域发布SPF记录是公认的最佳做法。不发送邮件的域的记录为：
www.example.com. IN TXT "v=spf1 -all"
www.example.com。在TXT中“v=spf1-全部”
Publishing SPF records for individual hosts is also best practice. The host name is generally the identity used in the 5321.HELO/.EHLO command. In the case of messages with a null 5321.MailFrom, this is used as the domain for 5321.MailFrom SPF checks, in addition to being used in 5321.HELO/.EHLO-based SPF checks. The standard SPF record for an individual host that is involved in mail processing is:
为单个主机发布SPF记录也是最佳做法。主机名通常是5321.HELO/.EHLO命令中使用的标识。对于带有null 5321.MailFrom的邮件，除了在基于5321.HELO/.EHLO的SPF检查中使用之外，它还用作5321.MailFrom SPF检查的域。参与邮件处理的单个主机的标准SPF记录为：
relay.example.com. IN TXT "v=spf1 a -all"
relay.example.com。在TXT中“v=spf1 a-全部”
Validating correct deployment is difficult. [RFC6652] describes one mechanism for soliciting feedback on SPF failures. Another suggestion can be found in Appendix C.
验证正确的部署是困难的。[RFC6652]描述了一种征求SPF故障反馈的机制。另一项建议见附录C。
Regardless of the method used, understanding the ADMD's outbound mail architecture is essential to effective deployment.
无论使用何种方法，了解ADMD的出站邮件体系结构对于有效部署都至关重要。
As explained in Section 2.4, [RFC5321] allows the MAIL FROM to be null, which is typical of some Delivery Status Notifications [RFC3464], commonly called email bounces. In this case, the only entity available for performing an SPF check is the "HELO" identity defined in Section 1.1.4. SPF functionality is enhanced by administrators ensuring this identity is set correctly and has an appropriate SPF record. It is normal to have the "HELO" identity set to the host name instead of the domain. Zone file generation for significant numbers of hosts can be consolidated using the "redirect" modifier and scripted for initial deployment. Specific deployment advice is given above in Section 10.1.2.
如第2.4节所述，[RFC5321]允许来自的邮件为空，这是一些传递状态通知[RFC3464]的典型特征，通常称为电子邮件反弹。在这种情况下，可用于执行SPF检查的唯一实体是第1.1.4节中定义的“直升机”身份。管理员可增强SPF功能，确保正确设置此标识并具有适当的SPF记录。将“HELO”标识设置为主机名而不是域是正常的。可以使用“重定向”修改器合并大量主机的区域文件生成，并为初始部署编写脚本。具体部署建议见上文第10.1.2节。
SPF results can be used in combination with other methods to determine the final local disposition (either positive or negative) of a message. It can also be considered dispositive on its own.
SPF结果可与其他方法结合使用，以确定消息的最终本地处置（正面或负面）。它本身也可以被认为是决定性的。
An attempt to have one organization (sender) direct the email-handling policies of another (receiver) is inherently challenging and often controversial. As stated elsewhere in this document, there is no comprehensive normative requirement for specific handling of a message based on SPF results. The information presented in Section 8 and in Appendix G is offered for receiver consideration when forming local handling policies.
试图让一个组织（发送者）指导另一个组织（接收者）的电子邮件处理策略本身就具有挑战性，而且常常引起争议。如本文件其他部分所述，对于基于SPF结果的消息的具体处理，没有全面的规范性要求。第8节和附录G中提供的信息供接收方在制定本地处理政策时参考。
The primary considerations are that SPF might return "pass" for mail that is ultimately harmful (e.g., spammers that arrange for SPF to pass using disposable domain names, or virus or spam outbreaks from within trusted sources), and might also return "fail" for mail that is ultimately legitimate (e.g., legitimate mail that has traversed a mail alias). It is important to take both of these cases under consideration when establishing local handling policy.
主要考虑因素是，对于最终有害的邮件，SPF可能会返回“通过”（例如，使用一次性域名安排SPF通过的垃圾邮件发送者，或来自可信来源的病毒或垃圾邮件爆发），对于最终合法的邮件，SPF也可能返回“失败”（例如，穿过邮件别名的合法邮件）。在制定本地处理策略时，必须考虑这两种情况。
Mediators are a type of User Actor [RFC5598]. That is, a mediator takes 'delivery' of a message and posts a 'submission' of a new message. The mediator can make the newly posted message be as similar to or as different from the original message as they wish. Examples include mailing lists (see Section 5.3 of [RFC5598]) and ReSenders (Section 5.2 of [RFC5598]). This is discussed in [RFC5321], Section 3.9. For the operation of SPF, the essential concern is the email address in the 5321.MailFrom command for the new message.
中介是一种用户参与者[RFC5598]。也就是说，调解人接收消息的“传递”，并发布新消息的“提交”。调解人可以根据自己的意愿使新发布的消息与原始消息相似或不同。示例包括邮件列表（见[RFC5598]第5.3节）和重发邮件（见[RFC5598]第5.2节）。[RFC5321]第3.9节对此进行了讨论。对于SPF的操作，最重要的关注点是新消息的5321.MailFrom命令中的电子邮件地址。
Because SPF evaluation is based on the IP address of the "last" sending SMTP server, the address of the mediator will be used, rather than the address of the SMTP server that sent the message to the mediator. Some mediators retain the email address from the original message, while some use a new address.
由于SPF计算基于“最后一个”发送SMTP服务器的IP地址，因此将使用中介的地址，而不是向中介发送邮件的SMTP服务器的地址。有些中介保留原始邮件中的电子邮件地址，而有些中介使用新地址。
If the address is the same as for the original message, and the original message had an associated SPF record, then the SPF evaluation will fail unless mitigations such as those described in Appendix D are used.
如果地址与原始报文的地址相同，且原始报文具有相关SPF记录，则SPF评估将失败，除非使用附录D中所述的缓解措施。
As with most aspects of email, there are a number of ways that malicious parties could use the protocol as an avenue for a DoS attack. The processing limits outlined in Section 4.6.4 are designed to prevent attacks such as the following:
与电子邮件的大多数方面一样，恶意方可以通过多种方式利用该协议进行DoS攻击。第4.6.4节中概述的处理限制旨在防止以下攻击：
o A malicious party could create an SPF record with many references to a victim's domain and send many emails to different SPF verifiers; those SPF verifiers would then create a DoS attack. In effect, the SPF verifiers are being used to amplify the attacker's bandwidth by using fewer octets in the SMTP session than are used by the DNS queries. Using SPF verifiers also allows the attacker to hide the true source of the attack. This potential attack is based on large volumes of mail being transmitted.
o 恶意方可以创建一个SPF记录，其中包含对受害者域的许多引用，并向不同的SPF验证者发送许多电子邮件；然后，这些SPF验证器将创建DoS攻击。实际上，SPF验证器通过在SMTP会话中使用比DNS查询更少的八位字节来放大攻击者的带宽。使用SPF验证器还允许攻击者隐藏攻击的真实来源。这种潜在的攻击是基于正在传输的大量邮件。
o Whereas implementations of check_host() are supposed to limit the number of DNS lookups, malicious domains could publish records that exceed these limits in an attempt to waste computation effort at their targets when they send them mail. Malicious domains could also design SPF records that cause particular implementations to use excessive memory or CPU or to trigger bugs. If a receiver is configured to accept mail with an SPF result of "temperror", such an attack might result in mail that would otherwise have been rejected due to an SPF "fail" result being accepted. This potential attack is based on specially crafted SPF records being used to exhaust DNS resources of the victim.
o 虽然check_host（）的实现应该限制DNS查找的数量，但恶意域可能会发布超过这些限制的记录，从而在向目标发送邮件时浪费计算时间。恶意域还可能设计SPF记录，导致特定实现使用过多的内存或CPU或触发错误。如果接收者配置为接受SPF结果为“temperror”的邮件，则此类攻击可能会导致邮件被拒绝，否则该邮件将由于接受SPF“fail”结果而被拒绝。此潜在攻击基于精心编制的SPF记录，这些记录用于耗尽受害者的DNS资源。
o Malicious parties could send a large volume of mail purporting to come from the intended target to a wide variety of legitimate mail hosts. These legitimate machines would then present a DNS load on the target as they fetched the relevant records.
o 恶意方可以将大量声称来自预期目标的邮件发送到各种合法邮件主机。当这些合法机器获取相关记录时，它们将在目标上呈现DNS负载。
o Malicious parties could, in theory, use SPF records as a vehicle for DNS lookup amplification for a DoS attack. In this scenario, the attacker publishes an SPF record in its own DNS that uses "a" and "mx" mechanisms directed toward the intended victim, e.g., "a:example.com a:foo.example.com a:bar.example.com ..." and then distributes mail with a MAIL FROM value including its own domain in large volume to a wide variety of destinations. Any such destination operating an SPF verifier will begin querying all of the names associated with the "a" mechanisms in that record. The names used in the record needn't exist for the attack to be effective. Operational experience since the publication of [RFC4408] suggests that mitigation of this class of attack can be accomplished with minimal impact on the deployed base by having
o 理论上，恶意方可以使用SPF记录作为DoS攻击的DNS查找放大工具。在这种情况下，攻击者在其自己的DNS中发布一条SPF记录，该记录使用指向目标受害者的“a”和“mx”机制，例如“a:example.com a:foo.example.com a:bar.example.com…”，然后将包含其自身域在内的“邮件发件人”值的邮件大量分发到各种目的地。任何操作SPF验证器的目的地都将开始查询该记录中与“a”机制关联的所有名称。记录中使用的名称不必存在，攻击才会有效。[RFC4408]发布以来的作战经验表明，通过以下方式，可以在对部署基地影响最小的情况下缓解此类攻击：
the verifier abort processing and return "permerror" (Section 2.6.7) as soon as more than two "void lookups" have been encountered (defined in Section 4.6.4).
一旦遇到两个以上的“无效查找”（定义见第4.6.4节），验证器将中止处理并返回“permerror”（第2.6.7节）。
Of these, the case of a third party referenced in the SPF record is the easiest for a DoS attack to effectively exploit. As a result, limits that might seem reasonable for an individual mail server can still allow an unreasonable amount of bandwidth amplification. Therefore, the processing limits need to be quite low.
其中，SPF记录中引用的第三方的情况最容易被DoS攻击有效利用。因此，对于单个邮件服务器来说似乎合理的限制仍然允许不合理的带宽放大。因此，处理限制需要非常低。
The "MAIL FROM" and "HELO" identity authorizations do not provide assurance about the authorization/authenticity of other identities used in the message. It is entirely possible for a malicious sender to inject a message using his own domain in the identities used by SPF and have that domain's SPF record authorize the sending host, and yet the message can easily list other identities in its header. Unless the user or the MUA takes care to note that the authorized identity does not match the other more commonly presented identities (such as the From: header field), the user might be lulled into a false sense of security.
“邮件发件人”和“直升机”身份授权不保证邮件中使用的其他身份的授权/真实性。恶意发件人完全有可能使用自己的域在SPF使用的标识中插入消息，并让该域的SPF记录授权发送主机，但该消息可以很容易地在其标头中列出其他标识。除非用户或MUA注意到授权身份与其他更常见的身份（如From:header字段）不匹配，否则用户可能会误以为安全。
There are two aspects of this protocol that malicious parties could exploit to undermine the validity of the check_host() function:
恶意方可以利用此协议的两个方面来破坏check_host（）函数的有效性：
o The evaluation of check_host() relies heavily on DNS. A malicious attacker could attack the DNS infrastructure and cause check_host() to see spoofed DNS data, and then return incorrect results. This could include returning "pass" for an <ip> value where the actual domain's record would evaluate to "fail". See [RFC3833] for a description of DNS weaknesses, and see [RFC4033] for a countermeasure.
o check_host（）的计算在很大程度上依赖于DNS。恶意攻击者可以攻击DNS基础结构，并导致check_host（）看到伪造的DNS数据，然后返回不正确的结果。这可能包括返回<ip>值的“pass”，实际域的记录将评估为“fail”。有关DNS弱点的说明，请参见[RFC3833]，对策请参见[RFC4033]。
o The client IP address, <ip>, is assumed to be correct. In a modern, correctly configured system, the risk of this not being true is nil.
o 假定客户端IP地址<IP>，是正确的。在现代的、配置正确的系统中，不正确的风险为零。
By definition, SPF policies just map domain names to sets of authorized MTAs, not whole email addresses to sets of authorized users. Although the "l" macro (Section 7) provides a limited way to define individual sets of authorized MTAs for specific email addresses, it is generally impossible to verify, through SPF, the use of specific email addresses by individual users of the same MTA.
根据定义，SPF策略只是将域名映射到授权MTA集，而不是将整个电子邮件地址映射到授权用户集。虽然“l”宏（第7节）提供了一种有限的方法来定义特定电子邮件地址的授权MTA的各个集合，但通常无法通过SPF验证同一MTA的各个用户使用特定电子邮件地址的情况。
It is up to mail services and their MTAs to directly prevent cross-user forgery: based on SMTP AUTH ([RFC4954]), users have to be restricted to using only those email addresses that are actually under their control (see Section 6.1 of [RFC6409]). Another means to verify the identity of individual users is message cryptography, such as Pretty Good Privacy (PGP) ([RFC4880]) or S/MIME ([RFC5751]).
由邮件服务及其MTA直接防止跨用户伪造：基于SMTP身份验证（[RFC4954]），必须限制用户仅使用其实际控制的电子邮件地址（请参见[RFC6409]第6.1节）。验证单个用户身份的另一种方法是消息加密，例如相当好的隐私（PGP）（[RFC4880]）或S/MIME（[RFC5751]）。
An SPF-compliant receiver gathers information from the SMTP commands it receives and from the published DNS records of the sending domain holder (e.g., "HELO" domain name, the "MAIL FROM" address from the envelope, and SPF DNS records published by the domain holder). These parameters are not validated in the SMTP process.
符合SPF的接收方从其接收的SMTP命令以及发送域持有者发布的DNS记录（例如，“HELO”域名、“邮件发件人”地址以及域持有者发布的SPF DNS记录）收集信息。SMTP进程中未验证这些参数。
All of these pieces of information are generated by actors outside of the authority of the receiver, and thus are not guaranteed to be accurate or legitimate.
所有这些信息都是由接收者权限之外的参与者生成的，因此不能保证其准确性或合法性。
This information, passed to the receiver in the Received-SPF: or Authentication-Results: trace fields, can be returned to the client MTA as an SMTP rejection message. If such an SMTP rejection message is generated, the information from the trace fields has to be checked for such problems as invalid characters and excessively long lines.
此信息在接收到的SPF:或Authentication Results:跟踪字段中传递给接收方，可以作为SMTP拒绝消息返回给客户端MTA。如果生成了此类SMTP拒绝消息，则必须检查跟踪字段中的信息是否存在无效字符和过长行等问题。
When the authorization check fails, an explanation string could be included in the reject response. Both the sender and the rejecting receiver need to be aware that the explanation was determined by the publisher of the SPF record checked and, in general, not the receiver. The explanation can contain malicious URLs, or it might be offensive or misleading.
当授权检查失败时，可以在拒绝响应中包含解释字符串。发送方和拒绝接收方都需要知道，解释是由SPF记录的发布方确定的，而通常不是接收方。解释可能包含恶意URL，也可能具有攻击性或误导性。
Explanations returned to sender domains due to "exp" modifiers (Section 6.2) were generated by the sender policy published by the domain holders themselves. As long as messages are only returned with non-delivery notifications ([RFC3464]) to domains publishing the explanation strings from their own DNS SPF records, the only affected parties are the original publishers of the domain's SPF records.
由于“exp”修饰符（第6.2节）返回给发件人域的解释是由域持有人自己发布的发件人策略生成的。只要邮件仅返回未送达通知（[RFC3464]）给从其自身DNS SPF记录发布解释字符串的域，则唯一受影响的方是域SPF记录的原始发布者。
In practice, such non-delivery notifications can be misdirected, such as when an MTA accepts an email and only later generates the notification to a forged address, or when an email forwarder does not direct the bounce back to the original sender.
在实践中，此类未送达通知可能会被误导，例如MTA接受电子邮件后才将通知发送到伪造地址，或者电子邮件转发器未将回退指示给原始发件人。
Macros (Section 7) allow senders to inject arbitrary text (any non-null [US-ASCII] character) into receiver DNS queries. It is necessary to be prepared for hostile or unexpected content.
宏（第7节）允许发送方将任意文本（任何非空[US-ASCII]字符）注入接收方DNS查询。有必要为敌对或意外内容做好准备。
Checking SPF records causes DNS queries to be sent to the domain owner. These DNS queries, especially if they are caused by the "exists" mechanism, can contain information about who is sending email and likely to which MTA the email is being sent. This can introduce some privacy concerns, which are more or less of an issue depending on local laws and the relationship between the ADMD and the person sending the email.
检查SPF记录会导致将DNS查询发送给域所有者。这些DNS查询，尤其是由“存在”机制引起的查询，可以包含有关谁在发送电子邮件以及可能将电子邮件发送到哪个MTA的信息。这可能会带来一些隐私问题，这些问题或多或少取决于当地法律以及ADMD和发送电子邮件的人之间的关系。
Operators that choose to deliver mail for which SPF produces a "fail" result need to understand that they are admitting content that is explicitly not authorized by the purported sender. While there are known failure modes that can be considered "false negatives", the distinct choice to admit those messages increases end-user exposure to likely harm. This is especially true for domains belonging to known good actors that are typically well-behaved; unauthorized mail from those sources might well be subjected to much higher skepticism and content analysis.
选择发送SPF产生“失败”结果的邮件的运营商需要了解，他们接受的内容明显未经声称的发件人授权。虽然存在可被视为“假阴性”的已知故障模式，但承认这些消息的独特选择增加了最终用户可能受到的伤害。这对于属于已知良好参与者的领域尤其如此，这些参与者通常表现良好；来自这些来源的未经授权的邮件可能会受到更高程度的怀疑和内容分析。
SPF does not, however, include the capacity to distinguish good actors from bad ones, nor does it handle the concept of known actors versus unknown ones. Those notions are out of scope for this specification.
然而，SPF不包括区分好演员和坏演员的能力，也不处理已知演员和未知演员的概念。这些概念超出了本规范的范围。
This section is normative, and any discrepancies with the ABNF fragments in the preceding text are to be resolved in favor of this grammar.
本节是规范性的，与前面文本中ABNF片段的任何差异都应按照本语法解决。
See [RFC5234] for ABNF notation. Please note that as per this ABNF definition, literal text strings (those in quotes) are case-insensitive. Hence, "mx" matches "mx", "MX", "mX", and "Mx".
ABNF符号见[RFC5234]。请注意，根据ABNF的定义，文本字符串（引号中的字符串）不区分大小写。因此，“mx”与“mx”、“mx”、“mx”和“mx”匹配。
record = version terms *SP
version = "v=spf1"
record = version terms *SP
version = "v=spf1"
terms = *( 1*SP ( directive / modifier ) )
terms = *( 1*SP ( directive / modifier ) )
directive = [ qualifier ] mechanism
qualifier = "+" / "-" / "?" / "~"
mechanism = ( all / include
/ a / mx / ptr / ip4 / ip6 / exists )
directive = [ qualifier ] mechanism
qualifier = "+" / "-" / "?" / "~"
mechanism = ( all / include
/ a / mx / ptr / ip4 / ip6 / exists )
all = "all"
include = "include" ":" domain-spec
a = "a" [ ":" domain-spec ] [ dual-cidr-length ]
mx = "mx" [ ":" domain-spec ] [ dual-cidr-length ]
ptr = "ptr" [ ":" domain-spec ]
ip4 = "ip4" ":" ip4-network [ ip4-cidr-length ]
ip6 = "ip6" ":" ip6-network [ ip6-cidr-length ]
exists = "exists" ":" domain-spec
all = "all"
include = "include" ":" domain-spec
a = "a" [ ":" domain-spec ] [ dual-cidr-length ]
mx = "mx" [ ":" domain-spec ] [ dual-cidr-length ]
ptr = "ptr" [ ":" domain-spec ]
ip4 = "ip4" ":" ip4-network [ ip4-cidr-length ]
ip6 = "ip6" ":" ip6-network [ ip6-cidr-length ]
exists = "exists" ":" domain-spec
modifier = redirect / explanation / unknown-modifier
redirect = "redirect" "=" domain-spec
explanation = "exp" "=" domain-spec
unknown-modifier = name "=" macro-string
; where name is not any known modifier
modifier = redirect / explanation / unknown-modifier
redirect = "redirect" "=" domain-spec
explanation = "exp" "=" domain-spec
unknown-modifier = name "=" macro-string
; where name is not any known modifier
ip4-cidr-length = "/" ("0" / %x31-39 0*1DIGIT) ; value range 0-32
ip6-cidr-length = "/" ("0" / %x31-39 0*2DIGIT) ; value range 0-128
dual-cidr-length = [ ip4-cidr-length ] [ "/" ip6-cidr-length ]
ip4-cidr-length = "/" ("0" / %x31-39 0*1DIGIT) ; value range 0-32
ip6-cidr-length = "/" ("0" / %x31-39 0*2DIGIT) ; value range 0-128
dual-cidr-length = [ ip4-cidr-length ] [ "/" ip6-cidr-length ]
ip4-network = qnum "." qnum "." qnum "." qnum
qnum = DIGIT ; 0-9
/ %x31-39 DIGIT ; 10-99
/ "1" 2DIGIT ; 100-199
/ "2" %x30-34 DIGIT ; 200-249
/ "25" %x30-35 ; 250-255
; conventional dotted-quad notation, e.g., 192.0.2.0
ip6-network = <as per Section 2.2 of [RFC4291]>
; e.g., 2001:db8::cd30
ip4-network = qnum "." qnum "." qnum "." qnum
qnum = DIGIT ; 0-9
/ %x31-39 DIGIT ; 10-99
/ "1" 2DIGIT ; 100-199
/ "2" %x30-34 DIGIT ; 200-249
/ "25" %x30-35 ; 250-255
; conventional dotted-quad notation, e.g., 192.0.2.0
ip6-network = <as per Section 2.2 of [RFC4291]>
; e.g., 2001:db8::cd30
domain-spec = macro-string domain-end
domain-end = ( "." toplabel [ "." ] ) / macro-expand
domain-spec = macro-string domain-end
domain-end = ( "." toplabel [ "." ] ) / macro-expand
toplabel = ( *alphanum ALPHA *alphanum ) /
( 1*alphanum "-" *( alphanum / "-" ) alphanum )
; LDH rule plus additional TLD restrictions
; (see Section 2 of [RFC3696] for background)
alphanum = ALPHA / DIGIT
toplabel = ( *alphanum ALPHA *alphanum ) /
( 1*alphanum "-" *( alphanum / "-" ) alphanum )
; LDH rule plus additional TLD restrictions
; (see Section 2 of [RFC3696] for background)
alphanum = ALPHA / DIGIT
explain-string = *( macro-string / SP )
explain-string = *( macro-string / SP )
macro-string = *( macro-expand / macro-literal )
macro-expand = ( "%{" macro-letter transformers *delimiter "}" )
/ "%%" / "%_" / "%-"
macro-string = *( macro-expand / macro-literal )
macro-expand = ( "%{" macro-letter transformers *delimiter "}" )
/ "%%" / "%_" / "%-"
macro-literal = %x21-24 / %x26-7E
; visible characters except "%"
macro-letter = "s" / "l" / "o" / "d" / "i" / "p" / "h" /
"c" / "r" / "t" / "v"
transformers = *DIGIT [ "r" ]
delimiter = "." / "-" / "+" / "," / "/" / "_" / "="
macro-literal = %x21-24 / %x26-7E
; visible characters except "%"
macro-letter = "s" / "l" / "o" / "d" / "i" / "p" / "h" /
"c" / "r" / "t" / "v"
transformers = *DIGIT [ "r" ]
delimiter = "." / "-" / "+" / "," / "/" / "_" / "="
name = ALPHA *( ALPHA / DIGIT / "-" / "_" / "." )
name = ALPHA *( ALPHA / DIGIT / "-" / "_" / "." )
header-field = "Received-SPF:" [CFWS] result FWS [comment FWS] [ key-value-list ] CRLF
header field=“Received SPF:[CFWS]结果FWS[注释FWS][键值列表]CRLF
result = "pass" / "fail" / "softfail" / "neutral" /
"none" / "temperror" / "permerror"
result = "pass" / "fail" / "softfail" / "neutral" /
"none" / "temperror" / "permerror"
key-value-list = key-value-pair *( ";" [CFWS] key-value-pair )
[";"]
key-value-list = key-value-pair *( ";" [CFWS] key-value-pair )
[";"]
key-value-pair = key [CFWS] "=" ( dot-atom / quoted-string )
key-value-pair = key [CFWS] "=" ( dot-atom / quoted-string )
key = "client-ip" / "envelope-from" / "helo" /
"problem" / "receiver" / "identity" /
"mechanism" / name
key = "client-ip" / "envelope-from" / "helo" /
"problem" / "receiver" / "identity" /
"mechanism" / name
identity = "mailfrom" ; for the "MAIL FROM" identity
/ "helo" ; for the "HELO" identity
/ name ; other identities
identity = "mailfrom" ; for the "MAIL FROM" identity
/ "helo" ; for the "HELO" identity
/ name ; other identities
sender = Mailbox
ip = ip4-network / ip6-network
ALPHA = <A-Z / a-z as per [RFC5234]>
DIGIT = <0-9 as per [RFC5234]>
SP = <space character as per [RFC5234]>
dot-atom = <unquoted word as per [RFC5322]>
quoted-string = <quoted string as per [RFC5322]>
comment = <comment string as per [RFC5322]>
CFWS = <comment or folding white space as per [RFC5322]>
FWS = <folding white space as per [RFC5322]>
CRLF = <standard end-of-line token as per [RFC5322]>
sender = Mailbox
ip = ip4-network / ip6-network
ALPHA = <A-Z / a-z as per [RFC5234]>
DIGIT = <0-9 as per [RFC5234]>
SP = <space character as per [RFC5234]>
dot-atom = <unquoted word as per [RFC5322]>
quoted-string = <quoted string as per [RFC5322]>
comment = <comment string as per [RFC5322]>
CFWS = <comment or folding white space as per [RFC5322]>
FWS = <folding white space as per [RFC5322]>
CRLF = <standard end-of-line token as per [RFC5322]>
This document is largely based on the work of Meng Weng Wong, Mark Lentczner, and Wayne Schlitt. Although, as this section acknowledges, many people have contributed to this document, a very large portion of the writing and editing is due to Meng, Mark, and Wayne.
本文件主要基于王孟翁、马克·伦茨纳和韦恩·施利特的工作。虽然，正如本节所承认的，许多人对本文档做出了贡献，但很大一部分的写作和编辑都是由孟、马克和韦恩完成的。
This design owes a debt of parentage to [RMX] by Hadmut Danisch and to [DMP] by Gordon Fecyk. The idea of using a DNS record to check the legitimacy of an email address traces its ancestry further back through messages on the namedroppers mailing list by Paul Vixie [Vixie] (based on suggestion by Jim Miller) and by David Green [Green].
这种设计归功于Hadmut Danisch的[RMX]和Gordon Fecyk的[DMP]。使用DNS记录检查电子邮件地址合法性的想法可以追溯到保罗·维克西（Paul Vixie）[Vixie]（根据吉姆·米勒的建议）和大卫·格林（David Green）[Green]在匿名投递者邮件列表上的消息。
Philip Gladstone contributed the concept of macros to the specification, multiplying the expressiveness of the language and making per-user and per-IP lookups possible.
Philip Gladstone在规范中提出了宏的概念，增加了语言的表达能力，并使每用户和每IP查找成为可能。
The authors of both this document and [RFC4408] would also like to thank the literally hundreds of individuals who have participated in the development of this design. They are far too numerous to name, but they include the following:
本文件和[RFC4408]的作者还想感谢参与本设计开发的数百名个人。它们的数量多得数不清，但它们包括以下内容：
The participants in the SPFbis working group. The folks on the spf-discuss mailing list. The folks on the SPAM-L mailing list. The folks on the IRTF ASRG mailing list. The folks on the IETF MARID mailing list. The folks on #perl.
SPFbis工作组的参与者。spf上的人讨论邮件列表。垃圾邮件列表上的人。IRTF ASRG邮件列表上的人。IETF MARID邮件列表上的人。perl上的人。
Per [RFC4408], the IANA assigned the Resource Record Type and Qtype from the "Domain Name System (DNS) Parameters" registry for the SPF RR type with code 99. The format of this type is identical to the TXT RR [RFC1035]. The character content of the record is encoded as [US-ASCII].
根据[RFC4408]，IANA从“域名系统（DNS）参数”注册表为SPF RR类型分配了资源记录类型和Qtype，代码为99。此类型的格式与TXT RR[RFC1035]相同。记录的字符内容编码为[US-ASCII]。
Studies have shown that RRTYPE 99 has not seen any substantial use, and in fact its existence and mechanism defined in [RFC4408] have led to some interoperability issues. Accordingly, its use is no longer appropriate for SPF version 1; implementations are not to use it.
研究表明，RRTYPE 99没有任何实质性的用途，事实上，[RFC4408]中定义的RRTYPE的存在和机制导致了一些互操作性问题。因此，其使用不再适用于SPF版本1；实现不需要使用它。
IANA has updated the "Resource Record (RR) TYPEs" registry to indicate that this document is the reference document for that RRTYPE.
IANA已更新“资源记录（RR）类型”注册表，以表明此文档是该RRTYPE的参考文档。
Per [RFC3864], the "Received-SPF:" header field is added to the IANA "Permanent Message Header Field Names" registry. The following is the registration template:
根据[RFC3864]，将“接收到的SPF:”标头字段添加到IANA“永久消息标头字段名称”注册表中。以下是注册模板：
Header field name: Received-SPF Applicable protocol: mail
([RFC5322]) Status: standard Author/Change controller: IETF
Specification document(s): RFC 7208
Header field name: Received-SPF Applicable protocol: mail
([RFC5322]) Status: standard Author/Change controller: IETF
Specification document(s): RFC 7208
IANA has changed the reference for the "exp" and "redirect" modifiers in the "Modifier Names" registry, under Sender Policy Framework Parameters, from [RFC4408] to this document. Their status is unchanged.
IANA已将发件人策略框架参数下“修改器名称”注册表中“exp”和“redirect”修改器的引用从[RFC4408]更改为本文档。他们的地位没有改变。
[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.
[RFC1035]Mockapetris，P.，“域名-实现和规范”，STD 13，RFC 1035，1987年11月。
[RFC1123] Braden, R., "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, October 1989.
[RFC1123]Braden，R.，“互联网主机的要求-应用和支持”，STD 3，RFC 1123，1989年10月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC3463] Vaudreuil, G., "Enhanced Mail System Status Codes", RFC 3463, January 2003.
[RFC3463]Vaudreuil，G.，“增强邮件系统状态代码”，RFC 3463，2003年1月。
[RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration Procedures for Message Header Fields", BCP 90, RFC 3864, September 2004.
[RFC3864]Klyne，G.，Nottingham，M.和J.Mogul，“消息头字段的注册程序”，BCP 90，RFC 3864，2004年9月。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[RFC3986]Berners Lee，T.，Fielding，R.，和L.Masinter，“统一资源标识符（URI）：通用语法”，STD 66，RFC 3986，2005年1月。
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006.
[RFC4291]Hinden，R.和S.Deering，“IP版本6寻址体系结构”，RFC 42912006年2月。
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5234]Crocker，D.和P.Overell，“语法规范的扩充BNF:ABNF”，STD 68，RFC 5234，2008年1月。
[RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, October 2008.
[RFC5321]Klensin，J.，“简单邮件传输协议”，RFC 53212008年10月。
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, October 2008.
[RFC5322]Resnick，P.，Ed.“互联网信息格式”，RFC5222008年10月。
[RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, July 2009.
[RFC5598]Crocker，D.，“互联网邮件体系结构”，RFC5598，2009年7月。
[RFC5890] Klensin, J., "Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework", RFC 5890, August 2010.
[RFC5890]Klensin，J.，“应用程序的国际化域名（IDNA）：定义和文档框架”，RFC 58902010年8月。
[RFC7001] Kucherawy, M., "Message Header Field for Indicating Message Authentication Status", RFC 7001, September 2013.
[RFC7001]Kucherawy，M.，“用于指示消息身份验证状态的消息头字段”，RFC 70012013年9月。
[US-ASCII] American National Standards Institute (formerly United States of America Standards Institute), "USA Code for Information Interchange, X3.4", 1968.
[US-ASCII]美国国家标准协会（前美国标准协会），“美国信息交换代码，X3.4”，1968年。
ANSI X3.4-1968 has been replaced by newer versions with slight modifications, but the 1968 version remains definitive for the Internet.
ANSI X3.4-1968已被稍作修改的较新版本所取代，但1968年版本仍然是互联网的最终版本。
[BATV] Levine, J., Crocker, D., Silberman, S., and T. Finch, "Bounce Address Tag Validation (BATV)", Work in Progress, May 2008.
[BATV]Levine，J.，Crocker，D.，Silberman，S.，和T.Finch，“跳出地址标签验证（BATV）”，正在进行的工作，2008年5月。
[DMP] Fecyk, G., "Designated Mailers Protocol", Work in Progress, May 2004.
[DMP]Fecyk，G.，“指定邮递员协议”，正在进行的工作，2004年5月。
[Green] Green, D., "Domain-Authorized SMTP Mail", June 2002, <http://www.mhonarc.org/archive/html/ietf-asrg/2003-03/ msg01525.html>.
[Green]Green，D.，“域授权SMTP邮件”，2002年6月<http://www.mhonarc.org/archive/html/ietf-asrg/2003-03/ msg01525.html>。
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.
[RFC1034]Mockapetris，P.，“域名-概念和设施”，STD 13，RFC 1034，1987年11月。
[RFC1983] Malkin, G., "Internet Users' Glossary", RFC 1983, August 1996.
[RFC1983]Malkin，G.，“互联网用户词汇表”，RFC 1983，1996年8月。
[RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)", RFC 2308, March 1998.
[RFC2308]Andrews，M.，“DNS查询的反向缓存（DNS NCACHE）”，RFC 2308，1998年3月。
[RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671, August 1999.
[RFC2671]Vixie，P.，“DNS的扩展机制（EDNS0）”，RFC 26711999年8月。
[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000.
[RFC2782]Gulbrandsen，A.，Vixie，P.和L.Esibov，“用于指定服务位置（DNS SRV）的DNS RR”，RFC 2782，2000年2月。
[RFC3464] Moore, K. and G. Vaudreuil, "An Extensible Message Format for Delivery Status Notifications", RFC 3464, January 2003.
[RFC3464]Moore，K.和G.Vaudreuil，“交付状态通知的可扩展消息格式”，RFC 3464，2003年1月。
[RFC3696] Klensin, J., "Application Techniques for Checking and Transformation of Names", RFC 3696, February 2004.
[RFC3696]Klensin，J.，“名称检查和转换的应用技术”，RFC 36962004年2月。
[RFC3833] Atkins, D. and R. Austein, "Threat Analysis of the Domain Name System (DNS)", RFC 3833, August 2004.
[RFC3833]Atkins，D.和R.Austein，“域名系统（DNS）的威胁分析”，RFC 38332004年8月。
[RFC3834] Moore, K., "Recommendations for Automatic Responses to Electronic Mail", RFC 3834, August 2004.
[RFC3834]Moore，K.，“自动回复电子邮件的建议”，RFC 38342004年8月。
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005.
[RFC4033]Arends，R.，Austein，R.，Larson，M.，Massey，D.，和S.Rose，“DNS安全介绍和要求”，RFC 4033，2005年3月。
[RFC4408] Wong, M. and W. Schlitt, "Sender Policy Framework (SPF) for Authorizing Use of Domains in E-Mail, Version 1", RFC 4408, April 2006.
[RFC4408]Wong，M.和W.Schlitt，“授权在电子邮件中使用域的发件人策略框架（SPF），第1版”，RFC 4408，2006年4月。
[RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan", BCP 122, RFC 4632, August 2006.
[RFC4632]Fuller，V.和T.Li，“无类域间路由（CIDR）：互联网地址分配和聚合计划”，BCP 122，RFC 4632，2006年8月。
[RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. Thayer, "OpenPGP Message Format", RFC 4880, November 2007.
[RFC4880]Callas，J.，Donnerhacke，L.，Finney，H.，Shaw，D.，和R.Thayer，“OpenPGP消息格式”，RFC 48802007年11月。
[RFC4954] Siemborski, R. and A. Melnikov, "SMTP Service Extension for Authentication", RFC 4954, July 2007.
[RFC4954]Siemborski，R.和A.Melnikov，“用于身份验证的SMTP服务扩展”，RFC 49542007年7月。
[RFC5507] IAB, Faltstrom, P., Austein, R., and P. Koch, "Design Choices When Expanding the DNS", RFC 5507, April 2009.
[RFC5507]IAB，Faltstrom，P.，Austein，R.，和P.Koch，“扩展DNS时的设计选择”，RFC 5507，2009年4月。
[RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification", RFC 5751, January 2010.
[RFC5751]Ramsdell，B.和S.Turner，“安全/多用途Internet邮件扩展（S/MIME）版本3.2消息规范”，RFC 57512010年1月。
[RFC5782] Levine, J., "DNS Blacklists and Whitelists", RFC 5782, February 2010.
[RFC5782]Levine，J.，“DNS黑名单和白名单”，RFC 5782，2010年2月。
[RFC6409] Gellens, R. and J. Klensin, "Message Submission for Mail", STD 72, RFC 6409, November 2011.
[RFC6409]Gellens，R.和J.Klensin，“邮件信息提交”，STD 72，RFC 6409，2011年11月。
[RFC6647] Kucherawy, M. and D. Crocker, "Email Greylisting: An Applicability Statement for SMTP", RFC 6647, June 2012.
[RFC6647]Kucherawy，M.和D.Crocker，“电子邮件灰色列表：SMTP的适用性声明”，RFC 6647，2012年6月。
[RFC6648] Saint-Andre, P., Crocker, D., and M. Nottingham, "Deprecating the "X-" Prefix and Similar Constructs in Application Protocols", BCP 178, RFC 6648, June 2012.
[RFC6648]圣安德烈，P.，克罗克，D.，和M.诺丁汉，“反对应用协议中的“X-”前缀和类似结构”，BCP 178，RFC 6648，2012年6月。
[RFC6652] Kitterman, S., "Sender Policy Framework (SPF) Authentication Failure Reporting Using the Abuse Reporting Format", RFC 6652, June 2012.
[RFC6652]Kitterman，S.，“使用滥用报告格式的发送方策略框架（SPF）身份验证失败报告”，RFC 66522012年6月。
[RFC6686] Kucherawy, M., "Resolution of the Sender Policy Framework (SPF) and Sender ID Experiments", RFC 6686, July 2012.
[RFC6686]Kucherawy，M.，“发送方策略框架（SPF）的解析和发送方ID实验”，RFC 6686，2012年7月。
[RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms for DNS (EDNS(0))", STD 75, RFC 6891, April 2013.
[RFC6891]Damas，J.，Graff，M.，和P.Vixie，“DNS（EDNS（0））的扩展机制”，STD 75，RFC 6891，2013年4月。
[RMX] Danisch, H., "The RMX DNS RR and method for lightweight SMTP sender authorization", Work in Progress, May 2004.
[RMX]Danisch，H.，“RMX DNS RR和轻量级SMTP发件人授权方法”，正在进行的工作，2004年5月。
[Vixie] Vixie, P., "Repudiating MAIL FROM", 2002, <http://marc.info/?l=namedroppers&m=102298170127004&w=4>.
[Vixie]Vixie，P.，“拒绝来自的邮件”，2002年<http://marc.info/?l=namedroppers&m=102298170127004&w=4>.
These examples are based on the following DNS setup:
这些示例基于以下DNS设置：
; A domain with two mail servers, two hosts, and two servers ; at the domain name $ORIGIN example.com. @ MX 10 mail-a MX 20 mail-b A 192.0.2.10 A 192.0.2.11 amy A 192.0.2.65 bob A 192.0.2.66 mail-a A 192.0.2.129 mail-b A 192.0.2.130 www CNAME example.com.
; 具有两台邮件服务器、两台主机和两台服务器的域；在域名$ORIGIN example.com@MX 10 mail-a MX 20 mail-b a 192.0.2.10 a 192.0.2.11 amy a 192.0.2.65 bob a 192.0.2.66 mail-a 192.0.2.129 mail-b a 192.0.2.130 www.CNAME example.com。
; A related domain $ORIGIN example.org. @ MX 10 mail-c mail-c A 192.0.2.140
; 相关域$ORIGIN example.org@MX 10 mail-c mail-c A 192.0.2.140
; The reverse IP for those addresses $ORIGIN 2.0.192.in-addr.arpa. 10 PTR example.com. 11 PTR example.com. 65 PTR amy.example.com. 66 PTR bob.example.com. 129 PTR mail-a.example.com. 130 PTR mail-b.example.com. 140 PTR mail-c.example.org.
; 这些地址的反向IP为$ORIGIN 2.0.192.in-addr.arpa。10 PTR example.com。11 PTR example.com。65 PTR amy.example.com。66 PTR bob.example.com。129 PTR mail-a.example.com。130 PTR mail-b.example.com。140 PTR mail-c.example.org。
; A rogue reverse IP domain that claims to be ; something it's not $ORIGIN 0.0.10.in-addr.arpa. 4 PTR bob.example.com.
; 声称是非法的反向IP域；它不是$ORIGIN 0.0.10.in-addr.arpa。4 PTR bob.example.com。
These examples show various possible published records for example.com and which values of <ip> would cause check_host() to return "pass". Note that <domain> is "example.com".
这些示例显示了example.com等各种可能的已发布记录，<ip>的哪些值将导致check_host（）返回“pass”。注意，<domain>是“example.com”。
v=spf1 +all
v=spf1+all
-- any <ip> passes
--任何<ip>通过
v=spf1 a -all
v=spf1 a-所有
-- hosts 192.0.2.10 and 192.0.2.11 pass
--主机192.0.2.10和192.0.2.11通过
v=spf1 a:example.org -all
v=spf1 a:example.org -all
-- no sending hosts pass since example.org has no A records
--没有发送主机通过，因为example.org没有A记录
v=spf1 mx -all
v=spf1 mx-全部
-- sending hosts 192.0.2.129 and 192.0.2.130 pass
--发送主机192.0.2.129和192.0.2.130通过
v=spf1 mx:example.org -all
v=spf1 mx:example.org -all
-- sending host 192.0.2.140 passes
--发送主机192.0.2.140通过
v=spf1 mx mx:example.org -all
v=spf1 mx mx:example.org -all
-- sending hosts 192.0.2.129, 192.0.2.130, and 192.0.2.140 pass
--发送主机192.0.2.129、192.0.2.130和192.0.2.140通过
v=spf1 mx/30 mx:example.org/30 -all
v=spf1 mx/30 mx:example.org/30 -all
-- any sending host in 192.0.2.128/30 or 192.0.2.140/30 passes
--192.0.2.128/30或192.0.2.140/30中的任何发送主机通过
v=spf1 ptr -all
v=spf1 ptr-所有
-- sending host 192.0.2.65 passes (reverse DNS is valid and is in example.com)
--发送主机192.0.2.65通过（反向DNS有效，在example.com中）
-- sending host 192.0.2.140 fails (reverse DNS is valid, but not in example.com)
--发送主机192.0.2.140失败（反向DNS有效，但不在example.com中）
-- sending host 10.0.0.4 fails (reverse IP is not valid)
--发送主机10.0.0.4失败（反向IP无效）
v=spf1 ip4:192.0.2.128/28 -all
v=spf1 ip4:192.0.2.128/28 -all
-- sending host 192.0.2.65 fails
--发送主机192.0.2.65失败
-- sending host 192.0.2.129 passes
--发送主机192.0.2.129通过
These examples show the effect of related records:
这些示例显示了相关记录的效果：
example.org: "v=spf1 include:example.com include:example.net -all"
example.org: "v=spf1 include:example.com include:example.net -all"
This record would be used if mail from example.org actually came through servers at example.com and example.net. Example.org's designated servers are the union of example.com's and example.net's designated servers.
如果来自example.org的邮件实际上是通过example.com和example.net上的服务器发送的，则将使用此记录。org的指定服务器是Example.com和Example.net的指定服务器的联合体。
la.example.org: "v=spf1 redirect=example.org"
la.example.org: "v=spf1 redirect=example.org"
ny.example.org: "v=spf1 redirect=example.org"
ny.example.org: "v=spf1 redirect=example.org"
sf.example.org: "v=spf1 redirect=example.org"
sf.example.org: "v=spf1 redirect=example.org"
These records allow a set of domains that all use the same mail system to make use of that mail system's record. In this way, only the mail system's record needs to be updated when the mail setup changes. These domains' records never have to change.
这些记录允许使用同一邮件系统的一组域使用该邮件系统的记录。这样，当邮件设置更改时，只需要更新邮件系统的记录。这些域的记录永远不必更改。
Imagine that, in addition to the domain records listed above, there are these (see [RFC5782]):
想象一下，除了上面列出的域记录之外，还有以下记录（请参见[RFC5782]）：
$ORIGIN _spf.example.com. mary.mobile-users A 127.0.0.2 fred.mobile-users A 127.0.0.2 15.15.168.192.joel.remote-users A 127.0.0.2 16.15.168.192.joel.remote-users A 127.0.0.2
$ORIGIN\u spf.example.com。mary.mobile-users A 127.0.0.2 fred.mobile-users A 127.0.0.2 15.15.168.192.joel.remote-users A 127.0.0.2 16.15.168.192.joel.remote-users A 127.0.0.2
The following records describe users at example.com who mail from arbitrary servers, or who mail from personal servers.
以下记录描述了example.com上从任意服务器发送邮件或从个人服务器发送邮件的用户。
example.com:
example.com：
v=spf1 mx
include:mobile-users._spf.%{d}
include:remote-users._spf.%{d}
-all
v=spf1 mx
include:mobile-users._spf.%{d}
include:remote-users._spf.%{d}
-all
mobile-users._spf.example.com:
移动用户。\u spf.example.com：
v=spf1 exists:%{l1r+}.%{d}
v=spf1 exists:%{l1r+}.%{d}
remote-users._spf.example.com:
远程用户。\u spf.example.com：
v=spf1 exists:%{ir}.%{l1r+}.%{d}
v=spf1 exists:%{ir}.%{l1r+}.%{d}
Say that your sender policy requires both that the IP address is within a certain range and that the reverse DNS for the IP matches. This can be done several ways, including the following:
假设您的发件人策略要求IP地址在特定范围内，并且IP的反向DNS匹配。这可以通过以下几种方式实现：
example.com. SPF ( "v=spf1 "
"-include:ip4._spf.%{d} "
"-include:ptr._spf.%{d} "
"+all" )
ip4._spf.example.com. SPF "v=spf1 -ip4:192.0.2.0/24 +all"
ptr._spf.example.com. SPF "v=spf1 -ptr +all"
example.com. SPF ( "v=spf1 "
"-include:ip4._spf.%{d} "
"-include:ptr._spf.%{d} "
"+all" )
ip4._spf.example.com. SPF "v=spf1 -ip4:192.0.2.0/24 +all"
ptr._spf.example.com. SPF "v=spf1 -ptr +all"
This example shows how the "-include" mechanism can be useful, how an SPF record that ends in "+all" can be very restrictive, and the use of De Morgan's Law.
这个例子展示了“-include”机制是如何有用的，以“+all”结尾的SPF记录是如何限制的，以及如何使用De Morgan定律。
The modifications to implementation requirements from [RFC4408] are all either (a) corrections to errors in [RFC4408] or (b) additional documentation based on consensus of operational experience acquired since the publication of [RFC4408].
[RFC4408]中对实施要求的修改全部是（a）对[RFC4408]中错误的更正，或（b）基于自[RFC4408]发布以来获得的运行经验共识的附加文件。
o Use of DNS RR type SPF (99) has been removed from the protocol; see [RFC6686] for background.
o 已从协议中删除DNS RR类型SPF（99）的使用；有关背景信息，请参见[RFC6686]。
o A new DNS-related processing limit based on "void lookups" has been added (Section 4.6.4).
o 增加了基于“无效查找”的新DNS相关处理限制（第4.6.4节）。
o Use of the ptr mechanism and the %p macro has been strongly discouraged (Sections 5.5 and 7.2). The ptr mechanism and the %p macro remain part of the protocol because they were found to be in use, but records ought to be updated to avoid them.
o 强烈反对使用ptr机制和%p宏（第5.5节和第7.2节）。ptr机制和%p宏仍然是协议的一部分，因为发现它们正在使用，但应更新记录以避免它们。
o Use of the "Authentication-Results" header field [RFC7001] as a possible alternative to use of the "Received-SPF" header field is discussed (Section 9.2).
o 讨论了使用“认证结果”标题字段[RFC7001]作为使用“接收到的SPF”标题字段的可能替代方法（第9.2节）。
o There have been a number of minor corrections to the ABNF to make it more clear and correct (Section 12). SPF library implementers should give the revised ABNF a careful review to determine if implementation changes are needed.
o 对ABNF进行了一些小的修改，以使其更加清晰和正确（第12节）。SPF库实施者应仔细审查修订后的ABNF，以确定是否需要对实施进行更改。
o Use of X- fields in the ABNF has been removed; see [RFC6648] for background.
o ABNF中X字段的使用已被删除；有关背景信息，请参见[RFC6648]。
o Ambiguity about how to deal with invalid <domain-spec> after macro expansion has been documented. Depending on one specific behavior has to be avoided (Section 4.8).
o 宏扩展后如何处理无效的<domain spec>的模糊性已被记录。根据具体情况，必须避免一种特定行为（第4.8节）。
o General operational information has been updated and expanded based on eight years of post-[RFC4408] operations experience. See Section 10 and Appendices D through G below.
o 基于八年的[RFC4408]后作战经验，通用作战信息已得到更新和扩展。见下文第10节和附录D至G。
o Security considerations have been reviewed and updated (Section 11).
o 已审查并更新了安全注意事项（第11节）。
Another approach that can be helpful is to publish records that include a "tracking exists:" mechanism. By looking at the name server logs, a rough list can then be generated. For example:
另一种有用的方法是发布包含“跟踪存在：”机制的记录。通过查看名称服务器日志，可以生成一个粗略的列表。例如：
v=spf1 exists:_h.%{h}._l.%{l}._o.%{o}._i.%{i}._spf.%{d} ?all
v=spf1 exists:_h.%{h}._l.%{l}._o.%{o}._i.%{i}._spf.%{d} ?all
This associated macro expansion would cause the sending HELO domain, local-part of the sending email address, domain part of the sending email address, and the IP address from which the connection was received to be embedded in an SPF query and logged in the sender's DNS logs.
此关联的宏扩展将导致发送HELO域、发送电子邮件地址的本地部分、发送电子邮件地址的域部分以及接收连接的IP地址嵌入到SPF查询中，并记录在发送方的DNS日志中。
This approach, which has been used since very early in the SPF project, allows senders to unilaterally collect data to evaluate the correctness of their SPF records. Unlike newer feedback mechanisms, it does not require any special cooperation from SPF verifiers. A similar example, one of the earliest SPF records published, can still be found as of this writing at altavista.net.
这种方法从SPF项目的早期就开始使用，允许发送方单方面收集数据，以评估其SPF记录的正确性。与较新的反馈机制不同，它不需要SPF验证者的任何特殊合作。类似的例子，最早发布的SPF记录之一，在撰写本文时仍可以在altavista.net上找到。
Appendix D. SPF/Mediator Interactions
附录D.SPF/调解人互动
There are three places that techniques can be used to ameliorate unintended SPF failures with mediators.
有三个地方可以使用技术来通过中介来改善意外的SPF故障。
The beginning, when email is first sent:
第一次发送电子邮件时的开头：
o "Neutral" results could be given for IP addresses that might be forwarders, instead of "fail" results based on a list of known reliable forwarders. For example:
o 对于可能是转发器的IP地址，可以给出“中性”结果，而不是基于已知可靠转发器列表的“失败”结果。例如：
"v=spf1 mx ?exists:%{ir}.whitelist.example.org -all"
"v=spf1 mx ?exists:%{ir}.whitelist.example.org -all"
This would cause a lookup on a DNS White List (DNSWL) and cause a result of "fail" only for email not coming from either the domain's mx host(s) (SPF pass) or whitelisted sources (SPF neutral). This, in effect, outsources an element of sender policy to the maintainer of the whitelist.
这将导致在DNS白名单（DNSWL）上进行查找，并导致仅针对不来自域mx主机（SPF pass）或白名单源（SPF neutral）的电子邮件的“失败”。实际上，这将发送者策略的一个元素外包给白名单的维护者。
o The "MAIL FROM" identity could have additional information in the local-part that cryptographically identifies the mail as coming from an authorized source. In this case, an SPF record such as the following could be used:
o “邮件发件人”标识可以在本地部分包含其他信息，以加密方式将邮件标识为来自授权来源。在这种情况下，可以使用以下SPF记录：
"v=spf1 mx exists:%{l}._spf_verify.%{d} -all"
"v=spf1 mx exists:%{l}._spf_verify.%{d} -all"
Then, a specialized DNS server can be set up to serve the _spf_verify subdomain that validates the local-part. Although this requires an extra DNS lookup, this happens only when the email would otherwise be rejected as not coming from a known good source.
然后，可以设置专门的DNS服务器来为验证本地部分的_spf_verify子域提供服务。尽管这需要额外的DNS查找，但只有当电子邮件因来源不明而被拒绝时，才会发生这种情况。
Note that due to the 63-character limit for domain labels, this approach only works reliably if the local-part signature scheme is guaranteed to either only produce local-parts with a maximum of 63 characters or gracefully handle truncated local-parts. The method used to secure the local-part is a local implementation issue; it need not be standard. An example of one way to do it can be found in [BATV].
注意，由于域标签有63个字符的限制，只有当本地部分签名方案保证只生成最多63个字符的本地部分或优雅地处理截断的本地部分时，这种方法才能可靠地工作。用于保护本地部分的方法是本地实现问题；它不必是标准的。在[BATV]中可以找到一个这样做的例子。
o Similarly, a specialized DNS server could be set up that will rate-limit the email coming from unexpected IP addresses.
o 类似地，可以设置专门的DNS服务器，对来自意外IP地址的电子邮件进行速率限制。
"v=spf1 mx exists:%{ir}._spf_rate.%{d} -all"
"v=spf1 mx exists:%{ir}._spf_rate.%{d} -all"
o SPF allows the creation of per-user policies for special cases. For example, the following SPF record and appropriate wildcard DNS records can be used:
o SPF允许为特殊情况创建每用户策略。例如，可以使用以下SPF记录和适当的通配符DNS记录：
"v=spf1 mx redirect=%{l1r+}._at_.%{o}._spf.%{d}"
"v=spf1 mx redirect=%{l1r+}._at_.%{o}._spf.%{d}"
The middle, when email is forwarded:
中间，转发电子邮件时：
o Mediators can solve the problem by rewriting the "MAIL FROM" to be in their own domain. This means mail rejected from the external mailbox will have to be forwarded back to the original sender by the forwarding service. Various schemes to do this exist, though they vary widely in complexity and resource requirements on the part of the mediator.
o 中介可以通过将“邮件发件人”重写为自己的域来解决问题。这意味着从外部邮箱拒绝的邮件必须由转发服务转发回原始发件人。尽管调解人在复杂性和资源需求方面存在很大差异，但实现这一点的方案多种多样。
o Several popular MTAs can be forced from "alias" semantics to "mailing list" semantics by configuring an additional alias with "owner-" prepended to the original alias name (e.g., an alias of "friends: george@example.com, fred@example.org" would need another alias of the form "owner-friends: localowner").
o 通过将附加别名配置为原始别名前面加上“owner-”（例如，“friends:george@example.com, fred@example.org“将需要另一个“所有者朋友：localowner”形式的别名。
o Mediators could reject mail that would "fail" SPF if forwarded using an SMTP reply code of 551, User not local (see Section 3.4 of [RFC5321]) to communicate the correct target address to resend the mail to.
o 如果使用SMTP回复代码551、用户非本地（请参阅[RFC5321]第3.4节）转发的邮件将“失败”SPF，则调解人可以拒绝该邮件，以传达正确的目标地址，以便将邮件重新发送到。
The end, when email is received:
最后，当收到电子邮件时：
o If the owner of the external mailbox wishes to trust the mediator, he can direct the external mailbox's MTA to skip SPF tests when the client host belongs to the mediator.
o 如果外部邮箱的所有者希望信任中介，则当客户端主机属于中介时，他可以指示外部邮箱的MTA跳过SPF测试。
o Tests against other identities, such as the "HELO" identity, can be used to override a failed test against the "MAIL FROM" identity.
o 针对其他标识（如“HELO”标识）的测试可用于覆盖针对“邮件发件人”标识的失败测试。
o For larger domains, it might not be possible to have a complete or accurate list of forwarding services used by the owners of the domain's mailboxes. In such cases, whitelists of generally recognized forwarding services could be employed.
o 对于较大的域，可能无法获得域邮箱所有者使用的转发服务的完整或准确列表。在这种情况下，可以使用公认的转发服务白名单。
MSPs (Mail Service Providers -- Section 2.3 of [RFC5598]) that offer mail services to third-party domains, such as the sending of bulk mail, might want to adjust their configurations in light of the authorization check described in this document. If the domain part of the "MAIL FROM" identity used for such email uses one of the MSP's domains, then the provider needs only to ensure that its sending host is authorized by its own SPF record, if any.
向第三方域提供邮件服务（如发送批量邮件）的MSP（邮件服务提供商——RFC5598第2.3节）可能希望根据本文档中描述的授权检查调整其配置。如果用于此类电子邮件的“邮件发件人”标识的域部分使用MSP的一个域，则提供商只需确保其发送主机由其自己的SPF记录（如果有）授权。
If the "MAIL FROM" identity does not use the MSP's domain, then extra care has to be taken. The SPF record format has several options for the third-party domain to authorize the service provider's MTAs to send mail on its behalf. For MSPs, such as ISPs, that have a wide variety of customers using the same MTA, steps are required to mitigate the risk of cross-customer forgery (see Section 11.4).
如果“邮件发件人”身份不使用MSP的域，则必须格外小心。SPF记录格式为第三方域提供了多个选项，以授权服务提供商的MTA代表其发送邮件。对于使用相同MTA的各种客户的MSP（如ISP），需要采取措施降低跨客户伪造的风险（见第11.4节）。
Relays are described in [RFC5598], Section 2.2.2. The authorization check generally precludes the use of arbitrary MTA relays between the sender and receiver of an email message.
[RFC5598]第2.2.2节介绍了继电器。授权检查通常禁止在电子邮件的发送者和接收者之间使用任意MTA中继。
Within an organization, MTA relays can be effectively deployed. However, for the purposes of this document, such relays are effectively transparent. The SPF authorization check is a check between border MTAs of different ADMDs.
在一个组织内，可以有效地部署MTA中继。然而，就本文件而言，此类继电器实际上是透明的。SPF授权检查是在不同ADMD的边界MTA之间进行的检查。
For mail senders, this means published SPF records have to authorize any MTAs that actually send across the Internet. Usually, these are just the border MTAs as internal MTAs simply forward mail to these MTAs for relaying.
对于邮件发件人，这意味着已发布的SPF记录必须授权任何实际通过Internet发送的MTA。通常，这些只是边界MTA，因为内部MTA只是将邮件转发到这些MTA进行中继。
The receiving ADMD will generally want to perform the authorization check at the boundary MTAs, including all secondary MXs. Internal MTAs (including MTAs that might serve as both boundary MTAs and internal relays from secondary MXs when they are processing the relayed mail stream) then do not perform the authorization test. To perform the authorization test other than at the boundary, the host that first transferred the message to the receiving ADMD has to be determined, which can be difficult to extract from the message header because (a) header fields can be forged or malformed, and (b) there's no standard way to encode that information such that it can be reliably extracted. Testing other than at the boundary is likely to produce unreliable results. This is described further in Appendix D of [RFC7001].
接收ADMD通常希望在边界MTA（包括所有辅助MX）上执行授权检查。内部MTA（包括在处理中继邮件流时可能同时用作边界MTA和辅助MX的内部中继的MTA）则不执行授权测试。要在边界以外的地方执行授权测试，必须确定首先将消息传输到接收ADMD的主机，这可能很难从消息头中提取，因为（a）头字段可能伪造或格式错误，以及（b）没有标准的方法来编码这些信息，以便能够可靠地提取出来。边界以外的测试可能产生不可靠的结果。[RFC7001]的附录D对此作了进一步说明。
Appendix G. Local Policy Considerations
附录G.当地政策考虑
SPF results can be used in combination with other methods to determine the final local disposition (either positive or negative) of a message. It can also be considered dispositive on its own.
SPF结果可与其他方法结合使用，以确定消息的最终本地处置（正面或负面）。它本身也可以被认为是决定性的。
SPF "pass" results can be used in combination with "whitelists" of known "good" domains to bypass some or all additional pre-delivery email checks. Exactly which checks and how to determine appropriate whitelist entries have to be based on local conditions and requirements.
SPF“通过”结果可与已知“良好”域的“白名单”结合使用，以绕过部分或所有额外的交付前电子邮件检查。具体哪些检查以及如何确定适当的白名单条目必须基于当地条件和要求。
SPF "fail" results can be used to reject messages during the SMTP transaction based on either "MAIL FROM" or "HELO" identity results. This reduces resource requirements for various content-filtering methods and conserves bandwidth since rejection can be done before the SMTP content is transferred. It also gives immediate feedback to the sender, who might then be able to resolve the issue. Due to some of the issues described in this section (Appendix G), SPF-based rejection does present some risk of rejecting legitimate email when rejecting email based on "MAIL FROM" results.
SPF“fail”结果可用于在SMTP事务期间根据“MAIL FROM”或“HELO”标识结果拒绝邮件。这减少了各种内容过滤方法的资源需求，并节省了带宽，因为可以在传输SMTP内容之前进行拒绝。它还向发送者提供即时反馈，发送者随后可能能够解决问题。由于本节（附录G）所述的一些问题，基于SPF的拒绝在基于“邮件发件人”结果拒绝电子邮件时确实存在拒绝合法电子邮件的风险。
SPF "fail" results can alternately be used as one input into a larger set of evaluations that might, based on a combination of SPF "fail" results with other evaluation techniques, result in the email being marked negatively in some way (this might be via delivery to a special spam folder, modifying subject lines, or other locally determined means). Developing the details of such an approach has to be based on local conditions and requirements. Using SPF results in this way does not have the advantages of resource conservation and immediate feedback to the sender associated with SMTP rejection, but could produce fewer undesirable rejections in a well-designed system. Such an approach might result in email that was not authorized by the sending ADMD being unknowingly delivered to end users.
SPF“失败”结果也可以作为一个输入输入到更大的一组评估中，根据SPF“失败”结果与其他评估技术的组合，可能会以某种方式导致电子邮件被负面标记（这可能是通过发送到特殊的垃圾邮件文件夹、修改主题行或其他本地确定的方式）. 制定此类方法的细节必须基于当地条件和要求。以这种方式使用SPF结果不具有节约资源和立即向发送方反馈SMTP拒绝的优点，但在设计良好的系统中可能会产生较少的不希望的拒绝。这种方法可能会导致未经发送ADMD授权的电子邮件在不知不觉中发送给最终用户。
Either general approach can be used, as they both leave a clear disposition of emails; either they are delivered in some manner or the sender is notified of the failure. Other dispositions such as "dropping" or deleting email after acceptance are inappropriate because they leave uncertainty and reduce the overall reliability and utility of email across the Internet.
这两种方法都可以使用，因为它们都可以清晰地处理电子邮件；要么以某种方式交付，要么通知发送方失败。其他处理方式，如接受后“删除”或删除电子邮件是不合适的，因为它们留下了不确定性，降低了整个互联网电子邮件的可靠性和实用性。
The "permerror" result (see Section 2.6.7) indicates that the SPF processing module at the receiver determined that the retrieved SPF policy record could not be interpreted. This gives no true indication about the authorized use of the data found in the envelope.
“permerror”结果（见第2.6.7节）表明接收方的SPF处理模块确定无法解释检索到的SPF策略记录。这并没有真正说明信封中数据的授权使用情况。
As with all results, implementers have a choice to make regarding what to do with a message that yields this result. SMTP allows only a few basic options.
与所有结果一样，实现者可以选择如何处理产生此结果的消息。SMTP只允许几个基本选项。
Rejection of the message is an option, in that it is the one thing a receiver can do to draw attention to the difficulty encountered while protecting itself from messages that do not have a definite SPF result of some kind. However, if the SPF implementation is defective and returns spurious "permerror" results, only the sender is actively notified of the defect (in the form of rejected mail), and not the receiver making use of SPF.
拒绝消息是一种选择，因为它是接收者可以做的一件事，以提请注意遇到的困难，同时保护自己不受没有某种明确SPF结果的消息的影响。但是，如果SPF实现存在缺陷并返回虚假的“permerror”结果，则只有发送方主动收到缺陷通知（以拒绝邮件的形式），而不是接收方使用SPF。
The less intrusive handling choice is to deliver the message, perhaps with some kind of annotation of the difficulty encountered and/or logging of a similar nature. However, this will not be desirable to SPF verifier operators that wish to implement SPF checking as strictly as possible, nor is this sort of passive reporting of problems typically effective.
较少干扰的处理选择是传递消息，可能需要对遇到的困难进行某种注释和/或类似性质的日志记录。然而，对于希望尽可能严格地实施SPF检查的SPF验证器操作员来说，这是不可取的，这种被动报告问题的方式通常也是无效的。
There is of course the option of placing this choice in the hands of the SPF verifier operator rather than the implementer since this kind of choice is often a matter of local policy rather than a condition with a universal solution, but this adds one more piece of complexity to an already non-trivial environment.
当然，可以选择将此选择权交给SPF验证者操作员而不是实现者，因为此类选择通常是本地策略的问题，而不是具有通用解决方案的条件，但这给已经不平凡的环境增加了一点复杂性。
Both implementers and SPF verifier operators need to be cautious of all choices and outcomes when handling SPF results.
在处理SPF结果时，实现者和SPF验证者操作员都需要对所有选择和结果保持谨慎。
The "temperror" result (see Section 2.6.6) indicates that the SPF processing module at the receiver could not retrieve an SPF policy record due to a (probably) transient condition. This gives no true indication about the authorized use of the data found in the envelope.
“temperror”结果（见第2.6.6节）表明，由于（可能）瞬态条件，接收器的SPF处理模块无法检索SPF策略记录。这并没有真正说明信封中数据的授权使用情况。
As with all results, implementers have a choice to make regarding what to do with a message that yields this result. SMTP allows only a few basic options.
与所有结果一样，实现者可以选择如何处理产生此结果的消息。SMTP只允许几个基本选项。
Deferring the message is an option, in that it is the one thing a receiver can do to draw attention to the difficulty encountered while protecting itself from messages that do not have a definite SPF result of some kind. However, if the SPF implementation is defective and returns spurious "temperror" results, only the sender is actively notified of the defect (in the form of mail rejected after it times out of the sending queue), and not the receiver making use of SPF.
延迟消息是一种选择，因为它是接收者可以做的一件事，以提请注意遇到的困难，同时保护自己不受没有某种明确SPF结果的消息的影响。但是，如果SPF实现存在缺陷并返回虚假的“temperror”结果，则只有发送方会收到缺陷的主动通知（以邮件在超出发送队列后被拒绝的形式），而不是接收方使用SPF。
Because of long queue lifetimes, it is possible that mail will be repeatedly deferred for several days, and so any awareness that the sender may have regarding a problem could be quite delayed. If "temperrors" persist for multiple delivery attempts, it might be preferable to treat the error as permanent and reduce the amount of time the message is in transit.
由于队列寿命很长，邮件可能会重复延迟几天，因此发件人对问题的任何意识都可能会被延迟。如果多次传递尝试都会出现“暂时错误”，则最好将错误视为永久性错误，并减少消息传输的时间。
The less intrusive handling choice is to deliver the message, perhaps with some kind of annotation of the difficulty encountered and/or logging of a similar nature. However, this will not be desirable to SPF verifier operators that wish to implement SPF checking as strictly as possible, nor is this sort of passive reporting of problems typically effective.
较少干扰的处理选择是传递消息，可能需要对遇到的困难进行某种注释和/或类似性质的日志记录。然而，对于希望尽可能严格地实施SPF检查的SPF验证器操作员来说，这是不可取的，这种被动报告问题的方式通常也是无效的。
There is of course the option of placing this choice in the hands of the SPF verifier operator rather than the implementer since this kind of choice is often a matter of local policy rather than a condition with a universal solution, but this adds one more piece of complexity to an already non-trivial environment.
当然，可以选择将此选择权交给SPF验证者操作员而不是实现者，因为此类选择通常是本地策略的问题，而不是具有通用解决方案的条件，但这给已经不平凡的环境增加了一点复杂性。
Both implementers and SPF verifier operators need to be cautious of all choices and outcomes when handling SPF results.
在处理SPF结果时，实现者和SPF验证者操作员都需要对所有选择和结果保持谨慎。
Author's Address
作者地址
Scott Kitterman Kitterman Technical Services 3611 Scheel Dr. Ellicott City, MD 21042 United States of America
斯科特·基特曼·基特曼技术服务3611美国马里兰州埃利科特市舍尔博士21042
EMail: scott@kitterman.com
EMail: scott@kitterman.com