What Caused the Microsoft Exchange/Outlook Outage?

Enterprises and individuals were unable to view their emails or Teams messages on Thursday, November 12. This was because Microsoft Exchange servers were taken off the grid due to excessive user/client requests.

As of going to press, Exchange servers are still down, and users cannot see or download their latest emails. Evidently, Microsoft is struggling to restore access to Outlook, Teams and Copilot half a day after the outage began.

This is not the first time an MS Exchange server global outage occurred.

Users might remember the November 2025 outage that was caused by “a change that caused an influx of retry requests routed through servers, impacting service availability.”

A DDoS attack is ruled out. Microsoft said it is “not aware of any malicious activity that is causing this incident”. This seems to be a case of server overload, which could have been prevented with early detection and proactive load balancing measures.

The Updates

However, the U.S. Cybersecurity and Infrastructure Security Agency (CISA) just confirmed active exploitation of a Microsoft Outlook zero-day vulnerability, CVE-2026-124194, that can expose user authentication data.

According to Microsoft’s security advisory, with this exploit an attacker can send a specially crafted message file and persuade a victim to open it in Outlook. The application may then connect to an attacker-controlled network location without showing its usual warning about external content.

Microsoft released security updates for an actively expoited Outlook network-spoofing flaw (CVSS 6.5), that allows unauthenticated attackers to spoof networks.

Network spoofing is a cyberattack where a fraudster disguises themselves as a trusted source, device, or network to deceive people, bypass security controls, or steal sensitive data.

16:36 UTC +5.5 (India) – We just looked around for updates and found these messages:

@MSFT365Status posted on X/Twitter: We’re investigating reports of users experiencing issues accessing Exchange Online mailboxes through multiple connection methods in the Americas.

More details can be found in the Microsoft 365 admin center under EX1550543.

@MSFT365Status We’ve determined a portion of infrastructure is experiencing elevated load across multiple regions, which is likely contributing to the connectivity errors. We’re providing more information under EX1550543 and MO1550821 in the Microsoft 365 admin center, as well as https://status.cloud.microsoft

@MSFT365Status We’ve begun redistributing connection traffic across our broader worldwide infrastructure to help balance the load. More info under EX1550543 and MO1550821 in the Microsoft 365 admin center, as well as https://status.cloud.microsoft if the admin center is not available to you.

Early Friday, Microsoft said it was “seeing positive results for server stability” after applying a software patch, and was “working to expand it to servers supporting active regions coming online.” It has promised to share a full Post-Incident Report with root cause and defense-in-depth actions after recovery is complete. That report is where you’d find out what triggered the overload in the first place. Sources: yahoo, tomsguide

What Caused The Outage?

The outage could be caused due to one or more of the following:

• Overloaded servers. Microsoft blames an “elevated load,” or servers becoming overstretched. It said “a portion of infrastructure is experiencing elevated load across multiple regions, which is likely contributing to the connectivity errors.” Source: NPRtomsguide
• Secure-connection process failing. On Thursday night Microsoft said “a process on the affected servers responsible for establishing secure connections becomes overwhelmed, causing the servers to stop processing requests.” Source: abc7news
• A cascade effect. Engineers were also working to address a problem that was causing servers to become unavailable after failing automated health checks. That would explain why the load kept piling onto fewer servers. Source: nbcchicago

Bleeping Computer reports:

“Servers became overloaded and then failed health checks. Each failed server was pulled from service, which pushed its traffic onto the remaining servers until they failed too. When users all reconnect at once, the reconnection surge keeps the remaining servers overloaded. Microsoft has been here before. Its November 2025 outage was caused by “a change that caused an influx of retry requests routed through servers, impacting service availability.”

What Microsoft Could Have Done

1. Shed load early instead of failing completely. Servers should reject excess requests in a controlled way before they tip over. Microsoft did this only reactively, “limiting which types of traffic can reach affected infrastructure in some locations” after servers “can become unresponsive again once they receive traffic.”
2. Limit how many servers health checks can remove. Cap the share of the fleet that automated checks can pull out at once. Past that cap, the system should keep sending traffic to all servers rather than piling it onto a shrinking pool.
3. Keep spare capacity for secure-connection setup. This is the process that was overwhelmed. Spare capacity, letting returning clients resume earlier secure sessions, and dedicated hardware for this work reduce the risk.
4. Retry budgets and staggered reconnects. Clients should wait longer between each retry and add random delay, so they don’t all reconnect at the same moment. Each client should also have a limit on how many retries it sends.
5. Contain failures by region. This outage was not contained. It hit “Microsoft 365 service connectivity for users in any region.” Splitting the service into independent cells stops one region’s failure from spreading to the others.
6. Staged rollouts with automatic rollback. It isn’t confirmed that a change triggered this outage (as was the case in the 2025 outage). But change-driven incidents keep recurring, as in the outage Microsoft blamed on a “problematic code change”. Rolling changes out to a small slice first and reversing them automatically when errors rise catches these early.
7. Overload testing (stress testing). Deliberately pushing servers past their limits in testing shows how they fail before it happens in production.

What IT Departments Can Do

• Plan for concentration risk. The outage showed how worryingly dependent many vital public services are on Microsoft. A single-provider dependency like this belongs in business continuity plans.
• Set up a separate fallback for communication. Keep a channel that doesn’t run on the same provider, and a documented plan for incident communication. Teams went down along with Outlook.
• Use offline access. Cached-mode mail and local copies of critical documents keep people working during an outage.
• Ask for incident reports in contracts. Write into contracts the right to receive post-incident reports and to see the provider’s resilience measures. Microsoft has promised a full Post-Incident Report with root cause and defense-in-depth actions. That report will show which of these measures were missing.