对结果而不是警告颜色进行分类
DNS健康检查器可以将协议故障、弹性建议和可选功能结合到一个令人震惊的分数中。邮件运营商需要不同的排序：什么决定受到影响，在哪条路线上，以及有什么证据？不可用的活动 DKIM 密钥和较低 TTL 的建议不应自动获得相同的事件优先级。
首先捕获准确的警告、测试名称和记录类型、时间、解析器或有利位置以及工具的说明。将其分类为观察到的故障、合理的风险或咨询建议。如果该工具仅提供标签，请保留该限制。不要仅仅为了使仪表板变绿而发布另一个身份验证记录。
确定测试的名称是否属于邮件路径
缺失的DKIM记录仅与以下方面相关： 选择器 以及受调查服务实际使用的签名域。 RFC 6376第3.6.2.1节 从签名值派生查找名称。猜测选择器的扫描器可能会错过有效的部署密钥或警告未使用的名称。在将猜测的缺勤视为生产故障之前，请求代表性消息证据。
应用同样的纪律 SPF。检查可见发件人域的工具可能不会检查接收者评估的SMTP身份。 RFC 7208第 2 节 区分这些身份。在决定由哪个所有者修复警告之前，先确定路线和实际评估的名称。
查找当前委派的权限，包括任何相关的子区域委派或别名。仅当控制面板与该权限的关系已知时，控制面板才是预期配置的证据。保留缺失记录、错误名称的值和错误托管帐户中的编辑之间的区别。
在更改记录之前解释响应
NXDOMAIN表示所查询的名称不存在，而NODATA结果表示现有名称中不存在所请求的数据。负缓存可以保留那些早期的结果，如中所述 RFC 2308第 2 节和第 5 节。因此，新创建的记录可能会在特定的递归路径显示之前出现在权威机构中。
相反， SERVFAIL描述解析失败，并不证明该策略不存在。 RFC 9520第 2.1 节 讨论其许多可能的原因。调查委托、可达性和验证证据。在解决方案被破坏时添加重复记录可能会在修复原始故障后留下第二个问题。
关于 TCP 支持的警告不应该只是表面上的驳回。 RFC 7766第 5 节 需要通用DNS实现来支持 UDP 和 TCP。一次小的成功查找并不能证明更大的响应或其他路径可以正常工作。正确的后续行动是范围内的传输诊断，而不是声称当前的每条消息都已经失败。
将直接影响与潜在风险分开
立即影响邮件的发现将观察到的DNS问题与活动路由联系起来：例如，接收者在验证时所需的选择器的解析器故障。潜在的可靠性问题可能会使当前测试通过，同时降低弹性。咨询发现可能涉及所需的功能，该功能的缺失并不会使实际部署的协议失效。
从两个维度进行分类：对观察的置信度和情况持续存在的后果。证据不完整的严重怀疑可能需要紧急调查，但无需宣布停电。过期的咨询例外应该收到所有者和审查日期，而不是从报告中悄悄消失。
避免使用诸如“DNSSEC 丢失意味着电子邮件身份验证已损坏。” DNSSEC可以添加经过身份验证的DNS数据，而SPF 、 DKIM和 DMARC 有自己的要求和结果。在哪里 DANE 部署了SMTP ， DNSSEC在该传输设计中具有直接作用 RFC 7672第 2.1 节。因此，相同的警告可能会在不同的服务中产生不同的后果。
三个警告的虚构示例
example.com的一个虚构检查器报告了一个名为 default 的缺失选择器、对一个权威端点的 TCP 查找失败以及 TTL 建议。邮件团队发明的库存将 June 标识为其活动发票路由使用的选择器。因此，第一个警告需要选择器确认，而不是立即创建记录。
第二条警告将发送给DNS所有者，其中包含测试的端点、时间和受影响的响应详细信息。即使一个小的 UDP 查询成功，它也代表了传输问题。 TTL 建议成为更改计划讨论：减少 TTL 可能有助于将来的更改，但它不能证明当前的传递失败或立即缩短已使用旧值缓存的条目。
对于这种情况，没有执行任何查询或消息。其提出的优先事项说明了如何避免将混合仪表板分数视为技术裁决。真正的分类需要保留权威的递归结果以及将测试记录与服务联系起来的证据。
记录可以审查的决定
对于每个警告，记录受影响的依赖性、证据、置信度、所有者、下一步操作和关闭条件。如果不确定发生了什么变化以及下一次观察必须确定什么，“稍后重新检查”是不完整的。 “接受的风险”应包括谁接受了风险以及何时重新考虑该决定。
授权修复后，重复相关观察并验证相关服务，而不是仅仅刷新原始分数。保留权威、递归路径和消息结果之间未解决的差异。原始证据门保持开放状态，直到带时间戳的权威和递归答案识别出确切的所有者姓名和记录类型。本手稿不提供这些观察结果或证明域的健康状况。