Skip to Content

Microsoft outage: the internet's email held up, Microsoft's did not

A configuration change at a single provider cut organizations in 74 countries off from their inbox. This is not a mishap: it is what centralization produces.

In short: on 12 November 2026 at 11:17 a.m. Montreal time, a network configuration change at Microsoft made Exchange, Teams, SharePoint, Copilot and about fifteen other services unreachable. By that evening, 140,000 people in 74 countries were reporting the problem. No cyberattack, no sanctions, no unpaid invoice: one change, at one provider. Meanwhile the internet's email system kept working, because it rests on an architecture Microsoft does not operate. That difference in architecture is what deserves an hour of your attention, not the outage itself.


In this article

Yesterday at 11:17 a.m. Montreal time, inboxes stopped answering across much of the world. Not yours, if you are not with Microsoft. Everyone else's.

As this is written, on the morning of 13 November, Microsoft still has not declared the incident resolved. British hospitals cancelled procedures, government services were disrupted in Australia, Japan and the Philippines, and in the United States police forces struggled to process bail payments. This is not a mail outage. It is an organizational outage, across several countries at once.

The interesting part is not that Microsoft went down. Everyone goes down. The interesting part is what did not go down, and why.


What actually happened

The incident carries two numbers in Microsoft's register: EX1550543 for Exchange Online and MO1550821 for Microsoft 365 as a whole. If your IT people are looking for them, that is where they are.

The list of affected services grew all night: Exchange Online first, so Outlook on the web, on the desktop and on phones, then Teams for scheduling and events, SharePoint for external sharing, OneDrive, Copilot, Defender, Purview, Power BI, Power Apps, Planner, To Do, Intune, Universal Print and part of the admin centre. Microsoft Graph too, which means third-party software wired into your mail and calendars stopped answering at the same moment.

On the cause, Microsoft is being careful, and so should you be. The company has ruled out a cyberattack and attributes the outage to settings applied to servers after an update: a process responsible for establishing secure connections became overwhelmed, servers stopped responding, and the load shifted onto the ones still standing. A recent network configuration change was rolled back because it coincides with the start of the incident. Coinciding is not causing, and no root cause has been confirmed to date.

One detail says a great deal: Microsoft extended to 48 hours the window before queued email expires. Hold on to that, we come back to it.


Who this article is for, and who it is not for

Before going further, three closed questions. They decide whether the rest is worth your time.

Does your billing stop when your email stops? If your purchase orders, approvals or invoices travel through the inbox, a day without email is a day without revenue, not an annoying day.

Is there a legal or contractual clock running? A tender deadline, a payroll deposit, a privacy incident to report promptly under Law 25: those deadlines do not pause because your provider is down.

Does anyone at your place already operate something? A file server, a website, a database. Not necessarily an IT department: one person who knows what a domain name is.

If you answered no three times, yesterday's outage cost you half a day of irritation and nothing else, and changing architecture would cost you far more than it would return. Read our breakdown of what an incident really costs an SMB instead: it will tell you where your money is genuinely at risk, which is probably not here.

If you answered yes at least twice, the rest is for you.


Nobody cut off the access

We have written here about the scenario of a political shutdown of the American cloud: sanctions, a decision taken elsewhere, a timetable nobody in Montreal controls. That risk is real, and it remains entirely intact.

Yesterday's outage has nothing to do with it, and that is exactly what makes it instructive. No political decision. No attacker. No commercial dispute. A configuration change, inside one of the most competent data centre operators in the world, and organizations in 74 countries lost their email for more than sixteen hours.

Nor is it an isolated accident. In January 2026, a loss of server capacity had already taken down several Microsoft 365 services at once in North America, for nearly ten hours. In July 2024, a faulty update from a third-party security vendor disabled 8.5 million Windows devices, under 1% of the global fleet according to the figure Microsoft gave, and that was enough to ground aircraft. And the problem is not specific to Microsoft: on 20 October 2025, an empty DNS record in a single Amazon Web Services region took down DynamoDB and around twenty other services for some fifteen hours, carrying off Slack, Atlassian and Snapchat along the way.

Four completely different causes. One thing in common: when the service is centralized, so is the outage. The blast radius is not set by how serious the mistake was, it is set by the architecture.


Email itself did not go down

Here is the fact almost all the coverage missed. Through those sixteen hours, the internet's email system worked normally. Messages kept moving between every server on the planet that is not at Microsoft. What was unreachable was not email: it was the mailboxes hosted in one place.

And the messages addressed to them were not lost. They waited. Not by luck: because the standard says so. SMTP, defined by RFC 5321, in force since October 2008, states plainly that mail which cannot be transmitted immediately must be queued and retried periodically, that the interval between attempts should be at least thirty minutes, and that the sender should give up only after four to five days.

Now reread the detail from earlier: Microsoft extended its own expiry window to 48 hours. An open standard from 2008 asks every server on the planet to persist for four to five days, and it is that distributed stubbornness, written by a committee eighteen years ago, that acted as the safety net while the centralized platform settled for two days.

Email is the oldest federated service in the world, and the only one everybody uses without thinking about it. Nobody owns email. There is no central email server. Each organization runs its own, or rents one, and they all speak through a common standard. That is why an outage at one provider, however enormous, stays an outage at one provider and not an outage of email.


Changing vendors is not changing architecture

The reflex after an outage like this is to look elsewhere. Google Workspace, maybe. Another cloud, another contract, another logo.

That changes nothing. You will have moved your single point of failure, not removed it. The day the other one goes down, you will live exactly the same day, with the same helplessness and the same number of buttons available to you: zero.

There are three possible architectures, and only the third changes the outcome.

Architecture What it looks like What happens when it breaks
Centralized Everyone at the same provider, on the same platform Everyone goes down together, and nobody on your side can do anything
Split across vendors Email at one, files at another, video calls at a third One function fails at a time. Better already, but each function stays a single point
Federated Each organization runs or rents its own server, and the servers speak an open standard One server fails, the others carry on. The radius stops at the edge of the affected organization

Decentralization is not another vendor. It is the absence of a centre.


What federation does differently

Email proves the model works at planetary scale, and has for forty years. Three other standards apply it to what SMBs actually use today.

Matrix, for team messaging and video calls, is the direct answer to Teams and Slack. Its specification says so in its opening sentence: a set of open APIs for decentralised communication over a global open federation of servers with no single point of control. The property that matters is this one: room data is replicated across all of the homeservers whose users take part in a given room, and no single homeserver owns or controls that room. If your provider's server goes down, your exchanges with other organizations still exist, at their end. We covered the deployment in our guide to Matrix and Element.

ActivityPub does the same for public publishing. It has been a W3C Recommendation since 23 January 2018, which makes it a web standard in the same sense HTML is. It is what powers Mastodon and much of what people call the fediverse.

Open Cloud Mesh, carried by the GÉANT association, handles file sharing between independent servers. It is the mechanism behind Nextcloud's federation: two organizations that each run their own instance share folders with each other without either one depositing its files with a common third party. Our overview of Nextcloud Hub covers the rest of the suite.

In all three cases the property being sought is the same, and it is a modest one: your outage becomes your outage again. It lasts as long as you decide to let it, and it concerns only you.


What federation does not fix

An article that stopped here would be selling you something. Here is the other half.

Your server can go down, and it will be yours. Yesterday, the 140,000 people reporting the problem would have confirmed within thirty seconds that it was not your fault. When your own server goes down, there is no status page, no crowd, no press statement: there is you, and a ringing phone. A well-chosen federated provider does not make that risk disappear, it brings it closer.

"Free software" is not "free of cost". The right to use it costs nothing, everything else costs somebody's time. Updates, verified backups, certificates, monitoring: that is a recurring load, not a project that ends. The real question is never "is it free", it is "who looks after it on a Tuesday morning".

Do not host your own email. It is the most consistent recommendation we give, and it is worth repeating inside an article that praises email. Sending reputation, blocklists, filtering: that is a full-time trade and a bad first project. An independent host on an open standard gives you reversibility without the burden.

Not everything federates. Your accounting does not replicate to your partners, and that is for the best. For an ERP, the right question is not federation, it is the licence and where the instance runs.

And comfort drops, at least at first. Centralized platforms are pleasant because a single team controls everything end to end. A federated world has visible seams. You accept them in exchange for something else.


Shrink the radius, don't rip everything out

Nothing above implies a migration. A full migration is a multi-quarter project, and it is not what a sixteen-hour outage should set off.

What it should set off is an honest inventory: what, at your place, stops when a single provider stops? The answer is almost always longer than expected, because single sign-on ties together things you believed were independent.

Three moves that fit inside a week, before even discussing changing anything:

  1. Write down the fallback route for reaching your ten most important clients without your usual mail system, and test it once.
  2. Check that at least one essential service does not depend on the same sign-on as the others, so an identity outage cannot close every door at once.
  3. Pull a copy of your data out of the platform, readable without it, and open the file to confirm that it opens.

Only then comes the question of order, and it gets decided layer by layer rather than all at once. The seven decisions to make before installing anything cover that ground, and the Collabora and OnlyOffice comparison handles the office layer, which is often the first one.

A second article follows in a few days with the full table: for every Microsoft product an SMB actually buys, the free software replacement, its licence and its honest catch.


At Blue Fox

We deploy free software hosted in Quebec, under the client's control, and we favour open protocols wherever one exists: Matrix rather than a proprietary messenger, Nextcloud and its federation for files, an IMAP mailbox at an independent host for email.

With one caveat we would rather write than leave unsaid: trusting us with your hosting is still a dependency. We will go down too, one day. What changes is not a promise never to fail, it is the size of the radius and the nature of the exit. When the software is under a free licence and the protocol is open, leaving comes down to a copy of your data and a DNS change. There is no renegotiation, no captive format, no permission to request. That is the only guarantee worth anything, because it is the only one that does not depend on our goodwill.

If the inventory in the previous section gave you a longer list than you expected, let's talk about your situation.


Sources

A cyber incident with no insurance: what it really costs an SMB
Statistics Canada cannot publish the figure. Here is how to calculate yours.