November 13, 2026. Microsoft opened a Microsoft 365 incident at 17:54 UTC on November 12 (12:54 p.m. Eastern), when its status account said it was investigating reports of problems accessing Exchange Online mailboxes. At its 06:17 UTC update on November 13, about 12.4 hours later, Microsoft's public status page still showed "Service degradation", said users "may be unable to connect to multiple Microsoft 365 services", and listed 19 services, including Exchange Online, Microsoft Copilot 365 and Microsoft Graph, whose features that interact with Exchange Online are impacted. For a business that runs on Microsoft 365, the line that matters is Microsoft's own: "email delivery may be delayed." Under the SMTP standard, mail that cannot be delivered is queued and retried by the sending server, so a delay is not the same as a lost message while the sender keeps retrying.

Key numbers
| Item | Number |
|---|---|
| First Exchange Online status post (incident EX1550543) | 17:54 UTC, Nov 12 |
| Second incident ID (posted 18:35 UTC) | MO1550821 |
| Hours from first post to the 06:17 UTC update (still degraded) | about 12.4 |
| Microsoft 365 services listed as affected (those that interact with Exchange Online) | 19 |
| Outlook reports on Downdetector, per CNBC ("at the time" the outage began) | about 130,000 |
| Latest status page update read for this article (still Service degradation) | 06:17 UTC, Nov 13 |
| SMTP retry interval in RFC 5321 ("in general", a SHOULD) | at least 30 minutes |
| SMTP give-up time in RFC 5321 (each sender sets its own) | at least 4-5 days |
Microsoft's status page (06:17 UTC update) and Microsoft 365 Status posts read on 13 November 2026 at about 06:35 UTC, plus RFC 5321 and CNBC.
What Microsoft says is affected
Microsoft posts the incident on status.cloud.microsoft "because Microsoft 365 administrators may be unable to access the admin center to get Service health information." It ties the impact to one dependency: "Features of the Microsoft 365 services below that interact with Exchange Online and email services are impacted." In our view, these are the items that matter most for a small team, as listed in the 06:17 UTC update:
- Outlook and Exchange Online. Users "may be unable to access their mailbox using Outlook on the web, Outlook desktop (MAPI), Exchange ActiveSync (EAS), or REST-based connections, and email delivery may be delayed."
- Microsoft Copilot 365. Users "may be unable to load Copilot Chat or receive responses", and Copilot "may be unable to access work data such as email, calendar, and files."
- Microsoft Graph. "API requests that access Exchange Online data, such as mail, calendar, and contacts, may time out" and can block some Teams management through Graph. Automations, CRM syncs and sending tools that read or send mail through Graph sit on this path.
- Defender for Office 365. "Users clicking on wrapped/rewritten URLs typically processed by Safe Links will result in a failure to navigate." Releasing mail from quarantine can fail, and message traces may be delayed.
- Teams. "Most of the core functionality including joining calls, meetings, group chats, and channel messages are not impacted", but Microsoft lists calendar failures with scheduling, invites, viewing and meeting edits, which depend on Exchange Online.
- SharePoint and the admin center. "Accessing files stored directly in SharePoint Online remains functional." Some admin center pages may not load.
On the consumer side, Microsoft's page showed "Microsoft 365 (Consumer)" as degraded at its 04:24 UTC update, while the separate Outlook.com and Microsoft Copilot entries read "Operational" when we checked at about 06:10 UTC. Azure showed "No Azure issues detected at this time."
The timeline from Microsoft's own posts
Times are UTC, quoted or summarized from the Microsoft 365 Status thread and the status page.
| Time (UTC) | What Microsoft said |
|---|---|
| Nov 12, 17:54 | Investigating reports of issues accessing Exchange Online mailboxes "in the Americas" (EX1550543) |
| Nov 12, 18:07 | The issue "may affect Microsoft 365 service connectivity for users in any region" |
| Nov 12, 18:35 | "Elevated load across multiple regions"; second incident ID MO1550821 |
| Nov 12, 19:12 | "We've paused all deployments", moving traffic and restarting servers |
| Nov 12, 19:31 | The load "isn't driven by an increase in traffic, but by a number of servers being unexpectedly unavailable" |
| Nov 12, 20:19 | "We've not identified any recent change correlated with the start of impact"; a component that processes server health suspected |
| Nov 12, 21:00 | An alternative health check method returned "a subset of affected servers" to service |
| Nov 12, 21:40 | Assessing whether reverting "a small number of recent configuration updates" could help |
| Nov 12, 22:09 | "Our actions taken thus far have not provided the anticipated relief"; "a core process on affected servers is becoming overwhelmed" |
| Nov 13, 00:06 | Returned servers "can become unresponsive again once they receive traffic" |
| Nov 13, 04:36 | "Partial recovery across regions" where traffic measures were applied |
| Nov 13, 05:46 | Working to "pinpoint the underlying cause of the traffic influx"; "not aware of any malicious activity" |
| Nov 13, 06:12 | "Continuing to work on recovering our frontend servers" |
| Nov 13, 06:17 | Evaluating "traffic throttling, protocol adjustments, and failover routing"; next update promised by 07:00 UTC |
CNBC, in a story first published at 20:54 UTC on November 12, said the outage "began shortly before 1 p.m." and that "At the time, about 130,000 users reported issues with Outlook" on Downdetector. Amazon told users that an "unrelated disruption elsewhere on the internet" was prompting inaccurate reports about AWS. Separately, Microsoft opened a Teams incident in North America (TM1550488) at 15:40 UTC, about two hours before the Exchange posts, and said at 16:13 UTC that automated recovery was reducing its impact. Microsoft has not said the two incidents are connected.
What it means for email you send and receive
Start with inbound mail. The SMTP standard, RFC 5321, says "mail that cannot be transmitted immediately MUST be queued and periodically retried by the sender", 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 sending provider sets its own schedule, so the exact window varies, and a sender can give up. We suggest checking for a bounce message before asking a customer to resend, because a resend on top of a queued original can arrive twice once service returns.
Then outbound links. If your recipients' organizations use Defender for Office 365 Safe Links, Microsoft's 06:17 UTC update said clicks on rewritten links fail to navigate. Click and reply numbers from Microsoft 365 recipients for November 12 and 13 may understate real interest, so we would not judge a campaign, a subject line or a landing page on those two days.
If you send cold email or sales sequences
Sending tools that connect to Microsoft 365 inboxes through Outlook connections or the Graph API depend on the parts Microsoft lists as affected. We suggest pausing sequences that send from Microsoft 365 inboxes until Microsoft marks the incident resolved, then resuming at your normal daily volume rather than catching up in one burst. Volume rules still apply after an outage; our guide to Microsoft 365 sending limits covers the caps a tenant works under, and the SMTP AUTH deprecation piece covers another Microsoft change on outbound tools' calendar.
In our view, the wider lesson is that one mailbox provider is one point of failure. Inboxes on a second provider would not have depended on Exchange Online to send, though delivery to Microsoft 365 recipients could still be delayed. Our email infrastructure page covers domains, inboxes and SPF, DKIM and DMARC for outbound, and the email hosting cost guide compares what a business mailbox costs per user.
What admins and agencies can do now
- Use the public status page. status.cloud.microsoft carries the incident when the admin center will not load. The IDs to quote in tickets are EX1550543 and MO1550821.
- Move urgent work to what Microsoft lists as working. Microsoft's 06:17 UTC update said most core Teams functionality, including joining calls and meetings and chats, was not impacted, and that files stored directly in SharePoint Online remained reachable.
- Pause automations that write mail or calendar events through Graph. We suggest re-running them after recovery and checking for duplicates, since a timeout can leave a run half done.
- Give clients times, not guesses. Quote Microsoft's latest update and its promised next update rather than a fix time Microsoft has not given.
- Read the Post-Incident Report. Microsoft says that once the issue is mitigated it will provide "full details of the root cause, defense-in-depth repair items, and more within a Post-Incident Report."
What we do not know yet
As of Microsoft's 06:17 UTC update on November 13, there was no published root cause, no restoration time and no count of affected tenants. At 05:46 UTC Microsoft said it was still working to "pinpoint the underlying cause of the traffic influx", and at 06:17 UTC it was "evaluating traffic controls that can be applied to increase capacity and stability." It said: "As of now, we are not aware of any malicious activity that is causing this incident." This page reflects Microsoft's posts up to that 06:17 UTC update. If the outage exposed gaps in how your outbound is set up, read what an email deliverability consultant costs before you hire one, and see the EWS deprecation timeline if your tools still connect to Exchange Online the old way.
Frequently Asked Questions
At its 06:17 UTC update on November 13, 2026, Microsoft's status page listed Microsoft 365 (Business or Enterprise) as "Service degradation" and said users "may be unable to access their mailbox using Outlook on the web, Outlook desktop (MAPI), Exchange ActiveSync (EAS), or REST-based connections." The consumer Outlook.com entry read "Operational" when we checked at about 06:10 UTC. Check status.cloud.microsoft for the latest.
Microsoft has not published a root cause. Its posts say the elevated load came from "a number of servers being unexpectedly unavailable", that servers were failing automated health checks, and that "a core process on affected servers is becoming overwhelmed." At 05:46 UTC on November 13 it was still working to "pinpoint the underlying cause of the traffic influx" and said it was "not aware of any malicious activity." A Post-Incident Report is promised once the issue is mitigated.
Microsoft says "email delivery may be delayed." Under RFC 5321, mail that cannot be delivered must be queued and retried by the sending server, with a give-up time that "generally needs to be at least 4-5 days", although each provider sets its own schedule. Check for a bounce message before resending.
Microsoft's 06:17 UTC update said most core Teams functionality, including joining calls and meetings, group chats and channel messages, was not impacted, while calendar scheduling, invites and meeting edits that depend on Exchange Online failed. Microsoft also opened a separate North America Teams incident, TM1550488, at 15:40 UTC on November 12 and has not said the two are connected.
Microsoft's 06:17 UTC update listed Microsoft Copilot 365, the work version, as affected: users "may be unable to load Copilot Chat or receive responses", and Copilot may be unable to reach email, calendar and files. The consumer Microsoft Copilot entry read "Operational" when we checked at about 06:10 UTC.
Use status.cloud.microsoft and the Microsoft 365 Status account on X. The incident IDs are EX1550543 and MO1550821.