Microsoft 365 Outage, 12 November 2026: What Happened and What to Check Next

What happened

Microsoft is tracking the outage as two incidents in the Microsoft 365 admin center [4]:

The first reports came from the Americas. Shortly after 1 p.m. ET, Microsoft said the problem could affect Microsoft 365 connectivity for users in any region [6]. The Exchange incident covers every common way of reaching a mailbox: Outlook on the web, the Outlook desktop client (MAPI), mobile clients (Exchange ActiveSync) and the REST API [6].

Downdetector reports climbed quickly. Press coverage put user reports for Outlook above 129,000 by early afternoon ET [6]. Those are reports submitted by users, not a count of affected accounts.

A separate Microsoft Teams incident, TM1550488, ran from 9:45 to 10:53 a.m. ET the same morning and was resolved. Microsoft has not said the two are connected [6].

Which services were affected

By 5:03 p.m. ET, incident MO1550821 listed these services as potentially affected [4]:

• Exchange Online
• Microsoft Teams
• SharePoint Online
• Microsoft Copilot 365
• Microsoft Defender XDR
• Microsoft Defender for Office 365
• Microsoft Intune
• Microsoft Purview, including Data Loss Prevention, Auto Labelling and Communication Compliance
• Microsoft Planner and Microsoft To Do
• Power BI (exporting reports with sensitivity labels to PDF)
• Microsoft 365 Apps admin center (Cloud Update, Cloud Policy, Inventory)

The list grew through the afternoon, so check the incident in your own admin center for the current scope.

What Microsoft says caused it

Microsoft's first working theory was elevated load on part of its infrastructure. It then corrected that: "We determined the elevated load isn't driven by an increase in traffic, but by a number of servers being unexpectedly unavailable; straining the remaining infrastructure." [1]

The servers were dropping out because they were failing automated health checks [3]. Microsoft said it found no recent change that lined up with the start of the incident, and pointed to a component on the servers that processes those health checks [6]. By late afternoon it was also investigating a small number of configuration updates as potential contributors [4].

Its response so far, in its own words: "We've paused all deployments, we're moving additional traffic off the affected infrastructure, and we're restarting affected servers to return them to service." [2] Later in the afternoon Microsoft validated an alternative health check method that returned a subset of servers to service and began rolling it out more widely [4].

Microsoft has not said why the health checks began failing. The incident records show "Root Cause: N/A" [4]. Treat any explanation that goes further than that as speculation until Microsoft publishes its post-incident report.

Was it a cyberattack?

Nothing Microsoft has published says so. Its service advisories do not report malicious activity, and it has disclosed no evidence of an attack [5]. Its own description is an availability failure: servers going offline and the remainder overloaded.

An outage on its own is not a sign that your tenant was compromised. It does create conditions attackers use, which is the part worth acting on.

Why an outage is still a security event

Phishing follows the news. Expect messages that say "your mailbox has been restored, sign in to re-activate" or "IT needs you to re-verify your account". Users who spent the afternoon locked out are primed to click. Tell them now that no action is needed on their side.

Security tooling was on the affected list. Defender XDR, Defender for Office 365, Purview Data Loss Prevention and Intune all appear in MO1550821 [4]. If your detection and policy enforcement live entirely inside Microsoft 365, assume there may be gaps or delays in alerts and controls during the incident window and review that window once service is back.

Workarounds leave holes. Under pressure, people forward work mail to personal accounts, share files through consumer apps, and ask for MFA or Conditional Access to be switched off "until it works". None of those fix a server-side outage, and each one outlives it.

The help desk is a target. A flood of "I can't log in" tickets is cover for someone impersonating a user to get a password or MFA reset. Keep identity verification steps in place even when the queue is long.

What to do now

While the outage is open

1. Follow EX1550543 and MO1550821 under Health > Service health in the Microsoft 365 admin center. If the admin center will not load, use status.cloud.microsoft.
2. Tell users it is a Microsoft-side outage and that they should not reset passwords, remove and re-add accounts, or reinstall Outlook.
3. Do not relax MFA, Conditional Access or mail-flow rules to work around it.
4. Use a channel outside Microsoft 365 for urgent communication, and say which one.

Once service is restored

1. Confirm mail flow has caught up, including queued inbound and outbound messages.
2. Review sign-in logs for the incident window: unfamiliar locations, repeated failures followed by a success, and new device registrations.
3. Check for new inbox rules, forwarding addresses and app consents created during or just after the outage.
4. Confirm Defender, Purview and Intune policies are enforcing again, and look for alerts that arrived late.
5. Record when your users were affected. If you plan to claim a service credit, your Microsoft agreement's service level terms set the requirements and the deadline.

What this means for MSPs and security teams

Three things are worth changing before the next one.

Keep an eye on Microsoft 365 from outside Microsoft 365. When Defender XDR is on the same incident as the mailboxes it protects, a second, independent view of identity and email telemetry is what tells you whether the quiet is real.

Plan the out-of-band path in advance. A status page, a phone tree or a messaging channel that does not depend on the affected tenant, plus break-glass admin accounts you have tested.

Write the client message once. An MSP with a short, plain note ready ("Microsoft outage, nothing to do on your side, do not reset anything, here is where we will post updates") spends an outage managing the incident instead of answering the same call.

Vijilan's SOC monitors endpoint, identity, network and cloud activity around the clock for partners and for organizations that work with us directly. With ThreatRespond™, that monitoring wraps the tools you already run, so watching your environment does not depend on one vendor's console being reachable. If you want to talk through what to review from today's incident window, talk to our team.

Frequently asked questions

Is Microsoft 365 still down?

As of 5:03 p.m. ET (22:03 UTC) on 12 November 2026, Microsoft listed both incidents, EX1550543 and MO1550821, as service degradations that had not ended. Some servers had been returned to service. Check Service health in the Microsoft 365 admin center or status.cloud.microsoft for the current state.

What caused the Microsoft 365 outage on 12 November 2026?

Microsoft says a number of servers became unexpectedly unavailable after failing automated health checks, which overloaded the remaining infrastructure. It has ruled out a surge in traffic as the driver. It has not published a root cause for why the health checks failed.

Was the Microsoft 365 outage a cyberattack?

Microsoft has reported no evidence of a cyberattack, and its service advisories do not mention malicious activity. It describes an availability failure in its own infrastructure. An outage alone is not evidence that a tenant was compromised.

Which Microsoft services were affected?

Exchange Online and Outlook were hit first. Microsoft's suite-wide incident also lists Teams, SharePoint Online, Copilot, Defender XDR, Defender for Office 365, Intune, Purview, Planner, To Do, a Power BI export feature and the Microsoft 365 Apps admin center as potentially affected.

What are EX1550543 and MO1550821?

They are Microsoft's incident IDs. EX1550543 is the Exchange Online incident covering mailbox access. MO1550821 is the wider Microsoft 365 incident covering multiple services. Administrators can find both under Health > Service health in the Microsoft 365 admin center.

Should I reset my password or reinstall Outlook?

No. The fault is on Microsoft's servers, so resetting passwords, removing and re-adding accounts or reinstalling apps will not help and can create new problems once service returns. Wait for recovery and be suspicious of any message asking you to sign in to "restore" your mailbox.

Did the outage affect security monitoring?

Microsoft listed Defender XDR, Defender for Office 365, Purview Data Loss Prevention and Intune as potentially affected. Organizations that rely only on those tools should review the incident window for delayed alerts and gaps in policy enforcement after service is restored.

What should an MSP check after Microsoft 365 is restored?

Confirm mail flow has caught up, then review sign-in logs, new inbox and forwarding rules, new app consents and device registrations from the incident window. Confirm security and compliance policies are enforcing again, and document the impact for each client.