2. 操作概述
2.1. 发布授权
符合SPF的域按照第3节的描述发布有效的SPF记录。这些记录授权由其中指定的MTA在"HELO"和"MAIL FROM"身份中使用相关域名。
SPF结果可用于做出肯定（来源已授权）和否定（来源未授权）的判定。如果ADMDs选择发布SPF记录并希望支持接收者做出否定授权判定，则它们需要发布以"-all"结尾的记录，或重定向到这样做的其他记录；否则，无法做出明确的授权判定。与否定判定相关的潜在问题和缓解措施在第10节中讨论。
希望声明在SMTP会话期间没有主机被授权在HELO或MAIL FROM命令中使用其DNS域名的ADMDs可以为既不用于电子邮件地址的域部分也不期望发起邮件的域名发布表明这一点的SPF记录。
在更改SPF记录时，必须注意确保有一个过渡期，以便旧策略在所有合法电子邮件可以合理地预期已被检查之前保持有效。[RFC5321]第4.5.4.1节讨论了消息可能在传输中的时间。虽然离线检查是可能的，但检查执行时间越接近原始传输时间，就越有可能获得与发送ADMD在发送消息时的意图相匹配的SPF结果。
2.2. 检查授权
邮件接收者可以对其接收的每封邮件消息执行一组SPF检查。SPF检查测试客户端主机使用给定身份发送邮件的授权。通常，此类检查由接收MTA执行，但可以在邮件处理链中的其他位置执行，只要所需的信息可用且可靠。"MAIL FROM"和"HELO"身份分别按照第2.4节和第2.3节的描述进行检查。
如果没有发布ADMD的明确批准，不建议针对SPF版本1记录检查其他身份，因为已知存在会给出错误结果的情况。例如，几乎所有邮件列表都会重写"MAIL FROM"身份（参见第10.3节），但有些不会更改消息中的任何其他身份。定义其他身份的文档将必须定义明确批准的方法。
邮件接收者可能将SPF检查用作对传入邮件进行更大测试集的一部分。其他测试的结果可能会影响是否执行特定的SPF检查。例如，在本地白名单上找到发送主机的IP地址可能会导致跳过所有其他测试并接受来自该主机的所有邮件。
当邮件接收者决定执行SPF检查时，它必须使用正确实现的check_host()函数（第4节）并使用正确的参数进行评估。尽管整个测试是可选的，但一旦决定执行测试，就必须按照规定执行，以便在发布者和接收者之间保留正确的语义。
要进行测试，邮件接收者必须使用第4.1节中描述的参数评估check_host()函数。
尽管无效、格式错误或不存在的域会导致SPF检查返回"none"，因为找不到SPF记录，但长期以来许多MTA的策略是拒绝来自此类域的电子邮件，尤其是在无效的"MAIL FROM"的情况下。拒绝电子邮件将防止一种规避SPF记录的方法。
实现必须注意从SMTP MAIL FROM命令给出的数据中正确提取
2.3. "HELO"身份
建议SPF验证者不仅检查"MAIL FROM"身份，还通过将check_host()函数（第4节）应用于"HELO"身份作为
请注意，在EHLO或HELO命令中提供的域的要求对发送方并不总是清楚，SPF验证者必须准备好身份是IP地址字面量（参见[RFC5321]第4.1.3节）或只是格式错误。只有当"HELO"字符串是有效的多标签域名时，才能执行此SPF检查。
2.4. "MAIL FROM"身份
如果未执行"HELO"检查或未通过将check_host()函数应用于"MAIL FROM"身份作为
[RFC5321]允许反向路径为空（参见[RFC5321]第4.5.5节）。在这种情况下，没有明确的发件人邮箱，这样的消息可以被假定为来自邮件系统本身的通知消息。当反向路径为空时，本文档将"MAIL FROM"身份定义为由本地部分"postmaster"和"HELO"身份（之前可能已单独检查过，也可能没有）组成的邮箱。
2.5. 检查位置
授权检查应该在处理接收邮件的SMTP事务期间执行。这降低了确定用作check_host()输入的正确IP地址的复杂性，并允许通过SMTP回复直接向发送MTA返回错误。[RFC7001]的附录D提供了对此主题的更深入讨论。
授权检查在SMTP事务期间的MAIL命令时执行，并使用MAIL FROM值和客户端IP地址。在以后的时间或使用其他输入执行检查可能会导致以下问题：
- 可能难以从可能具有欺骗性的标头中准确提取所需信息。
- 合法电子邮件可能会因为发件人的策略已更改而未通过授权检查。
向未通过授权检查的伪造身份生成不可送达通知通常构成反向散射，即无法采取行动的令人讨厌的拒绝通知。强烈建议运营商避免此类做法。[RFC3834]的第2节描述了反向散射及其引起的问题。
2.6. 评估结果
第4节定义了check_host()，这是一个模型函数定义，它使用上面定义的输入和在DNS中发布的发件人策略来得出关于客户端授权的结论。SPF验证者实现与那里定义的函数在语义上等效的东西。
本节枚举并简要定义该函数的可能输出。但是，请注意，协议未建立处理任何特定结果的规范性要求。有关每个结果的处理选项的讨论可以在第8节中找到。
2.6.1. None
"none"结果意味着（a）没有从可以用作要授权的
2.6.2. Neutral
"neutral"结果意味着ADMD已明确声明它不断言IP地址是否已授权。
2.6.3. Pass
"pass"结果是客户端被授权使用给定身份注入邮件的明确声明。
2.6.4. Fail
"fail"结果是客户端未被授权在给定身份中使用域的明确声明。
2.6.5. Softfail
"softfail"结果是发布ADMD的弱声明，表明主机可能未被授权。它尚未发布导致"fail"的更强、更明确的策略。
2.6.6. Temperror
"temperror"结果意味着SPF验证者在执行检查时遇到了瞬态（通常是DNS）错误。稍后的重试可能会成功，而无需进一步的DNS操作员操作。
2.6.7. Permerror
"permerror"结果意味着无法正确解释域发布的记录。这表示错误条件，肯定需要DNS操作员干预才能解决。