本文要点
- 官方原帖只确认外部域邮件收发延迟、原因已定位且缓解正在应用；公开帖没有披露根因、影响地区或完成时间。
- 先保留发件人、收件人、主题、发送时间、Message-ID、NDR 和业务单号，避免用重复发送制造重复通知、订单或账单。
- 用内部到内部、内部到外部、外部到内部三组最小测试确定边界，再在 Exchange 管理中心运行 Message trace。
- Message trace 的状态可能比实际处理晚 5–10 分钟；短时间内没有结果不能直接证明邮件未进入 Exchange Online。
- 官方事件期间不要无证据修改 MX、SPF、连接器、传输规则或代理出口；这些变更会污染定位并可能制造第二个故障。
- 固定出口只能让管理后台访问和复测条件保持一致，不能修复 Microsoft 365 服务端邮件队列。
官方边界：20:37 披露 EX1467029，缓解正在应用
@MSFT365Status 在北京时间 2026 年 9 月 4 日 20:37 发布 EX1467029：用户向外部域发送和从外部域接收邮件时可能遇到延迟；微软称已经确定原因，正在应用预计很快完成的缓解。公开原帖没有给出根因、受影响租户比例、地区、邮件积压量或准确恢复时间。
公开 X 帖是事件信号，不是租户级状态的替代品。管理员应登录 Microsoft 365 管理中心，在 Health 中查看 Service health 和 EX1467029 的租户范围更新；没有管理员权限的用户应把样本时间与 Message-ID 交给本组织管理员。
先止损：不要反复点发送或立刻改域名配置
对订单确认、登录验证码、客服回复、发票、付款和跨境店铺通知，先暂停自动重试扩容。把任务标为已确认送达、明确失败、仍在等待、结果未知四类；结果未知的邮件不要直接重新发送，否则缓解后原邮件与重试邮件可能一起到达。
每个样本至少记录发件人、收件人、主题、北京时间、Message-ID、是否出现 NDR、客户端和对应业务单号。截图与工单应脱敏，不公开邮箱地址、邮件正文、客户身份、订单号或认证信息。
三向测试矩阵：先确定是不是只影响外部域
选择不会触发订单、付款或自动化的唯一测试主题，分别测试同租户内部到内部、Microsoft 365 内部到外部域、外部域到 Microsoft 365。每组只发一封，记录发出时间、首次出现在 Message trace 的时间、到达时间和最终状态。
如果内部邮件正常，而两个跨域方向同时延迟，现象与官方事件范围一致；如果只有单一域、单一连接器或单一发件人失败，则不能只归因于 EX1467029。出现明确 NDR、550、SPF、证书或连接器错误时，按错误层级单独处理。
Message trace：看 received、pending、failed 与 delivered
在 Exchange 管理中心进入 Mail flow > Message trace，以发件人、收件人、时间段或完整 Message-ID 查询。微软文档说明，Message trace 可以判断服务是否收到、拒绝、延迟或交付邮件，并显示在最终状态前发生的处理动作。
新邮件的 trace 数据通常会有 5–10 分钟延迟，因此刚发送就查不到不是重发依据。重点记录状态、事件时间、方向、连接器名称和 Network Message ID；如果 trace 显示 delivered，但用户收件箱不可见，再检查垃圾邮件、隔离、转发、传输规则与收件端系统。
把微软服务故障、域名配置和代理网络分开
服务故障证据包括 EX1467029 覆盖当前租户和时间、多个外部域同时延迟、Message trace 出现一致的 pending 或 transport 延迟。域名配置问题通常集中在某个域，并伴随 MX、SPF、证书、连接器或 NDR 证据；微软官方建议在 Exchange 管理中心验证连接器，并分别检查 SPF 与 MX。
代理或本地网络问题主要影响用户能否访问 Outlook、Exchange 管理中心或解析与连接目标地址，它不能修复已进入 Microsoft 365 传输管道的邮件积压。只有 DNS、TLS、连接超时或代理 407 等独立证据时，才进入<a href="/resources/proxy-connection-troubleshooting-checklist" target="_blank" rel="noopener noreferrer">代理连接排查清单</a>；排查期间保持同一设备、同一账号和同一固定出口。
业务连续性：为跨境订单与验证码准备备用通道
对有时限的订单、付款、账号验证和客户支持，先在站内通知、已备案工单或其他已验证通道提示“邮件可能延迟”，不要把敏感订单信息发到公开社交平台。备用通道只用于传递状态和下一步，不绕过原有身份验证。
暂停依赖“收到邮件即继续”的自动化，保留事件 ID、业务幂等键和原始发送记录。若邮件关联订单、退款、密码重置或账号权限，恢复前必须先查询业务系统状态，不能把收件箱暂时没看到当作动作未执行。
恢复门槛：官方更新后仍要等队列排空
缓解完成或事件标记恢复后，先观察旧邮件是否陆续到达，再用新的唯一主题做三向测试。至少确认 Service health 更新、Message trace 不再持续 pending、跨域测试到达时间回到团队基线，才逐步恢复批量通知与自动重试。
若官方恢复后只有一个域仍失败，转入该域的 DNS、SPF、连接器、证书、规则或收件端排查；若管理后台也只在某个网络打不开，再用固定出口做对照。需要保持可复验的后台网络环境时，可<a href="/" target="_blank" rel="noopener noreferrer">访问 PuppyIP 官网</a>了解静态住宅 IP，但不要把换 IP 写成 Exchange Online 服务故障的修复步骤。
资料来源
常见问题
EX1467029 影响什么？
微软公开帖称，部分用户向外部域发送或从外部域接收邮件时出现延迟。公开帖没有说明所有租户、所有地区或内部邮件都受影响。
邮件没到，可以马上重发吗？
先查 Message trace 并保留 Message-ID。结果未知时直接重发，可能在队列恢复后造成重复通知、验证码、订单或账单。
为什么 Message trace 里暂时查不到刚发的邮件？
微软文档说明 trace 状态相对实际处理可能晚 5–10 分钟。等待该窗口后再查询，并使用完整 Message-ID、发件人、收件人和时间段缩小范围。
需要修改 MX、SPF 或连接器吗？
不要仅因官方事件就修改。只有单一域异常、明确 NDR、DNS 或连接器验证失败等证据出现时，才做范围明确且可回滚的配置变更。
换代理或换 IP 能恢复跨域邮件吗？
不能修复 Microsoft 365 服务端传输延迟。固定出口可用于保持管理后台访问与复测条件一致，但只有 DNS、TLS、连接超时或 407 等网络证据时才应排查代理。
微软说缓解完成后就能全量补发吗？
不建议。先确认旧队列是否排空、Message trace 是否回到基线，并用三向小样本验证；对结果未知的业务邮件先对账，再分批恢复。