身份验证记录可以在DNS控制台中看起来是本地的，同时依赖于另一个组织的名称服务器或记录。要评估可用性，请遵循解析和身份验证路径，而不是计算供应商或查看仪表板正常运行时间数据。有用的问题是，当接收者评估此特定消息时，必须回答哪个依赖关系。
区分委托机制
委派的DNS区域将区域边界下的名称的权限转移到指定的名称服务器。一个 CNAME 将一个名称指向另一个名称。 SPF 包含和重定向是应用程序级策略关系，而不是区域委派。它们创建了不同的故障路径，并且不能被评估为可互换的托管形式。 RFC 1034 解释权威服务和递归解析； RFC 7208 指定SPF对DNS的使用。
为每个步骤绘制准确的所有者姓名和记录类型。为了 DKIM 这始于 选择器 在签名域的_domainkey下。对于SPF ，从相关的经过身份验证的身份开始并遵循其策略条款。为了 DMARC，分别评估策略发现依赖性。提供商可以操作其中两个而不操作第三个。
记录故障语义，而不仅仅是正常运行时间
询问如果目标没有返回数据、明确的否定答案、格式错误的策略或超时会发生什么。这些并不等同。 SPF定义了永久和暂时的错误结果。 DKIM验证可能会受到不可用或无效的密钥信息的影响。接收者的最终消息处理还可以依赖于另一对齐的身份验证路径和本地策略，因此避免承诺一次查找失败总是阻止或总是传递邮件。
缓存可以暂时保留早期可用的答案，但它不是无限的备份。记录答案的 TTL 和观察时间。否定答案也可以根据中描述的规则进行缓存 RFC 2308。现在减少 TTL 不会追溯缩短已缓存在其他地方的答案的生命周期。
比较两个恢复依赖关系
假设一个已批准的权威查询返回一个新配置的选择器目标，而一个递归解析器仍然返回较早缓存的目标。记录来源和时间戳。在该服务器上观察到权威更改；它并不能证明所有接收者都使用新目标。现在假设替换签名服务缺少相应的私钥。即使在更正每个相关查找后，仅DNS也无法使该服务成功签名。
这些是假设的观察结果，不是本地DNS实验室或生产测试。它们导致单独的后续步骤：在批准的有利位置验证缓存和目标解析，并验证替换签名者的实际配置和消息输出。保留服务器、名称、类型、响应代码、标志、TTL 和完整答案。这个例子不练习 DNSSEC、引用或负缓存；在架构需要的地方独立测试它们。
决定依赖关系是否可接受
为每个外部目标分配一个所有者，并记录供应商的实际恢复和退出安排。考虑是否可以替换记录、是否拥有必要的公共元数据以及签名更改是否需要在另一个服务内执行操作。同一权威基础设施上的多个仪表板不会消除这种共享依赖关系。
在授权环境中测试替代品，并定义中断何时触发更改而不是观察。仓促的编辑可能会添加SPF错误或将选择器指向错误的键。保留以前的记录和决策日志，但要认识到恢复受到缓存和任何丢失的访问的限制。结果应该是有证据的特定于依赖项的风险决策，而不是声称所有DNS授权都是不安全的。