测试 SPF 需要两种证据： DNS发布的内容以及接收者对特定消息评估的内容。 Dig 和 nslookup 帮助检查第一个。值得信赖的 Authentication-Results 现场或接收器侧跟踪有助于检查第二个。保持这些观察结果通过相同的包络域、发送路径和时间窗口连接。
从正确的域开始
通过您正在调查的应用程序发送代表性消息并保留其原始标头。使用以下方法从受信任的接收者证据中识别信封身份 Return-Path 作为线索，而不是将其与可见的发件人地址混淆。对于空反向路径， SPF的身份处理涉及 HELO;不要假设普通消息输入涵盖这种情况。 RFC 7208 §2.3 和 RFC 7208 §2.4 描述身份。
记下接收方观察到的发送IP、信封身份、接收方系统和消息时间。不要仅仅为了获得彩色结果而将完整的私有标头上传到不熟悉的公共检查器。最小的受控装置通常可以回答技术问题，而不会泄露不相关的消息数据。
检查已发布的TXT响应
这些是示例性只读命令。将示例名称替换为正在评估的域；它们不是已经运行测试的证据：
bounce.example.com TXT 。 nslookup - type=TXT bounce.example.com这 BIND挖掘手册 记录查询实用程序，以及 微软的nslookup参考 描述查询选项。对绝对查询名称使用尾随点，避免意外的搜索后缀扩展。故障排除时保留完整响应，包括解析器、状态、答案和 TTL（如所示）。简短的答案可以方便阅读，但会省略诊断上下文。
检查实际所有者名称并从不相关的中选择SPF值 TXT记录。多个带引号的字符串可以属于一条TXT记录； SPF将这些字符串视为串联字符串，而不插入空格。两个单独适用 SPF记录 是一个不同的问题。 RFC 7208 §3.2 和 RFC 7208 §3.3 定义这种区别。
读取配对的合成结果
以下是完全合成的夹具，未观察到的邮件或生产记录。假设接收者看到来自文档地址192.0.2.10的直接连接， 邮件来自 invoices@bounce.example.com并可见来自invoices@example.com 。其DNS响应包含一条TXT资源记录：
bounce.example.com 。 300 IN TXT “ v=spf1 ip4:192.0.2.10 ”“ -all ”该记录中的两个字符串连接到 v=spf1 ip4:192.0.2.10 -all。第一个字符串中的尾随空格将机制分开。对于指定的连接，地址机制匹配并且预期的SPF结果通过。相应的说明性接收器结果是：
Authentication-Results ： mx.receiver.example ； spf=pass smtp.mailfrom= bounce.example.com仅在明确的固定假设mx.receiver.example是目标的可信身份验证服务的情况下才将其视为可信。发件人可以以其他方式插入类似的文本。该示例仅显示SPF证据；它没有断言 DKIM, DMARC 或交付结果。
与此不同的合成DNS答案进行对比，该答案包含两个具有相同名称的单独适用记录：
bounce.example.com 。 300 IN TXT “ v=spf1 ip4:192.0.2.10 -all ” bounce.example.com 。 300 IN TXT “ v=spf1 ip4:192.0.2.20 -all ”记录选择现在返回 permerror 而不是合并授权。不要仅通过计数引号来诊断这种情况；保留DNS资源记录边界。
当发布有争议时比较解析器
如果DNS编辑器和递归查询不一致，请确定权威的 名称服务器 直接查询经过验证的权威服务器。 Dig 支持表单 挖掘@服务器名称TXT;替换实际经过验证的服务器和目标名称。将答案和时间戳与递归结果进行比较。不要假设正在编辑的DNS帐户托管委派区域。
当前的权威答案和较旧的递归答案可以指示缓存。超时、 SERVFAIL和没有适用记录的成功响应是不同的观察结果。在确定原因之前保留准确的响应。避免仅仅因为一项观察结果过时而重复编辑正确的记录。
评估消息，而不仅仅是语法
TXT查找不执行SPF 。具有标准意识的评估者需要连接 IP 和相关SMTP身份，以及它解析的DNS状态。检查其跟踪是否有匹配的机制、依赖性和错误。静态记录验证器可以报告结构上可接受的策略，而不回答真正的发送者是否通过。
在目的地，读取由可信接收者插入的Authentication-Results ，而不是任意早期副本。 RFC 8601 使得信任边界变得重要。将SPF结果和身份与DKIM和DMARC结果一起记录，而不将它们视为可互换的。
保留可重复的测试记录
保存命令、查询时间、 DNS响应、评估者输入和经过编辑的收到消息证据。测试正在使用的每个显着不同的应用程序路由和地址族。将合成装置与观察到的结果分开标记。如果DNS视图看起来正确但接收者不同意，请继续 工具通过与接收者失败 而不是宣称接收者一定是错的。
DNS背景： RFC 1035第 3.2.1 节 定义资源记录 TTL； RFC 2308 §5 涵盖负缓存； RFC 8767 §4 更新 TTL 语义并在权威刷新失败时允许过时的使用。这些描述的是DNS行为，而不是更改的通用完成时间。
记录下一个决定
对于单记录固定装置，保留一条记录内显示两个字符串的边界以及连接空间； 192.0.2.10的预期SPF为通过。对于两条记录的固定装置，在评估机制之前，选择会失败并出现permerror 。单独保存可信结果假设：打印的Authentication-Results文本不独立可信。这里没有执行任何命令或邮件验证。