微软确认Outlook.com与Microsoft 365邮件延迟，SparkPost记录到临时退信

Microsoft 365 故障 EX1550543：邮件被延迟对发件人意味着什么

简短回答 在故障 EX1550543 期间，Microsoft 以临时 4xx 回复应答复的邮件属于延迟，而非拒收：会排队重试的发件人系统会保留邮件并自行重试，因此只需重发那些已过期并退回的邮件。从 2026 年 11 月 12 日约 17:30 UTC 起，SparkPost 记录到发往 Outlook.com 和 Microsoft 365 收件人的此类回复，包括 451 4.7.0、421 4.3.2 和 451 4.7.700。Microsoft 的公告 MO1550821 首次提及投递延迟是在 11 月 13 日 00:00 UTC，而该事件在 11 月 13 日 09:57 UTC 时仍处于开放状态。11 月 13 日的第一份 Microsoft DMARC 聚合报告到达 DMARCguard 时晚了 5 小时 58 分钟。可通过 MX 查询检查某个收件人是否托管在 Microsoft。

从 2026 年 11 月 12 日约 17:30 UTC 起，各发送服务发现发往 Outlook.com 和 Microsoft 365 地址的邮件在其队列中不断堆积。Microsoft 的服务器并未拒收这些邮件，而是以临时回复应答，我们未找到 Microsoft 针对此情况解释这些回复的文档。

被延迟的邮件并非丢失的邮件：发送服务器会保留它并再次尝试。例外情况是队列在 Microsoft 恢复之前就放弃，以及邮件自身过期，例如一次性验证码。队列多快放弃取决于发送你邮件的系统。在记录了默认值的系统中，重试窗口从 8 小时到 5 天不等。

这与一周前 AS9031519 的退信是相反的故障，建议也相反。

并非 Microsoft 的最新更新。该更新于 2026 年 11 月 13 日 09:57 UTC 发布在 MO1550821 下，状态仍为“服务降级”，并报告“多个工作负载有增量改善”，同时“服务健康状况仍不稳定，容量尚未完全恢复到基线”。它未给出完全恢复的时间。

其 11 月 13 日的更新称 Microsoft“未发现任何导致此事件的恶意活动”，并承诺发布包含根本原因的事后报告。

Microsoft 在其服务健康状态页面上发布公开摘要。Microsoft 365 管理员可在管理中心的“健康 > 服务健康”下获取每次更新：EX1550543 涵盖 Exchange Online，MO1550821 涵盖依赖它的其他服务。我们引用的是该信息源的 Cloud Admin Hub 镜像中的更新，无需管理员账户即可阅读。

电子邮件投递服务 SparkPost 于 2026 年 11 月 12 日 20:01 UTC 公布了其系统从 Microsoft 收到的三条回复。其帖子称“错误包括”这些，因此列表可能不完整。它将开始时间定为“11 月 12 日约 17:30 UTC”，并列出了受影响的目标：Outlook.com、Hotmail、Live、MSN 和 Office 365。

451 4.7.0 临时服务器错误 421 4.3.2 并发服务器连接数已超过上限 451 4.7.700 PFA 代理忙碌

这三条都以 4 开头，而这一位数字才是关键。根据 RFC 5321 §4.2.1，4yz 回复意味着“错误条件是临时的，可以再次请求该操作”，且发送服务器“应重试”。我们查看过状态页面的五家发送服务中，没有一家报告此事件导致永久性 5xx 拒收。

每条回复的其余部分提供的信息比期望的要少：SparkPost 引用的回复文本没有主机名或尾部细节，因此你自己日志中的同一回复可能更长。

故障期间发送给 Microsoft 的邮件在被延迟期间不会丢失。被延迟的邮件留在发件人的队列中，发件人会持续重试，直到 Microsoft 接受它或发件人自身的时间限制到期。只有第二种结果会丢失邮件。如果你的发送仪表板显示某封邮件为排队、延迟或延迟中，这就是它所处的状态。

各发送服务在事件发生时就已说明： 截至 11 月 13 日 04:45 UTC，SparkPost 仍看到“约四分之三发往 Microsoft 的投递尝试”被延迟，并补充说“大部分邮件仍在送达，但比平时更慢”。这是一家提供商的流量，而非全球比率。这些陈述描述的是撰写时仍在排队的邮件，Microsoft 未说明是否有邮件丢失。

Microsoft 关于积压的首次声明出现在其 11 月 13 日 09:03 UTC 的更新中：“我们正在将电子邮件超时窗口延长至 48 小时，以在服务恢复期间帮助保护延迟的邮件”。Microsoft 未定义该窗口。我们的理解是，它涵盖 Exchange Online 内部保留的邮件，其文档记载的重试期为 24 小时。它无法延长他人发送系统上的队列。

当重试窗口关闭时，延迟就变成丢失。RFC 5321 §4.5.4.1 规定，发件人的放弃时间“通常至少需要 4-5 天”。许多发送系统更早停止。截至 Microsoft 11 月 13 日 09:57 UTC 的更新，Mailgun、Postmark 和 Resend 的默认窗口对于 11 月 12 日 17:30 UTC 首次被延迟的邮件已经结束，因此通过其中之一仍未投递的邮件会作为退信或失败事件返回。

阅读表格时请记住其局限性。它只列出文档中写明数字的系统；我们未找到 Google Workspace 或 Amazon SES 的相关数字。这些数字是默认值，其中几个可以更改。Exim 计算的是收件人地址的连续失败，而非单封邮件的存在时间，Postmark 表示某些域有所不同。窗口只对在其中每次重试都失败的邮件有意义。

自身寿命短的邮件在任何窗口关闭之前很久就已无用。SparkPost 告知客户，具有短过期时间的邮件（如一次性验证码）“可能在 Microsoft 恢复之前过期”，Resend 表示如果故障持续时间超过其重试窗口，部分邮件可能会退信。

不要重发尚未退信的邮件。如果你的发送系统会排队并重试（如上表中每个系统所做的那样），邮件仍在其队列中。SparkPost 对其客户的警告适用于其中任何一个：

（原文较长，此处译出前 6000 字，完整内容请点「打开原文」。）