微软365宕机超24小时后基本恢复：邮件还在排队，根因是网络扩容升级埋的雷-北美指南

如果你周五下午打开 Outlook，发现邮箱终于能登录了，先别急着松一口气。从 2026 年 11 月 12 日星期四上午开始的微软 365 全球宕机，到 11 月 13 日星期五下午已经基本恢复，但恢复和彻底结束是两回事。微软当天在 X 上表示，已经解决了导致这次故障的根本问题，正在为剩余的客户和地区恢复服务；微软服务健康页面显示，截至美东时间下午 15:00，包括 Microsoft 365 与 Outlook 在内的全部服务状态均为 operational。换句话说，大门重新打开了，屋里积压的东西还在一样一样往外搬。

这篇文章不重复宕机第一天的经过，只讲你现在最关心的三件事：恢复到底到了哪一步、这次到底为什么会坏、以及你今天之内必须亲自核对什么。因为这场宕机的后半段比前半段更考验人：系统绿灯亮起之后，真正决定你有没有损失的，是那些卡在队列里的邮件和日历邀请。

恢复到了哪一步：服务亮绿灯，邮件还在追赶

微软的说法分了两层。第一层是根本问题已经解决，也就是不再有新的故障在产生；第二层是恢复服务仍在推进，覆盖剩余的客户和地区。服务健康页面在美东时间 15:00 的状态是全部 operational，这是一个重要的转折点，意味着微软认为核心服务已经回到正常运行区间。但 operational 这个词描述的是服务本身的状态，不是你收件箱的状态。邮件系统恢复运转之后，宕机期间积压下来的邮件要按队列依次投递和处理，这个过程需要时间，微软的说法是投递与处理仍在追赶。

对普通用户来说，最直观的感受可能是这样的：登录没有问题了，收件箱里开始陆续出现新邮件，但有些你一直在等的邮件迟迟不到；发出去的邮件对方说没收到，或者你自己发出的邮件在已发送里躺了很久才真正发出。这不是你的网络问题，也不是你的账号出了问题，而是整个投递链条正在消化积压。队列排空的速度取决于积压量和各地区的恢复进度，不同用户感受到的延迟并不一致，有人几小时就恢复正常，有人要等更久。

故障报告数说明了什么：从约 13 万份掉到约 1600 份

Downdetector 上的用户报告数量，是观察这次恢复进度最直观的公开指标。宕机开始时，Outlook 的故障报告一度达到约 13 万份；到 11 月 13 日星期五美东时间 14:50，Outlook 的故障报告约为 1600 份。Microsoft 365 的报告约为 700 份，峰值时接近 5 万份。报告量下降了两个数量级，说明绝大多数用户已经恢复正常使用，或者至少不再遇到足以让他们去上报的故障。

不过，报告数字也要辩证地看。Downdetector 统计的是主动上报的用户，数字下降首先说明大规模中断已经结束，但它不能证明每一个人都恢复了。剩下的约 1600 份 Outlook 报告，恰恰对应微软所说的剩余客户和地区，也就是恢复的长尾部分。如果你正好在这部分人里，你的体验可能和已经恢复的大多数人完全不同。所以不要只看大盘数字做判断，真正可靠的办法是亲自核对自己的邮箱和日历，后面会给出具体清单。

还有一个细节值得注意：这次宕机的编号是 EX1550543（Exchange Online）和 MO1550821。如果你是企业用户或者需要向微软支持提交工单，报出这两个编号，支持人员能直接定位到这次事件，而不用你再从头描述故障现象。个人用户虽然一般用不上工单，但知道事件编号也有助于你在微软服务健康页面或者状态更新里确认自己遇到的到底是不是同一件事。

根因终于说了：早前一次网络扩容升级埋的雷

微软给出的根因解释并不复杂：问题是在早前一次网络容量升级中引入的，在最近一次网络变更之后暴露出来。用大白话说，就是上一次扩容的时候埋下了一个隐患，当时没有发作；最近一次网络改动把它触发了，于是整个 Exchange Online 相关的服务链条被拖垮。微软同时明确了两点：这次故障不是网络攻击，与人工智能也没有关系。

这个说法之所以重要，是因为它排除了两种最容易引发恐慌的猜测。第一，这不是外部攻击，意味着你的账号和邮件内容没有因为攻击而面临额外的泄露风险，至少就微软目前的说法而言是这样。第二，这与 AI 无关，近来不少人把微软的故障和 Copilot、AI 基础设施的扩张联系起来，微软的表态直接否定了这种关联。完整的、正式的事后报告还要等微软后续发布，里面应该会包括更具体的技术细节和时间线。在那份报告出来之前，上面这段根因描述就是目前最权威的版本。

从用户角度看，根因的性质也决定了这次恢复的特点。这是一次基础设施层面的故障，而不是某个单一应用崩溃，所以它的影响面才这么广，从 Outlook 到依赖 Exchange Online 的日历、排程和部分聊天功能都被波及；同时也正因为根因定位在网络层，修复之后需要逐地区、逐服务地恢复和排空积压，这就解释了为什么服务状态先亮绿灯，而邮件投递还要再追赶一段时间。

受影响最大的是什么：Teams 核心功能基本没事，疼的是日历和排程

这次宕机里有一个容易被误解的点：很多人以为 Teams 也全线瘫痪了。实际情况是，Teams 的核心聊天与在线会议大体上没有受到影响，真正受影响的是依赖 Exchange Online 的那部分功能，主要是日历、排程，以及部分聊天功能。这也是为什么有些用户周五开会一切正常，却发现会议邀请发不出去，或者收到的邀请时间对不上。

对上班族来说，这种错位比彻底断网更麻烦。彻底断了，你知道要等；半好半坏，你就得逐项核对：这场会到底约上了没有，对方收到的时间是不是你以为的时间，取消的会议有没有真正取消。如果你周四下午到周五期间发出或者收到过会议邀请，尤其要把这几项过一遍。跨时区的会议更要当心，因为 Exchange Online 出问题期间，日历同步可能出现延迟，邀请上的时间未必是你发出时的原意。

48 小时窗口是什么意思：微软给延迟邮件留的活路

微软这次做了一个对用户很实际的安排：把邮件投递的超时窗口延长到了 48 小时。正常情况下，一封邮件如果在一定时间内投递不出去，系统会判定投递失败并退回给发件人。宕机期间，大量邮件卡在队列里，如果按正常超时规则处理，很多邮件会被直接退回，发件人收到退信，收件人永远不知道有这么一封邮件存在过。

延长到 48 小时，等于给这些卡在路上的邮件多争取了一天多的时间，让它们有机会在队列排空之后正常投递，而不是被当作死信退回。对你来说，这个安排有两个实际含义。第一，如果你在宕机期间发出过重要邮件，不要只看对方有没有回复，还要确认邮件到底发出去了没有；如果对方一直没收到，而你又没收到退信，邮件很可能还在队列里，再等一等或者重发一封更稳妥。第二，如果你一直在等一封重要邮件，而对方说已经发了，也别急着让对方重发，先确认对方有没有收到退信，再决定要不要重新发送。

个人用户今天要做的核对：按这五项过一遍

系统恢复之后，最容易吃亏的不是登录不上去的人，而是以为自己已经恢复、实际上还有东西卡住的人。建议你花十分钟，按下面五项核对一遍。

等一封重要邮件的人：先问发件人是否收到退信。如果对方没有收到退信，邮件大概率还在队列里，可以再等一段时间；如果对方收到了退信，或者超过 48 小时仍无音讯，请对方重新发送。
宕机期间发过邮件的人：检查已发送文件夹，确认重要邮件的状态；对没有收到回复的关键邮件，主动和对方确认是否收到，必要时重发一次，并在正文里说明这是重发，避免对方收到两封产生混淆。
收发过日历邀请的人：逐个确认周四下午以来发出和收到的会议邀请，核对时间、参会人和会议链接是否正确；跨时区会议要逐项确认，取消或改期的会议也要确认对方收到了更新。
用 OneDrive 同步文件的人：检查同步状态，确认宕机期间修改过的文件已经同步完成；如果看到同步冲突或者文件版本不一致，先不要覆盖，确认哪一份是最新的再处理。
用 Outlook 规则和自动回复的人：如果你在宕机期间设置或修改过自动回复、邮件规则，确认这些设置现在仍然生效，规则没有因为服务中断而被跳过或错乱。

做完这五项，你才算真正从这次宕机里走出来。特别提醒一点：不要把没有收到回复简单理解为对方没看到。宕机期间的沟通断层可能让对方以为你没发、你以为对方没回，这种双向误会是故障之后最常见的次生问题，主动确认一次就能避免。

企业用户与 IT 管理员：这几项不要等到周一

如果你是公司的 IT 管理员，或者负责团队的邮箱管理，恢复之后的核对工作要更系统一些。先在微软服务健康页面确认你所在租户的服务状态，再检查邮件队列和投递报告，确认积压邮件的排空进度。对于在宕机期间发出的批量通知、账单、合同和 Offer 等关键邮件，建议逐批确认投递状态，必要时安排重发，并提前告知收件方可能收到重复邮件。

其次是日历与会议室预定。依赖 Exchange Online 的会议室预定和排程功能在宕机期间可能出现延迟或错乱，建议核对未来几天的会议室占用情况，避免出现重复预定或者预定丢失。最后是把这次事件的编号 EX1550543 和 MO1550821 记下来，连同微软后续发布的事后报告一起归档。如果公司有合规或者审计要求，这份记录就是这次服务中断的官方依据。