Exchange Online EX1550543: Delayed Mail, Hybrid Impact and Recovery Guidance

The incident: what Microsoft has confirmed​

Microsoft titled the incident "Users may be unable to connect to their mailboxes in Exchange Online through multiple connection methods." Several sources give the same start time. The Exchange Online incident, tracked as EX1550543, was opened at 16:17 UTC on Thursday 12 November. A wider notice, MO1550821, covers the rest of the suite.

The first public message was limited to one region. Microsoft said it was investigating reports of users having trouble accessing Exchange Online mailboxes "through multiple connection methods in the Americas." That did not last. Although the first reports covered the Americas, Microsoft later confirmed that users in any region could be affected.

The affected access routes are why this was not a minor problem. Microsoft listed Outlook on the web, MAPI, Exchange ActiveSync and the REST API as potentially affected connection methods. That covers browser access, desktop Outlook, phones and API-based integrations. When all of those fail together, the cause is almost certainly on Microsoft's side, not in your network, your Outlook profile or your firewall. That is an inference from the range of affected methods, not a confirmed root cause. It still helps if your helpdesk is about to spend the morning rebuilding Outlook profiles.

Other services were affected too. MO1550821 was opened at 18:26 UTC for the services that depend on Exchange Online. According to Cybersecurity News, reported impact covers Outlook, Teams, SharePoint, Copilot and Microsoft Defender XDR, although the exact service and feature restrictions are still subject to Microsoft's updated advisory. PPC Land puts the number of affected services at 19, and earlier WindowsForum coverage used the same figure. Microsoft has not published a single count. The safest summary is that Exchange was the main service affected and that features built on top of it were also disrupted.

Section summary: Use EX1550543 for mailbox access and MO1550821 for dependent services. The outage started in the Americas, spread more widely, and was still listed as degraded on the morning of November 13 UTC.

How the explanation changed over the night​

Microsoft's updates, preserved in a public mirror of the service-health feed, show the investigation in real time, including some changes of direction:

• 17:45 GMT: Connectivity errors were found on part of the Exchange Online infrastructure that receives and processes user access requests. Networking logs were collected.
• 18:29 GMT: Some traffic was moved away from affected US infrastructure. Microsoft said Exchange was the main service affected and that other Microsoft 365 services had connectivity problems, tracked under MO1550821.
• ~19:06 GMT: Microsoft paused all deployments and configuration changes.
• 19:18 GMT: Microsoft said the high load did not come from an overall rise in traffic. A large number of servers had become unexpectedly unavailable, which pushed load onto the remaining servers.
• 19:43 to 19:57 GMT: Affected servers were failing automated health checks. Microsoft first suggested a recent change to the health-check component might be involved, then said it had found no recent change that matched the start of the impact. It began testing a way to bypass that component.
• 20:56 GMT: An alternative health-check method returned a subset of servers to service. Microsoft also prepared an automated process to detect and restart unresponsive servers.
• Overnight: Servers that came back healthy became unresponsive again once traffic returned. Microsoft then said a process on the affected servers "responsible for establishing secure connections" was being overwhelmed. It began reverting a recent network configuration change that matched the start of the impact, despite saying hours earlier that it had found no such change.
• Friday, 02:54 UTC: The change was not working as expected, and Microsoft began looking at other ways to add capacity.

By the early-morning updates on November 13, the picture was better but recovery was not complete. Microsoft reported improved server stability after applying a patch to an "upstream authentication/routing configuration component." It said it was rolling the patch out first to regions in or entering business hours, and it had added virtual-machine capacity. Its latest retrieved update reported early signs of stabilization. It said capacity had not returned to normal and that health remained uneven as traffic was carefully reintroduced. The next update was promised by 10:00 UTC on November 13.

Two details in those late updates matter to admins:

• Delayed mail is being held, not discarded. Microsoft said it was extending the email timeout window to 48 hours to protect delayed messages during recovery. Nothing in the evidence suggests messages were lost. Expect delayed delivery, not missing mail.
• Hybrid shops are affected too. Microsoft warned that on-premises mail flow may be affected if it goes to or from Exchange Online.

On the security question, Microsoft has said repeatedly that it is not aware of malicious activity causing the incident. PPC Land attributes a similar public statement to Microsoft executive vice president Charles Lamanna on X. Microsoft has committed to a full Post-Incident Report with the root cause and defense-in-depth fixes after recovery. Until it is published, any single explanation is still provisional.

Section summary: Microsoft's stated cause moved from traffic load, to failing health checks, to an overwhelmed secure-connection process, to a possible network configuration change. The final answer depends on the Post-Incident Report.

What admins should do right now​

There is no tenant-side fix for a provider-side outage. Your job is to track it, communicate clearly and keep evidence.

• Track the right incidents. Microsoft's Q&A guidance says to open the Microsoft 365 admin center → Health → Service health → Active issues Microsoft is working on, then select EX1550543. Check MO1550821 for Teams, SharePoint, Copilot and other dependent features.
• Have a backup status channel. Sign-in and admin-center pages may be affected too. If you can't get into the admin center, Microsoft posts the same updates on status.cloud.microsoft and on the @MSFT365Status account on X.
• Report it if your tenant isn't listed. If EX1550543 is not listed for the tenant, use Service health → Report an issue so Microsoft can correlate the report with other affected organizations.
• Don't troubleshoot clients. Resetting Outlook profiles, re-registering ActiveSync devices or changing MX records will not fix a server-side capacity problem, and some of those steps add work later.
• Watch hybrid queues. If you run on-premises Exchange in hybrid mode, monitor outbound queues to Exchange Online. Delayed mail should drain as capacity returns, especially with the 48-hour timeout extension.
• Keep records for SLA credits. LazyAdmin's outage guide says claims should cite the incident IDs (EX1550543, MO1550821, and TM1550488 if you were hit by the Teams incident on Thursday). That Teams incident was separate and earlier. It ran from 14:45 to 15:53 UTC on Thursday, affected only the Americas, and was resolved.

Exchange Online background: why one failure spreads​

PPC Land's explainer is useful for understanding why an Exchange problem shows up in Copilot. Exchange Online is Microsoft's hosted version of Exchange Server. It holds a tenant's mailboxes, calendars and contacts, and it is usually bought inside Microsoft 365 or Office 365 bundles, not on its own. PPC Land describes it as the data layer much of the suite depends on, and this incident supports that description.

PPC Land's walkthrough of the architecture, in brief:

• Inbound mail: MX records point to a Microsoft host. Messages pass through Exchange Online Protection (EOP), which checks SPF, DKIM and DMARC and filters spam and malware, before reaching the mailbox.
• Access: Outlook for Windows connects with MAPI over HTTP, phones usually use ActiveSync, and browsers use Outlook on the web. These are the same paths listed as affected in EX1550543. Third-party apps are moving from Exchange Web Services (EWS) to Microsoft Graph.
• Dependents: Copilot reads mail, calendar and contacts through Graph. If Exchange can't serve requests, those features fail too.

Exchange itself is old. PPC Land dates Exchange Server 4.0 to April 1996 and the general availability of Exchange Online to November 2008. Office 365, launched in June 2011, gave it its current scale.

Upcoming deadlines (per PPC Land; check your Message center)​

The explainer also lists several deadlines that admins should check against their own tenant's Message center posts:

The SMTP AUTH change is the most urgent for many Windows shops. Multifunction printers, scanners and older line-of-business apps that send mail with a username and password need a plan before the end of the year.

Reliability, the SLA and concentration risk​

PPC Land reports that Microsoft's Online Services SLA promises 99.9% monthly uptime for Exchange Online. That allows roughly 43 minutes of downtime in a 30-day month. Service credits are reported as 25% of the monthly fee below 99.9%, 50% below 99% and 100% below 95%. Measured against that budget, an outage that lasted overnight and into a second business day is well outside 99.9% for affected tenants. Whether a given tenant gets a credit still depends on Microsoft's per-tenant user-minute calculation, so keep records of your own impact.

Most organizations accept this trade-off. Microsoft runs the servers, applies the patches and carries out the failovers, and customers give up control. Exchange Online has also had serious security failures. PPC Land cites the Cyber Safety Review Board's finding that the 2023 Storm-0558 intrusion "was preventable and should never have occurred," and Microsoft's 2024 disclosure that Midnight Blizzard accessed its corporate email. To be clear, Microsoft has said there is no indication that this week's outage is malicious. PPC Land's point is about concentration: when email, identity-linked data and AI features all sit with one provider, a failure in one place affects many others.

Section summary: Exchange Online feeds Teams, SharePoint, Copilot and parts of Defender, so a capacity failure in Exchange's access layer spreads across the suite. Keep an outage communication plan, a backup status channel and a list of your dependencies on Exchange.

Bottom line​

EX1550543 is one of the larger Microsoft 365 outages in recent memory. It lasted a long time, and Microsoft's explanation changed several times while it was being fixed. As of Microsoft's latest updates on November 13, recovery was underway but not complete, delayed mail was being protected with a 48-hour retry window, and the root cause was waiting on the Post-Incident Report. For admins, the immediate steps are to follow EX1550543 and MO1550821, avoid troubleshooting clients for a server-side failure, and record your impact for an SLA claim. After that, check the SMTP AUTH, EWS and Admin API deadlines in your Message center.

Correction (November 13, 2026): Two times in the incident timeline were corrected against Microsoft's Service health feed: the update identifying connectivity errors on Exchange Online infrastructure was posted at 17:45 GMT, not 16:55 GMT, and the update saying the serviceability change was not taking as expected was posted at 02:54 UTC on November 13, not 03:07 UTC.