域身份验证策略不会授权应用程序使用您的邮件中继。中继授权控制谁可以提交邮件以及邮件可以发送到哪里； SPF, DKIM 和 DMARC 帮助接收者评估生成的消息身份。两者都需要。签名精美但接受任意发件人的路由仍然存在操作和滥用风险。
选择支持的路线
记录应用程序、租户、提交端点、身份验证方法、预期身份和接收者类别。 Microsoft 区分了客户端SMTP提交、连接器验证的SMTP中继和直接发送。其记录的直接发送路由不会通过Microsoft 365中继到 Internet 收件人，而支持的SMTP中继可以。这些是特定于产品的区别，而不是通用的SMTP术语。 Microsoft 应用程序电子邮件指南.
根据实际工作负载选择当前支持的方法。避免将旧设备配置复制到不同的租户或将 IP 允许条件视为应用程序身份的永久证明。记录谁拥有凭据、证书、网络限制和连接器更改。不要仅仅为了简化故障排除而泄露测试证据中的秘密或扩展持久访问。
提交与最终验证分开
SMTP事务显示哪个阶段接受或拒绝命令。 RCPT TO 处的拒绝与消息数据后的失败不同，最终成功的 DATA 响应意味着接收者接受了对消息的责任，而不是证明收件箱位置。 RFC 5321。保留完整的回复代码、增强代码（如果存在）、文本和时间戳，而不是减少每次失败的阻止。
然后检查授权接收的消息的实际信封和签名域。中继可以重写身份或应用更改身份的签名 结盟 结果。 SPF评估相关连接路由，而不是用户对发件人属于该公司的信念。不要假设提交成功就是DMARC通过或通过是收件人同意的证据。
比较三个假设阶段的结果
使用包含三个独立案例的书面验收分类账：未经批准的外部接收者请求预计将在 RCPT TO 被拒绝；经批准的外部路线预计会达到可接受的最终数据响应；并单独检查批准的内部路线。说明性答复可能是收件人拒绝时的 550 5.7.1，或 RCPT TO 时的 250，对于 DATA 的 354，以及在已接受交易的最后一个点后的 250。这些是假设的回复序列，不是捕获的环回或 Microsoft 转录本。
一位客户的 EHLO 名称不是授权证明。真正的中继权限必须使用该部署支持的身份验证和连接器控制。这里没有执行凭证验证、连接器查找、本地套接字、 TLS会话或提供程序发送。在未来的授权测试中记录实际的响应代码和上下文，而不是将这些预期示例视为观察到的结果。
测试允许和拒绝的情况
对于批准的部署，请使用受控收件人来测试预期的内部和外部路径。包括来自客户端的明确授权的负面测试，该测试不应转发，而无需探测不相关的系统。保留经过消毒的笔录和提供者日志，同时将原始证据置于访问控制之下。确认拒绝发生在预期的位置，并且无法通过备用申请途径绕过。
在关键工作流程依赖于中继之前检查限制、队列行为并重试所有权。短暂的拒绝不应导致快速重试风暴，而永久性的配置故障则需要负责任的修复。记录后备要求，而不授权无限制的旁路。
使用中继访问、支持的收件人范围、最终消息身份验证和应用程序成功的单独结果来结束更改。将缺失的观察结果标记为未解决。这可以防止团队仅仅因为DNS看起来正确或一个SMTP命令返回成功代码而声明应用程序正常运行。
源和执行边界
RFC 9989第 4.4、5.3.5 和 5.4 节 区分认证、对齐和处理；通行证并不认可消息内容。这里的运营决策是范围内的建议和明确的假设示例，而不是对客户、提供商或历史固定装置的新测试。任何真正的改变都需要有自己的授权范围、保留的证据和负责任的决定。