将拒绝中继视为权限问题
中继拒绝响应意味着接收服务不允许在观察到的条件下尝试进行操作。它本身并不能识别错误的密码、 SPF 缺陷或丢失的邮箱。在进行任何更改之前，请确定哪个服务拒绝了哪个收件人的哪个SMTP步骤。确切的端点和响应比应用程序缩短的“邮件失败”通知更有用。
保留完整的基本SMTP回复、增强状态代码（如果存在）、诊断文本、响应主机、时间戳和命令阶段。记录认证过程中是否发生拒绝， 邮件来自、RCPT TO 或消息数据之后。保留可以支持授权调查的提供商请求标识符，但从共享票证中删除秘密和不必要的消息内容。
将重试类别与诊断分开
第一个SMTP回复数字提供广泛的操作语义。 4xx 回复是暂时的否定完成； 5xx 回复是对尝试请求的永久否定完成。这两个类都无法识别被拒绝的权限。增强的代码添加了类别、主题和细节，但它们的含义仍然需要完整的诊断和提供者上下文。 RFC 5321 ，第 4.2.1 节 和 RFC 3463 ，第 2 节.
不要重复重新提交未更改的永久拒绝的交易。短暂的响应也不能证明立即重复尝试是合理的。在调查时使用负责任的邮件系统的有限重试策略。 4xx 条件可能涉及路由、资源或其他临时问题，而不是身份验证。保持状态并完整回复可以避免将每次失败变成密码重置请求。
将端点与其预期角色相匹配
使用邮箱提交服务的应用程序必须满足该服务的提交要求。基于连接器的继电器必须符合组织授权的连接器条件。直接入站路由可以接受本地收件人，而无需授予转发到其他地方的许可。微软当前的应用程序邮件指南区分了这些路由；其直接发送选项不通过租户向外部收件人提供递送服务。 Microsoft 应用程序邮件设置.
在编辑设置之前构建短路由记录：配置的主机、实际响应主机、端口、源网络、身份验证模式、发送者身份和接收者类别。将其与预期设计进行比较。不要尝试任意公共SMTP服务器来查看哪一个接受邮件。可到达的服务器不是授权中继，成功接受并不意味着使用它是合法的。
狭隘地使用提供商诊断
Microsoft 的故障排除页面识别出带有 TenantAttribution 和 Relay Access Denied 的增强代码 5.7.64，并且还讨论了发送到错误区域的邮件的 4.4.62。在该记录的上下文中，更改的公共 IP 或证书可以阻止租户归属。同一页面将 5.7.60 与“代理发送”权限相关联。这些例子有助于选择调查部门；它们并不意味着每个 5.7.x 响应都有相同的原因。 Microsoft 设备和应用程序故障排除.
该故障排除页面的日期为 2025 年 6 月，包含较旧的身份验证解决方法。不要按照建议禁用 MFA 或安全默认值作为一般修复。使配置与较新的设置指南和组织的安全策略保持一致。该草案没有规定基本身份验证停用日期、假设已启用功能或声明当前租户接受旧方法。
用一个虚构的事件追踪被拒绝的权威
想象一个虚构的应用程序，其外部通知在网络切换后停止。其预期设计使用基于 IP 的连接器。调查数据包包含中继归因诊断，但没有新的公共源观察。有用的下一步是让网络所有者和邮件管理员使用批准的只读证据将实际出口身份与授权连接器进行比较。该示例并未表明任何地址已更改或允许修改连接器。
现在改变虚构的事实：内部收件人工作，应用程序从未有连接器，只有外部收件人失败。这指向路由范围问题，而不是相同的网络更改诊断。第三种情况可能成功提交身份验证，但由于不同的发件人身份而出现发件人权限错误。诊断分支必须保持独立，以便在一种情况下进行方便的修复不会扩大在另一种情况下的权限。
将授权和可交付性分开
SPF出版物描述了SPF身份允许的发送基础设施；它不会指示任意SMTP服务进行中继。相似地， DKIM 签名和 DMARC 结盟 不授予邮箱“代理发送”权限。修复错误的图层可以使原始拒绝保持不变，同时创建新的曝光。在提出小范围更正之前，使用路线到需求图来识别被拒绝权限的所有者。 RFC 7208 ，第 2.4 和 4.1 节.
更正可能涉及批准的端点、授权的发件人身份或管理员审核的连接器匹配。它永远不应该“允许所有人”、发布凭据、未经审查禁用保护策略或通过不相关的公共中继重新发送。在任何授权更改之前记录旧状态、预期权限和预期收件人范围。
重新测试一笔有界交易
在授权相关更改后，使用经过批准的测试收件人和可识别的非敏感消息。保留完整回复和下游处置。如果服务器在消息数据后给出肯定的完成回复，则它承担传输责任；这与收件箱送达证明不同。如果连接在最终答复之前关闭，请在生成另一条应用程序消息之前确定结果，因为传递可能不确定。 RFC 5321 ，第 4.2.5 和 6.1 节.
包含当前提供商证据和受控测试消息的需求路线图。这一确切的目录要求仍然开放。未检查或更改任何权限、连接器或凭据，也未发送任何中继探测或测试消息。诊断分支是建议的检查，而不是特定于帐户的结果。