Exchange 混合部署的邮件流有哪几种路由方式？

官方文档在开头就给出一条重要约束：不要在本地 Exchange 服务器与 Microsoft 365 之间部署会修改邮件的服务器、服务或设备。原因是两个组织之间的安全邮件流依赖邮件中携带的信息来相互识别，中途改写会破坏这一机制。仅在 TCP 25 端口上放行 SMTP 且不做修改的防火墙是受支持的。这条约束解释了大量混合环境中「邮件被当成外部邮件处理」「内部邮件被判为垃圾」类故障的根因——通常就是中间某个安全设备改写了邮件头。文档另说明边缘传输服务器只影响本地组织内部的路由，不影响本地、云端与互联网之间的路由。

一个高频误解是以为混合配置向导会把入站路由也配好。官方明确：混合配置向导不配置来自互联网的入站邮件路由，若要改变入站投递方式，必须手工修改 MX 记录。两个选项各有取舍：MX 指向 Microsoft 365——官方推荐配置，所有邮件先进 Exchange Online 再按收件人位置分发，这也是让云端内置安全能力保护本地组织的必要前提；MX 保持指向本地组织——所有邮件先进本地 Exchange，适合已有本地日记归档方案的组织，但代价是云端内置安全能力无法保护本地收件人。决策依据文档列出三条：邮箱主要在云端还是本地、是否希望用云端内置安全能力保护本地、以及合规基础设施部署在哪一侧。

集中式邮件传输（centralized mail transport）是混合配置向导中的一个选项，默认不启用。以 MX 指向 Microsoft 365 为例：未启用时，Exchange Online 收到发给云端与本地两个收件人的邮件后做分叉（bifurcation），一份直投云端邮箱，另一份发往本地 Exchange 服务器；启用后，Exchange Online 会先把邮件整体路由到本地 Exchange 服务器，由本地服务器做收件人查找与分叉，一份直投本地邮箱，另一份再送回 Exchange Online 投递给云端邮箱。出站方向同理：未启用时云端邮箱的外发邮件由 Exchange Online 直接查 MX 投递互联网；启用后先经 TLS 送到指定的本地 Exchange 服务器，由本地施加合规、防病毒与其他处理后再查 MX 外发。官方态度很明确：仅建议有特定合规需求的组织启用集中式邮件传输，否则通常不推荐——因为它把云端邮件强行绕行本地，增加了链路长度与故障面。

有两条容易被忽略的例外。其一，本地 Exchange 发件人发往互联网收件人的邮件始终通过 DNS 直接投递，与混合配置向导中选择的出站路由选项无关——也就是说集中式邮件传输不改变本地发件人的外发路径。其二，启用集中式邮件传输后，发给同一 Exchange Online 组织内其他收件人的邮件不会绕行本地组织。这两点在设计合规拦截覆盖面时必须算清楚：若合规要求是「所有外发邮件必须经本地 DLP 检查」，那么云端到云端的内部邮件不在集中式传输的覆盖范围内，需要另行在云端侧配置策略。

当 MX 保持指向本地组织时，邮件路径依赖一个额外机制：云端邮箱会拥有一个混合路由（次要）地址，形如 user@contoso.mail.onmicrosoft.com。互联网邮件先到本地 Exchange，本地服务器用全局编录做收件人查找并分叉，投给本地邮箱的那份直接投递，投给云端邮箱的那份则使用该次要地址、通过配置了 TLS 的发送连接器送往 Exchange Online。理解这一点有助于排查两类问题：一是云端邮箱迁移后收不到外部邮件（往往是次要地址缺失或未同步），二是邮件头中出现看似陌生的 onmicrosoft.com 域（属正常混合路由痕迹，不是被劫持）。