通过Microsoft 365发送的应用程序需要受支持的邮件路由以及正确的身份验证。客户端SMTP提交、基于连接器的SMTP中继和直接发送使用不同的信任和收件人模型。
变更前确定路线 SPF, DKIM 或者 DMARC。 DNS可以描述发送依赖性，但它无法将不受支持的路由转变为授权中继或使 Direct Send 传送到外部收件人。
记录应用程序需要做什么
识别应用程序的托管位置、发件人身份、预期收件人以及支持的身份验证和传输功能。记录负责的业务服务和管理员。
将组织内部的设备与第三方托管应用程序区分开来。检查该托管模型的当前 Microsoft 指南，而不是假设每个产品都可以使用相同的连接器。
当外部收件人属于业务工作流程时，包括对外部收件人的单独测试。仅限内部的成功并不能建立外部交付路线。
比较支持的路由
Microsoft 当前的设置指南区分了以下方法：
客户端SMTP提交使用经过身份验证的云邮箱，并支持内部和外部收件人。
SMTP中继使用入站连接器，并且可以在满足其先决条件时进行外部中继。
直接发送是内部收件人传送，而不是互联网中继。
大容量电子邮件是使用 HVE 帐户的单独内部收件人服务，而不是外部递送替代方案。
将此比较视为选择帮助，而不是完整的配置或许可规范。重新检查当前第一方说明中适用的身份验证支持、网络访问、限制和先决条件。
不要仅仅因为较旧的设备指南显示了已弃用或不合适的身份验证方法就启用它。选择应用程序和当前服务实际支持的路由。
使用SMTP中继之前了解连接器信任
Microsoft 为其SMTP中继安排记录了基于证书或基于公共 IP 的身份验证。网络和托管要求很重要。
基于证书的路由需要在证书配置中适当的接受域关系。基于 IP 的路由取决于 Microsoft 可见的公共地址，而不是设备上显示的私有地址。
Microsoft 当前的指南将第三方托管的应用程序（例如 Azure 托管的服务）排除在此SMTP中继安排之外。在使用 IP 身份验证的情况下，地址必须是静态的并且不与其他组织共享。仔细检查共享地址和托管限制。为组织外部共享的基础设施创建 IP 连接器可能会创建与管理员预期不同的信任范围。
使用 Microsoft 生成或验证的MX端点和当前连接器过程。请勿从缩短的域名创建端点或复制其他租户的设置。
不要将直接发送与外部中继混淆
Direct Send 不向基于云的组织之外的收件人提供递送服务。 Microsoft 的指南将其视为具有相关邮件服务器职责和适当限制的高级客户的一个选项。
在综合示例中，扫描仪成功发送给员工，但在工作流添加客户的外部地址时失败。该症状与接收范围不包括外部中继的路由一致。
添加SPF包含无法更改该收件人范围。在编辑不相关的记录之前，请重新评估路线和申请要求。
选择路线后验证身份
参考： RFC 9989 §4.4.
配置支持的路由后，检查从实际应用程序接收到的消息。记录可见的发件人、评估的SPF身份、相关的DKIM签名和可信的DMARC结果。
连接器对连接的接受和接收者的一致身份验证结果建立了不同的事物。出站网关或附加中继也可能影响最终结果。
使用Microsoft 365身份验证指南进行域设置，并且 结盟 原始通道不匹配的诊断。
保留特定路线的验收记录
保留所选择的方法、托管模型、信任机制、接收者范围、所有者和代表结果。包括确切的提供商说明和配置日期，以便以后的管理员可以识别更改的要求。
分别记录认证失败和发送失败。被拒绝的连接、不受支持的收件人路由以及接收到的未对齐消息可能需要不同的更正。
完整的结果是受支持的应用程序路由，具有可靠的信任和经过验证的消息，而不仅仅是有效的 TXT记录 或成功的内部测试。