现有的机制可以使 SPF 策略取决于从邮件的SMTP输入组装的DNS名称。这可以实现细粒度的策略，但也使可见的 TXT记录 对实际查询或其隐私影响的描述很差。
不要因为看起来很熟悉而批准一项宏观政策。将其扩展为代表性输入，识别接收查询的DNS运营商并确定肯定答案的含义。
了解现有测试
存在扩展其域规范并执行 A 记录查询。即使对于IPv6 SMTP连接，它也会执行此操作。如果有的话 一个记录 返回，机制匹配；返回的地址不会与连接 IP 进行比较。仅 AAAA 答案不能满足 A 查找。看 RFC 7208第 5.7 节.
在正常+预选赛下，一场比赛产生通过。姓名缺失或空答案不匹配；临时的DNS错误必须根据SPF的错误规则进行处理，而不是默默地转换为授权决策。
手动扩展综合查询
假设有效的单个记录、成功的DNS应答并且没有超出限制。考虑 v=spf1 exists:%{ir}._permit.%{d} -all 在example.com上获取来自192.0.2.9的IPv4连接。 i 宏代表输入地址。 r 变压器将部件反转，d 是电流评估域。扩展查询是 9.2.0.192._permit.example.com.
如果该名称返回 A 记录（例如说明性值127.0.0.2 ），则即使该地址与192.0.2.9不同，也存在匹配项。如果不存在 A 记录并且没有错误阻止评估，则该机制不匹配并且策略达到-all 。
这里的A值只是一个肯定答案标记。安全意义来自于对查询的DNS命名空间及其返回答案的规则的控制。回答每个可能的查询的通配符可能会无意中授权到达它的每个输入。
区分宏观身份
d 宏是当前正在评估的域。 o 宏来自发送者的域，而 l 指发送者的本地部分。包含或重定向可以更改计算上下文，因此不要假设 d 和 o 在依赖项内可以互换。
宏转换器可以选择部分、反转它们并更改分隔符。 IPv6扩展不是与IPv4相同的点分十进制字符串。使用 RFC 7208 §7.2 和 RFC 7208 §7.3 以及实际形式的实现跟踪，而不是从IPv4示例中猜测。
格式错误的扩展名称和过长的标签需要特别小心。在下面 RFC 7208 §4.8，规范指出了一些无效域规范结果的实现差异。将固定装置保持在有效的DNS语法内并测试您环境中使用的评估器；不要声称所有接收器都以相同的方式处理每个格式错误的输入。
检查隐私和可用性
如中所述 RFC 7208 §11.6，使用本地部分或完整发送者数据的宏可以通过DNS查询向命名空间运营商和相关DNS基础设施公开与消息相关的身份信息。在使用此类设计之前，请检查所需的最少数据，尤其是使用第三方策略服务时。
该策略还取决于应答DNS系统的可用性和完整性。记录谁在操作它、如何生成积极的答案、如何审查更改以及中断期间会发生什么。在下面 RFC 7208 §4.6.4、引起 DNS 查询的术语和 无效查找 仍受SPF限制；存在不提供无限制的外部策略调用。
建立有用的验收装置
测试授权输入、未经授权的输入、 IPv6如果使用）、 DNS中断以及有效但异常的发件人本地部分（如果影响查询）。保存每个灯具的准确扩展名称、查询类型、 DNS答案和终端SPF结果。
还测试通配符行为和对目标区域的更改。当应答服务更改其权限逻辑时，记录可以保持语法正确。仅当DNS决定可以得到解释和重现时才结束审核。
实用的外卖
对于存在来说，扩展的DNS问题是政策证据。在依赖结果之前检查其输入、回答语义、隐私暴露和错误行为。
记录决定及其限制
对于相同的192.0.2.9输入，区分三个装置： A= 127.0.0.2给出匹配和默认合格的通过；成功的空 A 答案不会给出任何匹配项并达到-all ；临时DNS错误结束评估 temperror 而不是失败。错误规则是 RFC 7208 §5 和 RFC 7208 §4.6.2。这些是预期结果，不是观察到的DNS或评估器运行。