两个检查员可以意见不一致，但不会错误地显示当前的权威记录。他们可能会提出不同的问题，使用不同的解析器或应用不同的身份验证逻辑。首先准确捕获他们的输入和输出；红色或绿色状态是结论，而不是DNS跟踪。
与实际问题相符
参考： RFC 1035 §4.1.1, RFC 2308 §2.2, RFC 7208 §4.1.
记录准确的完全限定名称、记录类型、时间戳和工具版本。为了 DKIM 包括 选择器 和签名域。为了 SPF记录 如果检查器执行策略评估，则评估的身份和源 IP。仅查看 apex TXT工具所执行的任务与递归评估特定发件人的包含依赖性的工具不同。
保留响应代码和所有相关的答案部分。没有请求数据的 NOERROR 与NXDOMAIN 、 SERVFAIL和超时不同。别名可以将工具引导至不同的终端所有者。一个连接所有的工具 TXT记录 进入一个字符串可能会报告解析器工件而不是解析器分歧。
明确路径和政策
参考： RFC 4033 §3, RFC 4035 §5.5.
找到该工具公开的已配置的递归解析器或转发器。 VPN、企业视图、本地覆盖、验证和过滤可以改变观察结果。其他地方托管的检查器可能具有不同的缓存历史记录。不要从浏览器的解析器设置推断实际邮件接收者的解析器。
直接向权威服务器查询发布基线，然后查询指定的递归服务。直接的权威可见性并不成功 DNSSEC 验证。如果验证解析器返回SERVFAIL ，而直接查找返回数据，请调查链和诊断；不要假设验证是唯一可能的原因。
重现两条合法的缓存历史
参考： RFC 1034 §5.3.3, RFC 8767 §4.
使用实验室时间线：在t=0解析器 A 缓存 TTL 300 的策略 P。在t=100权限对策略 Q 进行更改。在t=120解析器 B 进行第一次查询并获取 Q，而在此简化模型中，A 仍可以为 P 提供大约 180 秒的剩余新鲜度。这不是通用的丢弃期限：使用RFC 8767实现可以在指定的故障条件下保留并提供过时的答案。预期的差异是通过缓存计时来解释的，而不是通过两个当前的权限策略来解释的。
保留权威服务器本身不同意的第二种情况。在这种情况下，等待 A 的缓存数据过期并不能修复底层的发布错误。保留的历史离线捕获记录了这两种分类。它不模拟特定于解析器的陈旧答案功能、预取或生产缓存。
按正确顺序解决原因
首先修复冲突的权威数据。然后检查缓存年龄、负缓存条目、别名、分割视图和验证失败。重复确切的问题，而不是进行不相关的编辑，直到所有仪表板变成绿色。将任何工具规范化或解析器限制记录为单独的问题。
当输入和DNS答案匹配但身份验证结论仍然不同时，请比较应用程序算法和身份假设。代表性消息的实时接收结果是与DNS发布不同的证据层。缩小最终声明的范围：返回哪些名称和类型、通过哪条路径、在何时以及哪些内容尚未测试。
保留历史实验室证据
保留的捕获日期为 2026 年 11 月 7 日。以下描述的是有限的历史观察，而不是EmailAuth.ai的新执行或测试。
两个有限缓存转发器查询相同的环回权限。一张在政策改变之前就已准备好，但仍然被退回 p=none 减少 TTL；新查询的转发器返回 p=reject。直接查询捕获当前权威的p=reject答案。每个捕获包括 UTC 时间、TTL、类型、端点、AA/RA 和线路字节。这些自定义转发器演示了这种受控缓存历史记录，而不是每个递归实现。捕获标签为resolver1_cached_old；解析器2_fresh_new；权威_当前。保留的跑步者和原始捕获包含在本审查包中作为历史证据。他们接受了检查，但没有重新进行本次审查。生产DNS 、 DNSSEC和SMTP结果仍未经过测试。