确定哪个 Exchange 路由拒绝了邮件
与 Exchange 相关的传递失败不会自动导致 SPF, DKIM 或者 DMARC 问题。在接收者到达操作员预期的认证问题之前，消息可能会因接收者限制、中继许可、大小限制或限制而停止。首先确定产品、路线和剔除系统。仅凭 Exchange 名称并不能区分本地服务器与Exchange Online或涉及两者的混合路径。
本指南使用 2026 年 11 月 8 日审查的 Microsoft 公共 Exchange Server 文档。相关页面标记了 Exchange Server 2016、2019 和订阅版的适用性。该标签并不表明旧安装仍然受支持： Exchange Server 2019 生命周期页面 显示其扩展支持将于 2025 年 10 月结束。在应用任何过程之前记录实际版本和构建。这里没有检查服务器配置或交付测试。
绘制一条具有可观察边界的路线
描述提交应用程序或邮箱、其连接方法、接收连接器、任何传输代理或出站网关、下一跃点和目标收件人。添加提交和最终交付时实际使用的身份。云邮箱仍然可以通过本地组件接收邮件，而应用程序可以完全绕过组织的常用邮箱平台。
对于每个边界，询问哪个系统可以接受、推迟或拒绝该消息以及哪个管理员拥有该决定。保持路线图真实，而不是用假定的产品默认值来填补空白。如果远程中继返回拒绝，则更改不相关的本地邮箱设置可能不会产生任何效果。在未证明路由使用该服务的情况下，不应将Microsoft 365提交或直接发送指令导入到 Exchange Server 诊断中。
读取诊断作为来自特定跃点的证据
将完整的未送达报告保存在批准的位置，然后提取生成服务器、拒绝存在的服务器、受影响的收件人、时间、增强状态代码和说明文本。微软的 NDR 指南 将面向用户的信息与管理员诊断区分开来。生成报告的服务器不必是拒绝原始消息的系统。
不要在没有上下文的情况下解释短代码。广泛的授权失败可能是指中继访问或收件人接受，而不是域身份验证。如果多个收件人失败，请保留他们各自的回复，而不是为整个提交指定一个原因。准备外部升级时保护地址、消息内容和内部主机名；编辑不得删除定位拒绝边界所需的诊断。
将收件人接受与域身份验证分开
微软的 交货限制文件 描述允许和拒绝列表以及需要经过身份验证的发件人的设置。在该配置上下文中，可以排除外部匿名发件人。通过DKIM并不等同于满足 Exchange 的经过身份验证的发件人要求。因此，有效签名不会推翻接收者的权限决定。
建议的调查是让授权管理员检查相关的收件人设置并将其与预期的业务访问进行比较。不要自动删除仅限内部的限制以恢复单个外部邮件。这可能是故意的。例外情况需要接收者所有者的决定、确切的受影响人群以及对由此产生的访问的安全审查。本文既不读取也不更改这些设置。
找到有效尺寸和收件人控件
这 消息大小指南 描述组织、连接器、服务器和邮箱级别的限制。邮箱显示的配额并不是完整的路线范围权利。确定哪些控制适用于消息以及上游或下游服务是否施加其他限制。文档中的默认值并不能证明特定安装中的配置值。
邮件大小也不同于附件大小。 MIME编码、标头和处理可以增加遍历路由的内容； Microsoft 指出大约三分之一的扩展来自 Base64 编码。对于建议的测试，记录序列化消息的大小以及附件的原始大小。收件人计数和标题大小控件是单独的维度。避免同时削弱多个限制，因为这会使原因更难确定并扩大变更范围。
区分限制和永久拒绝
微软的 节流指导 描述对消息处理、连接速率和会话超时的控制。这些控制可以保护服务器容量，并且不会通过发布身份验证记录来删除。队列延迟需要调查相关速率、积压和传输状况，而不是推测性的DNS编辑。
将任何诊断驱动的重试视为已批准的邮件系统行为的一部分。不要重复提交测试消息来查看限制是否最终被清除。如果更改合理，请指定确切的控制、受影响的路线、预期效果和回滚条件。路由可能会遇到传输限制和身份验证缺陷；纠正其中一个并不能证明另一个不存在。
在声明路线固定之前需要受控消息
提议的验证应使用授权接收者和无害内容，将批准的途径与促使调查的诊断进行比较。记录提交结果、相关跳跃证据和最终接收者结果（如果有）。如果身份验证在范围内，请在完整路由之后检查消息，因为后面的网关可以更改或替换签名。一条成功的消息支持观察到的情况，而不是每个收件人、大小或流量级别。
调试条件保持开放：检查当前提供商拥有的指令并测试具体路线。一般产品设置指南是父级；避免重复其基础知识。所需的原始证据是： 包含当前提供商证据和受控测试消息的需求路线图。下面的地图是建议的诊断框架，而不是观察到的客户路线。未发送任何消息，未收集任何DNS应答，且未更改任何权限或限制。技术审查和业主授权必须先于操作补救措施。