10. 对基础设施的影响 (Effects on Infrastructure)
本节概述了采用此协议对涉及互联网电子邮件的各个实体将产生的主要影响。它旨在向读者明确此协议在何处明确影响此类实体的运行。本节不是"操作手册"或"最佳实践"文档，也不是此类实体根据本规范应该做什么的全面列表。
本节仅提供操作建议和指导。它不是规范性的。
[RFC5598]描述了互联网电子邮件架构。本节根据架构的不同部分进行组织。
10.1. 发送域 (Sending Domains)
希望符合本规范的发起ADMD（管理域——[RFC5598]的第2.2.1和2.3节）将需要确定它们允许在中继到其他ADMD时在"HELO"和"MAIL FROM"身份中使用其域名的中继列表（[RFC5598]第2.2.2节）。人们认识到，形成这样的列表不仅仅是一个简单的技术练习，而是涉及具有技术和管理考虑的策略决策。
10.1.1. DNS 资源考虑 (DNS Resource Considerations)
通过选择需要较少DNS信息的指令并将成本较低的机制放在SPF记录的早期位置，可以最小化SPF查找所需的DNS资源。
第4.6.4节指定了接收器必须使用的限制。发布不超过这些要求的记录至关重要。还需要仔细权衡合法解决方案的成本和可维护性。
例如，考虑如下设置的域：
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
假设管理要点是授权（pass）mx和mx2，同时使所有其他主机失败。比较以下解决方案：
最佳记录：
example.com. IN TXT "v=spf1 ip4:192.0.2.1 ip4:192.0.2.129 -all"
良好记录：
$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
昂贵记录：
example.com. IN TXT "v=spf1 mx:example.com -all"
浪费的、不良记录：
example.com. IN TXT "v=spf1 ip4:192.0.2.0/24 mx -all"
10.1.2. 管理员的考虑 (Administrator's Considerations)
可能存在管理考虑：使用"a"而不是"ip4"或"ip6"允许主机轻松重新编号，代价是每个接收器需要进行DNS查询。使用"mx"而不是"a"允许邮件主机集轻松更改。除非这样的更改很常见，否则最好使用资源密集程度较低的机制，如"ip4"和"ip6"而不是"a"，或"a"而不是"mx"。
在某些特定情况下，关于记录内容的标准建议是适当的。为不发送邮件的域发布SPF记录是一个成熟的最佳实践。不发送邮件的域的记录是：
www.example.com. IN TXT "v=spf1 -all"
为单个主机发布SPF记录也是最佳实践。主机名通常是5321.HELO/.EHLO命令中使用的身份。在具有空5321.MailFrom的消息的情况下，除了用于基于5321.HELO/.EHLO的SPF检查外，这还用作5321.MailFrom SPF检查的域。参与邮件处理的单个主机的标准SPF记录是：
relay.example.com. IN TXT "v=spf1 a -all"
验证正确的部署很困难。[RFC6652]描述了一种征求SPF失败反馈的机制。另一个建议可以在附录C中找到。
无论使用哪种方法，理解ADMD的出站邮件架构对于有效部署至关重要。
10.1.3. 退信 (Bounces)
如第2.4节所述，[RFC5321]允许MAIL FROM为空，这是某些传递状态通知[RFC3464]的典型情况，通常称为电子邮件退信。在这种情况下，可用于执行SPF检查的唯一实体是第1.1.4节中定义的"HELO"身份。管理员确保正确设置此身份并具有适当的SPF记录可以增强SPF功能。将"HELO"身份设置为主机名而不是域是正常的。对于大量主机的区域文件生成可以使用"redirect"修饰符进行整合，并为初始部署编写脚本。具体的部署建议在上面的第10.1.2节中给出。
10.2. 接收者 (Receivers)
SPF结果可以与其他方法结合使用，以确定消息的最终本地处置（正面或负面）。它也可以单独被视为决定性的。
试图让一个组织（发件人）指导另一个组织（接收方）的电子邮件处理策略本质上是具有挑战性的，并且经常是有争议的。如本文档其他地方所述，没有基于SPF结果的消息特定处理的全面规范性要求。在形成本地处理策略时，第8节和附录G中提供的信息可供接收方考虑。
主要考虑因素是，SPF可能会为最终有害的邮件返回"pass"（例如，使用一次性域名安排SPF通过的垃圾邮件发送者，或来自受信任源内的病毒或垃圾邮件爆发），也可能会为最终合法的邮件返回"fail"（例如，已通过邮件别名的合法邮件）。在建立本地处理策略时，重要的是要考虑这两种情况。
10.3. 中介者 (Mediators)
中介者是一种用户参与者[RFC5598]。也就是说，中介者"接收"一条消息并"提交"一条新消息。中介者可以使新发布的消息与原始消息尽可能相似或尽可能不同。示例包括邮件列表（参见[RFC5598]的第5.3节）和转发者（[RFC5598]的第5.2节）。这在[RFC5321]第3.9节中讨论。对于SPF的操作，关键问题是新消息的5321.MailFrom命令中的电子邮件地址。
由于SPF评估基于"最后"发送SMTP服务器的IP地址，因此将使用中介者的地址，而不是向中介者发送消息的SMTP服务器的地址。一些中介者保留原始消息的电子邮件地址，而一些使用新地址。
如果地址与原始消息相同，并且原始消息具有关联的SPF记录，则SPF评估将失败，除非使用附录D中描述的缓解措施。