Microsoft 365 suffered a widespread outage beginning Thursday, November 12, 2026, which extended into Friday and disrupted access to business email and other cloud services across multiple regions. Microsoft first reported that users in the Americas could not connect to Exchange Online mailboxes. It later identified potential disruption to Teams, SharePoint Online, Microsoft 365 Copilot, Defender XDR and many other services. The activity described here was documented by SecurityWeek.

Microsoft is tracking the email disruption as EX1550543 and the broader incident as MO1550821 in the Microsoft 365 admin center, where both were listed as service degradations. Features in any Microsoft 365 service that interact with Exchange Online were affected, while parts of those services that do not depend on it kept working. Some Google Workspace users also reported trouble reaching their Google-hosted mail through Outlook desktop and mobile clients, so the impact extended to people who use Outlook only as a client.

Microsoft traced the strain to a large number of servers becoming unavailable, which left the remaining systems to carry the load. The company said overall traffic had not increased. Affected servers were failing automated health checks and showed elevated processor usage, and a process that establishes secure connections became overwhelmed until those servers stopped handling requests. Microsoft tested a workaround that bypasses the health-check component and began rolling back a recent network configuration change that coincided with the start of the disruption. By 9 p.m. ET Thursday, restarting affected servers was showing signs of improvement, though Microsoft had not confirmed full recovery or a root cause.

"At this time, we have no evidence of malicious activity associated with this incident." (Microsoft 365 status page)

Microsoft has promised a Post-Incident Report with root cause details after mitigation. The outage came two days after November Patch Tuesday, which addressed 1,094 vulnerabilities, including CVE-2026-124194, an exploited Outlook spoofing flaw that can expose a user's authentication material when a crafted file is opened. Microsoft has not linked that CVE to the outage, and no connection has been confirmed.

For your organization, the practical lesson is how far one Exchange Online fault reached. A single provider-side failure affected email, Teams, SharePoint and Copilot features at the same time, and your recovery timing depended entirely on Microsoft's fix.

Operational and Business Consequences of Losing Email and Teams Access

The disruption ran from Thursday into Friday, so it spanned parts of two business days. As of Microsoft's Thursday evening update, restarting affected servers was only "showing signs of improvement," and the company had not confirmed full recovery. For your organization, the useful question is how much of your daily work depends on email and Teams messages reaching people on time.

The first cost is missed customer communication. Customer inquiries, quote requests, support tickets and order confirmations that travel by email either stall or arrive late. If your customers hear nothing back, they may assume they were ignored, call your front desk instead, or take the request to a competitor.

Delivery itself becomes unpredictable. When a receiving mail server cannot accept messages, the sending server typically queues the message and retries for a period. If those retries run out, the sender receives a non-delivery report (a bounce). Partners who see a bounce from your domain may conclude your address is invalid or resend the same message several times. Mail that does get through often arrives in a backlog once service returns, which buries time-sensitive items under hours of delayed traffic.

Internal workflows stop moving too. Purchase order approvals, payment authorizations, contract sign-offs and HR requests that route notifications through Outlook or Teams sit unanswered because approvers never see them. Scheduled Teams meetings with clients, vendors or job candidates fail or move to ad hoc phone calls, and decisions get delayed or go undocumented.

The impact also reached beyond Microsoft tenants. Some Google Workspace users reported trouble reaching their Google-hosted email through Outlook desktop and mobile clients. If your staff use Outlook as their mail app for a non-Microsoft service, they may have been affected even though your mailboxes are not hosted on Exchange Online.

Help desk load rises quickly in an event like this. Users cannot tell whether the problem is their laptop, their password or the provider, so they open tickets, reboot devices and reset credentials. Your IT staff spend the day triaging a cloud problem they cannot fix, and the channels they would normally use to post status updates may be the same ones that are down.

Contractual exposure follows from all of this. If your customer-facing processes rely on Exchange Online, such as support response times, delivery notices or formal notifications required by contract, you may miss commitments you owe your own clients. Any service credit you receive from a cloud provider is a separate matter from the obligations in your customer agreements, and those agreements may not treat a provider outage as an excused delay.

The compliance side deserves attention in regulated sectors. Messages that bounced or sat on a sender's server never entered your tenant, so your retention policies, journaling and eDiscovery did not capture them during that window. When employees switch to personal email, text messages or consumer chat apps to keep work moving, those conversations land outside your archive and outside your legal hold scope.

There is a security side effect as well. Users cut off from normal channels are more likely to trust outage-themed messages, such as fake "Microsoft support" emails, prompts to re-verify a mailbox, or phone calls offering help with restoring access. Microsoft stated it had no evidence of malicious activity tied to the incident. The timing still matters, because the outage came two days after November Patch Tuesday fixed 1,094 vulnerabilities, including CVE-2026-124194.

Microsoft has not linked that vulnerability to the outage. However, a burst of delayed mail arriving at once, combined with users eager to catch up, gives a malicious attachment more chances to be opened without scrutiny.

Root Cause Details and the Status of CVE-2026-124194

Microsoft has not confirmed a root cause, and no Post-Incident Report has been published yet. Its status updates describe a capacity failure inside its own server fleet. A large number of servers became unavailable, and the remaining systems had to absorb their traffic. Microsoft said overall traffic had not increased, so the added load came from lost capacity and not from a surge in demand.

The technical details Microsoft has shared so far fall into four observations:

• A process that establishes secure connections was becoming overwhelmed, and affected servers stopped handling requests once it did.
• Affected servers were failing automated health checks, which would explain why they dropped out of service.
• Microsoft was testing a workaround that bypasses the component responsible for processing those health checks.
• Engineers were also investigating elevated processor usage on the affected servers.

Microsoft also began rolling back a recent network configuration change that coincided with the start of the disruption. The company has only described this change as coinciding with the outage. It has not said the change caused it, and it was still monitoring whether the rollback helped. For IT teams, this means the cause remains an open question until Microsoft publishes its review. Microsoft has committed to a full Post-Incident Report covering root cause and "defense-in-depth actions" after mitigation is complete.

On the security question, Microsoft's Friday status update stated: "At this time, we have no evidence of malicious activity associated with this incident." That is the confirmed position. Any claim that the outage was an attack is unverified and contradicts Microsoft's own statement.

CVE-2026-124194 is a separate matter. Microsoft fixed it in its November Patch Tuesday release, which came two days before the disruption and addressed 1,094 vulnerabilities across its products. The confirmed facts from the source are limited. It is an Outlook spoofing flaw, Microsoft says attackers have exploited it, and it can expose a user's authentication material if that user opens a specially crafted file in an affected Outlook client. The opening of a file by the user lines up with MITRE ATT&CK technique User Execution: Malicious File (T1204.002). Exposed authentication material lets an attacker attempt to act as that user, which puts mailbox contents and connected services at risk.

The source does not report a CVSS score, a list of affected Outlook versions, or whether any component of Exchange Online receives a service-side fix. This analysis could not independently verify those details in the Microsoft Security Update Guide or NVD, so they are omitted. The source places the flaw in the Outlook client, which suggests endpoint patching is relevant, but that should be confirmed against Microsoft's advisory. Microsoft's service advisories have not linked CVE-2026-124194 to the outage, and the timing alone is not evidence of a connection.

Several characteristics of this event mark it as an availability incident on Microsoft's side. The failures hit many tenants across multiple regions at once. Symptoms centered on connection failures tied to secure connection setup and failed health checks. Service elements that do not depend on Exchange Online kept working. Some Google Workspace users also reported trouble reaching their Google-hosted mail through Outlook desktop and mobile clients, which points to the client and connection path rather than any single tenant. Activity in your own tenant that these symptoms do not explain, such as unfamiliar sign-ins or unexpected mailbox changes, would fall outside the scope of this outage and point toward a separate security issue.

Steps for Microsoft 365 Administrators During and After the Disruption

The first action for you as an administrator is to open Service Health in the Microsoft 365 admin center and compare your users' symptoms against the open Exchange Online and Microsoft 365 incidents before you change anything in your tenant. The steps below are organized by the NIST Cybersecurity Framework: they start with confirming scope, move through protecting users and checking logs, and end with preparing for the next disruption.

Identify

Turn on Service Health notifications and route them to an address hosted outside Microsoft 365. Mailbox-based alerts may never arrive while Exchange Online is degraded, so a personal or secondary-provider address keeps your admins informed. While you wait, record which Outlook client versions and any on-premises or hybrid Exchange servers you run. You will need that inventory to judge your exposure to CVE-2026-124194.

Protect

• Tell staff through a non-Microsoft channel. Use SMS, a phone tree, or a status page hosted elsewhere to explain what is affected and when the next update will come. This cuts duplicate helpdesk tickets.
• Warn users about outage-themed phishing. Tell them to ignore messages that claim to be from Microsoft or IT and ask them to re-verify accounts or open attachments to "restore" mail. CVE-2026-124194 is an exploited Outlook flaw that exposes authentication material when a user opens a specially crafted file, so a fake "fix your mailbox" attachment is a realistic lure.
• Hold off on mass password resets and tenant changes. Microsoft has described a server-side failure. Bulk resets, MFA re-registration, or conditional access edits made in response to service symptoms create lockouts once service returns and add noise to your audit trail.
• Apply the November Patch Tuesday updates to Outlook clients. If Microsoft confirms a customer-side fix tied to CVE-2026-124194, such as an update for hybrid Exchange servers, apply it as described in Microsoft's advisory.

Detect

Once mail flows again, run message trace in the Exchange admin center across the outage window. Look for messages marked as failed or pending, and confirm that queued mail was delivered. Contact senders or recipients directly for anything that failed, since missed invoices or contract replies affect revenue.

Next, review your sign-in logs and the unified audit log for the same period. Focus on sign-ins from unfamiliar locations, new inbox forwarding or deletion rules, changes to MFA methods, and new application consent grants. Attackers who capture credentials during a confusing outage can use them later with legitimate permissions, which makes early review worth the effort.

Respond

Microsoft has stated it has no evidence of malicious activity associated with this incident. If you find suspicious sign-ins or mailbox rules, handle them as a separate security incident: revoke sessions, reset only the affected accounts, and remove unauthorized rules. Keep timestamped notes of helpdesk tickets and user reports so you can compare them with Microsoft's own timeline.

Recover

Read the Post-Incident Report when Microsoft publishes it. The company has said it will include the root cause and defense-in-depth actions, which will help you decide whether any tenant-side changes are warranted.

• Document a communications fallback plan that works without Microsoft 365. It should name the alternate channel, who activates it, and how customers are notified.
• Assess third-party email continuity or archiving services that let users read and send mail when Exchange Online is unavailable, and test failover before you need it.
• Review SLA credit eligibility under your Microsoft agreement. Gather the incident records, affected user counts, and duration evidence from your logs, then submit a claim through the admin center within the window your agreement specifies.

Assign an owner and a review date to each of these three items so the plan is tested before the next service disruption.

Key Takeaway for Organizations Relying on Microsoft 365

Microsoft's status page states that it has "no evidence of malicious activity associated with this incident," and the company has said it will treat the disruption with urgency until full mitigation. What you can treat as confirmed is a service failure inside Microsoft's infrastructure whose effects reached past Microsoft-hosted mailboxes, since some Google Workspace users also reported trouble reaching their email through Outlook desktop and mobile clients. The promised Post-Incident Report, with root cause and defense-in-depth actions, is the document your team should rely on before drawing firm conclusions about what failed.

CVE-2026-124194 belongs in a separate category. It is an Outlook spoofing flaw that Microsoft says attackers have exploited, and it can expose a user's authentication material when that user opens a specially crafted file in an affected Outlook client. Its patch shipped two days before the outage began, but no Microsoft service advisory connects the vulnerability to the Exchange Online disruption. Keep it on your patching list for Outlook clients and out of your explanation of why email stopped working.

The single most important action is to check Microsoft's official Service Health entries and advisories for your own tenant before you change settings or send guidance to staff. Alongside that, make sure your organization has a fallback communication channel hosted outside Microsoft 365, so your people can still reach each other and your customers when the next disruption occurs.

Whoever administers your Microsoft 365 tenant, whether an internal IT lead or an outside provider, can confirm which advisories apply to you and whether your Outlook clients carry the November updates. If you want an outside view as well, a security assessment begins with a 15-minute call and ends with written findings on five areas, including phishing risk and employee training readiness, which relate to how your staff handle crafted files like the one this Outlook flaw depends on.