刚刚过去的周五（2026年11月13日），必将是Microsoft 365（Office 365）商用以来最值记得铭记的日子。受 Exchange Online 及 Exchange Online 关联服务故障EX1550543和MO1550821影响的Microsoft 365的全球用户都喜提了一个“No-Email Friday”，合法摸鱼的Officer积极地参与到了Microsoft 365到底会变成了Microsoft 364还是Microsoft 360的竟猜当中。
如今故障已缓解，大多服务已恢复，微软已经确认根因，它的股价还以奇怪的是微涨收盘，作为邮件管理员，除了继续通过已经无数次刷新的以下页面了解进展：
https://status.cloud.microsoft/m365/referrer=serviceStatusRedirect
我们接下来要做什么呢？答案是：
了解问题影响与原因，检查是否依然存在邮件积压。
一、故障影响
1、最直接受影响的是使用Exchange Online邮箱的用户，故障期间所有可知连接方式均受到了不稳定的连接影响。包括：
- Outlook on the web（OWA）
- Outlook Desktop / MAPI
- Exchange ActiveSync
- REST API
2、除了影响使用Exchange Online邮箱的用户自身访问邮箱，相关的本地Exchange Server及第三方邮件系统往Exchange Online邮箱用户的邮件传输同时样受影响，包括：
本地 Exchange Server 与 Exchange Online 之间存在邮件流量，这意味着 不仅是混合部署环境，非混合部署Exchange Server 受到波及，另外，其它第三方邮件系统往Exchange Online用户发送的邮件，也因流受阻受到了影响，甚至收到延迟投递的通知。
二、确认的根因
11 月 13 日 17:57 UTC 的状态更新中，微软明确说明：
此次事故与网络容量升级期间出现的问题有关，该问题在后续网络变更之后暴露。
微软表示：
- 已经处理了底层问题。
- 正在逐步恢复剩余受影响区域。
- 采取分阶段恢复方式，逐步验证基础设施稳定性。
- 后续将发布完整的 Post-Incident Report。
微软还特别说明:
这次是技术问题，与网络攻击或 AI / Agent 无关。
对，没有依所有人所想：不是受到网络攻击，与AI也无关。我本人也没有其它可提供的内幕消息。
三、最新状态
微软最新的更新显示：
- 之前受影响的环境已经出现持续恢复。
- 微软正在延长监控时间。
- 邮件服务恢复后，仍需继续处理事故期间积累的邮件队列。
- 只有确认积压邮件均已成功处理，才会考虑正式关闭事件。
因此，截至当前：
这次故障依然没有标记为完全解决。
四、邮件管理员该做什么？
Outlook 登录恢复并不意味着邮件传输已经完全恢复。服务访问和邮件积压处理是两个不同的恢复阶段。根据前述故障影响中描述，无论是否为混合环境，是否为Exchange Server都可以受到邮件流受阻的影响，生成积压邮件队列，而不同邮件系统对邮件队列的处理方式可能会有差异，接下来邮件系统管理员可以：
主动检查自己的邮件系统中是否存在往EOP的积压邮件队列，并适当的修改队列重试次数和失败时间。
以Exchange混合部署环境及纯本地Exchange Server环境为例 ，可使用以下命令检查本地 Exchange 邮件队列：
Get-Queue | Sort-Object MessageCount -Descending | Format-Table Identity,Status,MessageCount,NextHopDomain
如果存在发送到 Exchange Online 的队列存在积压，需要结合微软服务状态判断是否属于云端恢复过程中的延迟，同时检查：
- Exchange Online Message Trace。
- 本地 Exchange Message Tracking Log。
- Send Connector 的下一跳状态。
- 服务器是否存在额外的 DNS 或连接故障。
如果您有问题，欢迎留言或是到5DMail专属微信群来讨论！
