[ 送达率和发件人规则 ]

为什么DNS修复无法修复所有传送问题

将DNS证据连接到实际失败的机制,并将路由或身份验证修复与不相关的接收者策略和传递条件区分开来。

由EmailAuth研究团队提供 · 7 分钟阅读

[ 要点 ]

  • 查询确切的所有者姓名和记录类型。
  • 正确的DNS不会建立消息身份验证或收件箱传递。
  • 关闭观察到的机制,而不声明所有可交付性都已修复。
在此页面上

确定DNS更改可能影响哪些故障

DNS对于邮件路由和身份验证至关重要,但正确的记录并不能解决所有投递问题。 DNS正确应答后,邮件可能会因收件人策略、内容、信誉、队列行为、帐户限制或其他条件而失败。从观察到的故障阶段开始,询问哪条记录(如果有)参与该决策。在没有该链接的情况下重复编辑DNS可能会产生新的风险,同时不会影响原始问题。

本文使用保留的主DNS 、 SMTP和提供商文档。它不检查活动域或执行交付测试。该目录需要针对确切所有者名称和记录类型的带时间戳的权威和递归答案。这些观察结果仍然缺失,因此这里没有声明真正的配置正确或错误。

将记录发布与解析器观察分开

在查询之前记录完全限定的所有者名称和记录类型。一个 TXT记录 在一个 DKIM选择器 与域顶端的TXT记录不是同一对象,并且子域的管理方式可以与其父域不同。保留实际返回的记录边界和值,而不是仅仅依赖DNS编辑器显示它们的方式。 RFC 1035定义了DNS响应中使用的资源记录结构和 TTL。 RFC 1035

提议的证据集应包括权威观察和相关的递归观察,每个观察都带有时间戳和查询上下文。递归缓存可以反映以前的状态,而权威服务则显示较新的状态。不要在不检查名称、类型和响应状态的情况下调用每个差异传播。本地缓存刷新并不能确定外部接收器观察到的内容。

将身份验证记录与实际消息身份联系起来

SPF, DKIM 和 DMARC 取决于特定的身份和消息条件。错误名称的看似有效的记录并不能证明该消息使用了该名称。 DMARC评估与可见发件人域的一致身份验证,而DKIM识别其签名域和选择器。保留实际收到的消息上下文(如果可用),而不是假设发送平台使用配置的身份。 RFC 9989 RFC 6376

DNS修复可以解决丢失或格式错误的查找依赖项,而无需修复未签名的消息、修改的签名或意外的发送路由。相反,消息可以成功通过身份验证,但在另一个策略下仍然会被拒绝。因此,封闭测试必须涵盖失败的机制,而不仅仅是显示DNS检查器现在返回绿色。

在选择下一层之前读取接收器的响应

Yahoo的SMTP指南区分了临时延迟、身份验证失败、无效收件人和基于内容的策略阻止。这些类别不共享一种DNS补救措施。永久无效收件人响应不应触发SPF扩展,内容诊断需要有关邮件和发送实践的证据,而不是推测性MX更改。 Yahoo SMTP诊断

Microsoft 的Exchange Online NDR 参考同样将特定身份验证错误与收件人自定义阻止列表和自动转发限制区分开来。确切的响应和收件人上下文决定了应该调查哪个所有者。发件人的DNS管理员可能无权更改收件人的策略,并且正确的DNS答案不会覆盖该策略。 Microsoft NDR 参考

将SMTP接受和收件箱放置分开

SMTP接受建立传输阶段结果,而不是收件人阅读或通用收件箱传送。稍后的过滤器可以应用其自己的处理。保留完整的事务和任何后续 DSN,而不是将成功的DNS查询或接受的切换视为业务消息到达预期接口的证据。 RFC 5321

当DNS编辑后问题发生变化时,准确记录发生的变化。新的尝试可以使用不同的路由、收件人或消息正文。如果没有受控条件,证据可能会显示出改进,但无法证明是DNS编辑造成的。不要仅仅因为时机方便就声称根本原因;保留前后的观察结果和相互矛盾的解释。

原始 DNS 到交付工作表

使用此建议的工作表来确定DNS更正是否相关以及还剩下什么。真实域尚未完成。

  • 失败:准确响应、受影响的收件人、 SMTP阶段和观察时间。
  • 候选依赖性:所有者名称、记录类型以及记录可能影响失败的原因。
  • 权威答案:服务器查询、时间戳、响应状态、保留结果。
  • 递归答案:解析器上下文、时间戳、TTL 和保留结果。
  • 消息身份:可见的发件人、信封身份、签名域和相关选择器。
  • 非 DNS 条件:收件人策略、内容、帐户、声誉或路由证据。
  • 批准的更改:预期的更正、所有者、回滚和不相关的记录保持不变。
  • 结束:受控的后续结果及其支持的精确主张。

明确标记不存在的证据。如果原始故障响应未保留,请在选择维修之前收集新的授权观察结果。如果递归结果与权威结果不同,请保留两者并调查时间和命名空间。如果两者都正确,不要仅仅因为业务问题仍未解决而继续编辑。

虚构示例:身份验证已修复,但转发仍被阻止

虚构的 Maple Transit 在计划练习中更正了预期的身份验证记录,然后遇到单独的转发策略拒绝。拟议的审查将假设的DNS改进与接收者或租户策略决策区分开来。它不会仅仅因为整个工作流程仍无法完成而假设DNS修复失败,也不承诺另一次记录编辑将消除限制。

下一步将是确定负责的保单所有者,并确认转发行为是否是有意的和授权的。受控测试需要保留准确的路线和响应。 Maple Transit 是虚构的:未观察或更改任何DNS应答、消息、租户策略或传送结果。该场景说明了多个独立的门,而不是经过验证的修复。

使用狭义的、基于证据的完成声明

一个好的DNS闭包语句可以识别现在观察到的确切名称和类型、权威和递归上下文以及重新测试的机制。它还列出了该范围之外的其余交付条件。 “选择器查找现在返回预期的密钥”比“送达能力已固定”更窄且更有用,尤其是在没有观察到接收方结果的情况下。

避免将扩展身份验证授权或更改路由记录作为对声誉或内容问题的一般响应。此类更改可能会影响不相关的流并造成安全隐患,而无法解决接收者的实际原因。将纠正措施与证据和负责人的批准联系起来。

该目录的带时间戳的权威和递归证据仍然开放。人类SME、来源适用性、生产路线、视觉可达性和所有者发布也都是开放的。该草案提供了诊断边界和工作表,而不是实时DNS验证或保证邮件将到达收件箱。

[ 外卖 ]

保留权威、递归和消息证据,然后将剩余的故障引导给负责的非 DNS 所有者。

[ 按角色 ]

这对您意味着什么

选择您的角色以执行后续实际步骤。

IT/邮件管理员

将记录与失败的机制联系起来

错误名称的正确记录不是修复。

后续步骤

  1. 保留准确的查询上下文。
  2. 将消息标识与记录进行匹配。
  3. 使用受控的后续观察。

CISO / SecOps

避免无关的授权更改

在不修复策略或内容故障的情况下,扩大记录可能会增加风险。

后续步骤

  1. 需要因果假设。
  2. 保持无关记录不变。
  3. 保留批准和回滚条件。

创始人/非技术人员

使用狭义的完成声明

DNS成功并不是普遍的交付保证。

后续步骤

  1. 询问重新测试的阶段。
  2. 单独分配非 DNS 阻止程序。
  3. 保持接受者结果的不确定性可见。

[ 常见问题解答 ]

常见问题

绿色DNS检查是否证明收件箱已送达?

不会DNS解析、身份验证和接收器处理是不同的阶段。

为什么要保留权威且递归的答案?

它们提供不同的观察上下文,包括可能的缓存数据和 TTL。

RFC 1035 :域名实施和规范

本地缓存刷新会清除接收器缓存吗?

没有这样的结论。记录外部观察环境而不是假设它发生了变化。

错误的选择器是否会破坏原本有效的关键记录?

相关的DKIM查找取决于实际签名的域和选择器。

RFC 6376: DKIM

当另一个策略阻止传递时,身份验证能否通过?

是的。提供商文档将身份验证与其他拒绝类别区分开来。

Microsoft: Exchange Online中的电子邮件未送达报告和SMTP错误

SPF更改会修复无效收件人吗?

他们没有解决接收者的情况。 Yahoo单独记录了它。

Yahoo发件人中心: SMTP错误代码

后来接受是否证明DNS编辑导致了恢复?

如果没有控制和记录其他变化的条件,就无法做到这一点。

这里是否保留了实时DNS答案?

不会。目录所需的带时间戳的权威和递归证据仍然开放。

[ 来源 ]

来源

  1. RFC 1035 :域名实施和规范

    部分 §3.2.1 格式 · §3.3.14 TXT RDATA 格式 · §7.4 使用缓存

  2. RFC 9989: DMARC

    部分 §2.4 超出范围 · §4.1 DMARC基础知识 · §4.3 身份验证机制 · §4.4 标识符对齐说明

  3. RFC 6376: DKIM

    部分 §3.5 DKIM-Signature头字段 · §6.1.3 计算验证

  4. Yahoo发件人中心: SMTP错误代码

    部分 什么是 4XX(421 和 451)临时错误? · 什么是 5XX(553 和 554)永久错误? · 基于内容的块(例如:PH* 错误) · 消息暂时延迟(例如:TS* 错误)

  5. Microsoft: Exchange Online中的电子邮件未送达报告和SMTP错误

    部分 未送达报告中的常见错误代码 · §5.7.23 · §5.7.509 · §5.7.513 · §5.7.520

  6. RFC 5321 :简单邮件传输协议

    部分 §4.2.1 回复代码严重性和原理 · §6.1 通过电子邮件进行可靠的传递和回复

[ 词汇表 ]

词汇表

业主姓名
与资源记录关联的DNS名称。

RFC 1035 :域名实施和规范

TTL
DNS缓存中使用的资源记录生存时间值。

RFC 1035 :域名实施和规范

机制关闭
支持的结论是,特定失败的依赖项按预期更改。
非 DNS 条件
交付因素,例如相关记录查找之外的收件人策略或内容处理。

企业出处

为什么顶级金融机构和政府 退役了他们的电子邮件安全仪表板。

传统的电子邮件身份验证平台会向您出售仪表板并要求您的工程师来完成这项工作。在高风险环境中,手动监督意味着延迟执行、配置漂移和不受监控的影子域。

EmailAuth是代理电子邮件来源平台。 我们的代理人强制执行 p=reject,保持第三方发件人一致并将您的域名移至完整状态 RFC 9989 合规性、新的DMARC标准,以及人机交互审核能力。

政府 大型企业 一级金融机构

SaaS · 专用租赁 · 气隙本地部署 · BYOK 加密

知识库