A failure in Exchange Online on November 12 spread to every Microsoft 365 feature that reads mail, calendars or labels. We map those dependencies from Microsoft's own status post, explain the retry rules that decide whether delayed mail arrives or bounces, and give the checks to run in your tenant.
This explains reporting by
Microsoft 365 Status: Users may be unable to connect to multiple Microsoft 365 services (updated November 13, 2026, 14:56 UTC). Read the original first:
https://status.cloud.microsoft/
In one minute #
- Connectivity problems began shortly before 1 p.m. ET on Thursday, November 12, and lasted more than 20 hours, per CNBC. Microsoft's status post still said 'Service degradation' at 14:56 UTC on November 13.
- Microsoft's stated cause: 'elevated load across multiple regions' after servers were 'unexpectedly unavailable; straining the remaining infrastructure.' It says it has 'no evidence of malicious activity.'
- The outage started in Exchange Online. Microsoft says features of other services 'that interact with Exchange Online and email services are impacted', which is why Copilot, Teams calendars, Purview labels and Defender pages failed too.
- Microsoft extended its mail retry window to 48 hours, per CNBC. Exchange Online's normal expiry is 1 day, and tenants can only set 12 to 24 hours.
- Mail from outside senders waits in the sender's own queue. RFC 5321 says senders should keep retrying for at least 4 to 5 days, but each sender sets its own limit.
- Check message trace for Pending and Failed mail, read the Queued messages report, and resend anything that bounced.
What Microsoft has confirmed #
CNBC reports that connectivity problems began shortly before 1 p.m. ET on Thursday, November 12, and lasted more than 20 hours. Outlook, SharePoint and Copilot were largely down through the Asian business day, the European morning and the early US hours.
Microsoft's first update blamed 'elevated load across multiple regions', with servers 'unexpectedly unavailable; straining the remaining infrastructure.' Around 9 a.m. ET on November 13 it said email queues were 'significantly reduced and approaching normal levels.'
The status post at status.cloud.microsoft, last updated 14:56 UTC on November 13, says Microsoft sees 'sustained improvements' but some users may still see intermittent connection problems or delayed email. It says Microsoft has 'no evidence of malicious activity' and will publish a Post-Incident Report with the root cause after mitigation.
That report does not exist yet. Everything below about the cause is Microsoft's short public wording, nothing more.
Why one Exchange failure reached so many products #
Exchange Online is not only email. It also stores calendars and mailbox data that other Microsoft 365 features read. Microsoft's status post says it plainly: features 'that interact with Exchange Online and email services are impacted', while parts that do not depend on Exchange keep working.
Microsoft's own list of affected services shows how far that reaches:
- Exchange Online: Outlook on the web, Outlook desktop (MAPI), ActiveSync and REST connections may fail, and delivery may be delayed.
- Copilot: Copilot Chat may not load, and Copilot may not reach mail, calendar and files.
- Teams: calls, meetings, group chats and channel messages mostly work, but anything tied to Exchange fails, such as scheduling, invites and meeting edits. Live and virtual events cannot be created.
- Purview and Defender: data loss prevention, sensitivity labels, eDiscovery search and export, and some Defender portal pages are affected.
- Also listed: the Microsoft 365 admin center, Power BI and Fabric exports with sensitivity labels, To Do, Universal Print, SharePoint external sharing, and Windows 365 Cloud PCs that use Purview Customer Key.
The last item is the one to notice. A Cloud PC that depends on a Purview key may not connect at all, so a mail outage can become a desktop outage for those users.
What happens to an email that cannot be delivered #
Email does not fail on the first try. When a server cannot deliver a message, it keeps the message in a queue and tries again later. The rules for this are in RFC 5321, the email standard.
RFC 5321 says the sender 'MUST delay retrying' after a failure, that the retry interval 'SHOULD be at least 30 minutes', and that the give-up time 'generally needs to be at least 4-5 days.' Each mail system picks its own numbers inside those rules.
Exchange Online's numbers are shorter. Microsoft's Set-TransportConfig docs say the default MessageExpiration is 1 day, and a tenant can set it from 12 hours to 24 hours. 'Queued messages typically expire after 24 hours, resulting in an NDR', a non-delivery report, or bounce.
So the 48-hour window Microsoft announced, per CNBC, is longer than any value a tenant could set for itself. Microsoft has not said which queues it applies to.
Mail sent from outside your company is a different case. While Exchange Online could not accept it, that mail waited in the sender's own queue, under the sender's own expiry. An on-premises Exchange Server, for example, defaults to 2 days (Set-TransportService docs). Some senders give up sooner, so some outside mail may have bounced back to them, and you will not see that bounce.
How to check your tenant #
Start with message trace. In Exchange Online PowerShell, list messages from the outage window that were not delivered:
Connect-ExchangeOnline
Get-MessageTraceV2 -StartDate "2026-11-12 17:00" -EndDate "2026-11-13 18:00" -Status Pending,Failed | Select-Object Received,SenderAddress,RecipientAddress,Subject,Status
Pending means delivery is deferred and still being retried. Failed means delivery was tried and failed. Times are UTC; adjust them to your own window.
Then check your expiry setting, so you know what a normal day looks like:
Get-TransportConfig | Format-List MessageExpiration
In the new Exchange admin center, the Queued messages report shows outbound mail over connectors that has waited more than an hour. Microsoft says it retries those messages for 24 hours on a normal day before it returns them as bounces.
The alert policy 'Messages have been delayed' emails TenantAdmins when more than 2,000 messages queue. During an Exchange outage, that email goes to the same mailboxes that are down.
What to tell users and clients #
Most delayed mail should still arrive, because Microsoft extended its retry window. Tell people not to resend everything right away, because resent mail will arrive twice when the queue drains.
Do resend anything that bounced. A bounce means the system gave up, so that message will not arrive on its own.
Ask important outside contacts to resend anything they sent on Thursday afternoon or Friday morning, Eastern time. If their mail bounced, the bounce went to them, not to you.
Check meetings created or changed during the outage. Teams scheduling and invites were on Microsoft's affected list, so some changes may not have saved.
Who is affected #
| Case | Status |
|---|---|
| Exchange Online mailboxes (Outlook web, desktop, mobile, REST) | Affected. Access failures and delayed delivery; recovering on November 13. |
| Microsoft 365 Copilot | Affected. Copilot Chat may not load or reach mail, calendar and files. |
| Microsoft Teams | Partly affected. Core calls, chats and meetings mostly work; scheduling, invites and meeting edits fail. |
| Purview (DLP, sensitivity labels, eDiscovery) | Affected, per Microsoft's status post. |
| Windows 365 Cloud PCs using Purview Customer Key | Some users may be unable to connect. |
| SharePoint Online file access | Working. External sharing and Exchange-dependent features may be affected. |
What to do #
- Run message trace for the outage window and resend anything with Failed status.
- Do not tell users to resend everything; deferred mail is still being retried and may arrive twice.
- Ask key outside contacts whether their mail to you bounced on November 12 or 13.
- Send Microsoft 365 service health alerts to an address outside your tenant.
- Give clients a phone or chat backup for the next mail outage, and write it down now.
- Read Microsoft's Post-Incident Report when it is published and check whether the root cause touches your setup.
What is still unknown #
- Why the servers became unavailable. Microsoft has given only a short description so far; the root cause will be in its Post-Incident Report.
- Which queues the 48-hour extension covers. CNBC reports the extension; Microsoft's status post that we read does not describe it in detail.
- Whether any mail was lost rather than delayed. Microsoft has not said.
- How many tenants were affected. Microsoft has not given a number.
- When the outage will be fully over. At 14:56 UTC on November 13 the status was still 'Service degradation'.
Sources #
AI News Report· every headline, every morning.