When Email Stops: Lessons from the November 2026 Microsoft 365 Outage

On Thursday, 12 November 2026, email stopped working for a large part of the business world. Exchange Online, the service behind Outlook for most organizations on Microsoft 365, failed in one region after another. For many users the disruption lasted most of a day, and delayed mail was still arriving on Saturday.

At PointClick we manage several thousand Microsoft 365 mailboxes as a Tier 1 Microsoft Cloud Solution Provider. We watched the incident unfold in real time with our clients. The question we heard most from leaders was a fair one: how can one of the most valuable technology companies in the world go this long without a fix?

Here is our answer, based on the public record, along with what clients are asking now: what they can do on their side, and what this says about the world's dependence on a handful of US technology providers.

What happened

Problems began on Thursday afternoon in the UTC time zone, which was late morning to early afternoon in the eastern United States and evening in Europe. Microsoft tracked the incident as EX1550543 for Exchange Online. It first said users in the Americas couldn't reach their mailboxes, then widened the warning to users "in any region." A second incident, MO1550821, covered the Microsoft 365 services that depend on Exchange Online.

The impact went well beyond the inbox:

• Email: Outlook on the web, Outlook desktop, mobile mail (Exchange ActiveSync) and REST-based connections all failed, and mail delivery was delayed.
• Teams: calendars, meeting invites and scheduling broke, although calls, meetings and chat largely kept working.
• Other services: Copilot, SharePoint and OneDrive features, Defender, Intune, Purview, Planner and parts of the admin center were all affected.

At the peak, Downdetector logged 130,000–140,000 Outlook reports from more than 70 countries. Schools, hospitals, courts, agencies and businesses lost their main communication channel for a working day.

Microsoft said several times that it saw no sign of malicious activity. Its later statement was more direct: "This was a technical issue not related to cyber or AI / agents. The incident was introduced by an issue during an earlier network capacity upgrade that surfaced following a recent network change." Microsoft has said a preliminary post-incident report will follow within two business days and a final report within five. We will update this article when Microsoft publishes its report.

Why it took so long to restore

"A network change went wrong" sounds like something you could undo in minutes. Microsoft's status updates show why it wasn't. Pending the full report, the sequence looked like this:

1. Servers began failing automated health checks. Large systems take servers that look unhealthy out of service. That protects users when a few machines are sick, but when many fail at once, the system removes a large share of its own capacity.
2. The remaining servers were overloaded. Microsoft said the load "isn't driven by an overall increase in traffic." Normal traffic was squeezed onto fewer machines, a process that sets up secure connections became overwhelmed, and those servers stopped responding too.
3. Restarts didn't hold. Servers returned to service "can become unresponsive again once they receive traffic." When hundreds of millions of devices are all trying to reconnect, a restored server can be overwhelmed the moment it comes back.
4. The cause wasn't obvious at first. Early updates said no recent change lined up with the impact. Hours later, Microsoft began reverting one that did. Some machines were "stuck in a bad state," which kept corrected settings from reaching them.
5. Recovery was deliberately slow. The turning point came overnight with a patch to an "upstream authentication/routing configuration component." Microsoft then restored service region by region, starting with Asia Pacific. In its words: "Given the scale of demand, we restored services gradually, validating stability at each stage. While this took longer, it helped ensure a stable restoration."
6. Email had to catch up. Microsoft extended its email timeout window to 48 hours so delayed messages would keep retrying instead of bouncing. Access returned before mail flow did, and some messages arrived hours late and out of order.

Microsoft said its underlying fix was in place on Friday afternoon, 13 November (UTC). It reported that consumer services had fully recovered by 16:10 UTC that day, and later confirmed that the email backlog had been processed and the issue was remediated.

The honest answer to "how could this take so long?" is that scale cuts both ways. The shared global infrastructure that makes Microsoft 365 reliable on an ordinary day makes a failure in a shared component hard to unwind, and bringing service back too fast can trigger a second collapse.

What leaders are asking us

Could we have prevented this? No. A provider-side outage can't be prevented from the customer side. You can control how much it hurts: whether people can still communicate, critical messages get through, and customers hear from you first.

Wouldn't on-premises Exchange have been safer? For most organizations, no. Well-run hyperscale clouds are still more available and better secured than most self-managed email servers; on-premises outages just don't make the news. The lesson isn't to leave the cloud. It's to stop treating any single service as if it can't fail.

Did we lose email? Probably not. Sending servers queue and retry, and Microsoft extended its timeout to 48 hours. But delays were common, so confirm anything time-critical sent on 12–13 November.

Are we owed anything? Possibly. Exchange Online has a financially backed 99.9% monthly uptime commitment. Service credits are 25% of the affected service's monthly fee below 99.9%, 50% below 99%, and 100% below 95%. Downtime is measured in affected user-minutes, credits aren't cash, and claims are due by the end of the following month. If you buy through a CSP, your provider files the claim. Credits rarely approach the business cost, which is why continuity matters more than the SLA.

Should we run a second email platform? Rarely. A continuity layer that steps in only when the primary fails usually delivers most of the benefit for a fraction of the cost.

A practical email resilience checklist

You can't control Microsoft's network. Here is what you can control.

1. Add an email continuity service. Many secure email gateways and specialist providers offer continuity: if Microsoft 365 is unavailable, they queue inbound mail and give users an emergency web inbox to keep sending and receiving. Mimecast and Proofpoint are examples. It works best when already in your mail flow, and it must be tested.
2. Understand that backup is not continuity. Third-party backup protects against deletion, ransomware and data loss. It doesn't let anyone send email during an outage. Most organizations need both.
3. Know what fallbacks will and won't do. Outlook's Cached Exchange Mode keeps recent mail and calendars readable offline. But web, desktop and mobile clients all connect to the same service, so switching apps doesn't help when the service itself is down.
4. Set up an out-of-band communications plan. Decide in advance how you'll reach staff, customers and suppliers. Teams chat mostly worked this time, but it shares identity and infrastructure with Microsoft 365. Keep a channel that doesn't (SMS or mass notification, a phone tree, a separate messaging platform) and a contact list stored outside Microsoft 365.
5. Map your email dependencies. List the processes that quietly depend on email: invoicing, password resets, ticketing, approvals, alerts. Give critical application notifications a separate sending path, such as a transactional email service.
6. Plan DNS before you need it. If your plan involves changing MX records, keep TTLs short (typically an hour or less) and pre-stage the change. Better still, choose a design that needs no DNS changes mid-incident.
7. Monitor service health properly. Configure Microsoft 365 Service Health alerts for more than one person, and follow Microsoft 365 Status on X and the public status page. Don't wait for users to tell you.
8. Write the runbook and rehearse it. Who declares an incident, who talks to customers, what holding messages say, when continuity switches on. Run a tabletop exercise at least yearly.
9. Do the post-incident cleanup. Use message trace to find pending or failed mail, recheck meeting invites, and reverse temporary workarounds.

The bigger question: dependence and sovereignty

This was a technical failure, not a geopolitical event. But it made a long-running concern concrete. Much of the world's commerce, government and communication now runs on a small number of US providers. In 2025 the UK competition regulator found that AWS and Microsoft each held 30–40% of the UK/EEA cloud infrastructure market.

Three issues come up in nearly every conversation we have now:

• Concentration. When one shared platform fails, every organization on it fails at once. In the UK, Computer Weekly found that 46 of 48 police forces route email through Microsoft 365.
• Jurisdiction. The US CLOUD Act of 2018 requires US-based providers to produce data in their possession, custody or control, even if it's stored abroad. In 2025, Microsoft France's legal director told a French Senate inquiry that he couldn't guarantee customer data would never be handed to US authorities under a valid request. Microsoft has responded with its EU Data Boundary, 2025 European digital commitments (including a European board and a legally binding Digital Resilience Commitment), sovereign cloud offerings, and partner-operated clouds such as Bleu in France and Delos in Germany.
• Priority. During this outage, Australia's Home Affairs Minister said the government had activated a resilience agreement with Microsoft "to make sure that we get appropriate prioritisation of Australian interests." That's sensible for Australia. It also raises a question for countries and organizations without that leverage: who goes first when capacity is scarce?

AI raises the stakes. Copilot went down with Exchange Online this week because it depends on the same data and services. As AI agents enter daily operations, the same few companies host the models, the GPUs and the data, so concentration risk grows with every workflow built on them.

We work with organizations in the United States, Spain and the wider EU, The Gambia and West Africa, and India. Each faces different rules and options, but a balanced approach looks similar everywhere:

• Go multi-vendor where it matters, for continuity, backup and out-of-band communications, rather than everywhere.
• Choose data residency deliberately, using in-region data storage options where regulation or risk calls for it.
• Keep an exit plan. Know how you would export your mail, files and identity data, and test it.
• Use regional and local providers where they fit, for workloads with strict sovereignty needs or local latency requirements.
• Treat AI as critical infrastructure. Ask where your AI tools run, what they depend on, and what happens if they're unavailable.

Where to start

Large cloud outages are rare, but they aren't going away. The organizations that kept working last Thursday didn't have a different email provider. They had a plan, a fallback channel, and people who knew what to do.

If you'd like an independent view of where your organization stands, PointClick offers a free email resilience review. We'll map your Microsoft 365 dependencies, identify single points of failure, and recommend proportionate continuity and communication measures, with no obligation. Contact us at support [at] pointclick [dot] net or through our contact page.

Malik Khan is Founder and CEO of PointClick Technologies, a managed IT and cloud services provider founded in 2007 with offices in Raleigh, Málaga, Banjul and India.