A Microsoft 365 outage that began on Thursday evening, 12 November, disrupted access to Exchange Online mailboxes for organisations around the world. Microsoft’s incident record puts the start at 16:17 UTC, or 8:17pm UAE time, and recovery work continued into Friday morning. Exchange Online was the main service hit. Teams, SharePoint Online, Copilot and Defender XDR were also listed as affected, along with the admin portals that IT teams use to check what is wrong.
Microsoft hasn’t shared a root cause yet. It has shared enough for IT teams to plan their next steps, though, and the most useful lesson concerns the parts you control.
What happened on 12 November
Two times matter here, and they’re easy to mix up. The Exchange Online incident, EX1550543, is recorded in Service health as starting at 16:17 UTC. Microsoft’s first public post on the Microsoft 365 Status account on X came later, at about 17:54 UTC, saying users in the Americas were having trouble accessing their mailboxes. A second incident, MO1550821, was opened for the impact on other Microsoft 365 services.
| Time (UTC) | UAE time | What happened |
|---|---|---|
| 16:17, 12 Nov | 20:17, Thu | Recorded start of EX1550543 in Service health: users unable to connect to Exchange Online mailboxes |
| About 17:54, 12 Nov | About 21:54, Thu | First public post on X: investigating mailbox access problems in the Americas |
| Shortly after | Shortly after | Microsoft says users in any region may face Microsoft 365 connection problems |
| About 18:26, 12 Nov | About 22:26, Thu | MO1550821 opened for Microsoft 365 services that depend on Exchange Online |
| 18:35 to 19:12, 12 Nov | 22:35 to 23:12, Thu | Traffic moved, changes paused, affected servers restarted |
| About 20:19, 12 Nov | About 00:19, Fri | No recent change found that matches the start of impact; failed health checks may come from a component that processes them |
| About 21:00, 12 Nov | About 01:00, Fri | A different health check method brings some servers back into service |
| About 00:06, 13 Nov | About 04:06, Fri | Restored servers work at first but can stop responding again once traffic returns |
According to Arab News, Downdetector received reports from 74 countries and territories within about an hour. Any figure for total downtime is provisional until Microsoft publishes its report.
The list of affected services grew through the night. Exchange Online, Teams, SharePoint Online, Microsoft 365 Copilot, Defender XDR and Defender for Office 365 were named first. Later updates added Planner, To Do, Windows 365, cloud printing and mobile device management. The Register reported that Intune and the Microsoft 365 Apps Admin Center also went down.
What Microsoft has said about the cause
Microsoft first described the problem as high load, then corrected itself: overall traffic hadn’t gone up. A number of servers had dropped out of service, and the rest couldn’t carry all the connections on their own.
The servers dropped out because they were failing automated health checks. Microsoft’s updates point at a component on those servers that is responsible for processing the health checks, and they also mention elevated processor usage. Microsoft has described that component as where the failures may originate. It hasn’t said what made it fail, and it hasn’t called it the root cause.
The question of a recent change is also still open. At around 20:19 UTC, Microsoft said it had found no recent change that lined up with the start of impact. Later, SecurityWeek reported that Microsoft was looking at a small number of configuration changes and had started rolling one back to see whether it helped. That’s a line of investigation. Microsoft hasn’t confirmed that any change caused the outage.
Recovery was slow because the fixes only partly worked. Some servers came back using a different health check method, then stopped responding again once users reconnected. By early Friday, engineers were isolating parts of the infrastructure, restarting components and adding traffic back in stages.
Microsoft has disclosed no evidence of a cyberattack. As of Friday 13 November, neither incident has a confirmed root cause. For major incidents, Microsoft publishes a post-incident report under Service health in the Microsoft 365 admin centre. Wait for that report before you share any explanation inside your organisation.
How the Microsoft 365 outage affected UAE organisations
Start with what’s confirmed. By Friday morning, Outlook, Microsoft 365 and Teams were the three most reported services on Downdetector’s UAE site, with a sharp rise at 8:42am, according to Gulf News. Those are user reports. They show people in the UAE couldn’t use the services. They don’t tell you which organisations or sectors were hit, and no public source we’ve seen names any.
The timing softened the blow for many offices. The incident began at 8:17pm UAE time on Thursday, after most staff had finished for the day.
That doesn’t apply to everyone. Banks, hospitals, utilities, airlines, logistics firms and government departments often have teams handling operations outside normal office hours. Where those teams depend on Microsoft 365, an evening Exchange outage can mean missed payment confirmations, delayed referrals between clinics, shift handovers that never arrive and customer emails that go unanswered until morning. Whether that happened inside any particular organisation is something only its own records will show.
For users, there were three separate problems.
First, Outlook couldn’t reach mailboxes through Outlook on the web, MAPI, ActiveSync or the REST API, so email failed on desktop, mobile and browser at the same time.
Second, Teams and other collaboration tools lost any feature that depends on Exchange. Microsoft said features linked to Exchange Online and email were affected while other features kept working. That’s why some users could chat in Teams but couldn’t see their calendar or schedule a meeting. Connectors built on Microsoft Graph also failed.
Third, and hardest for IT teams, the admin portals went down. With Intune and the admin centres unavailable, administrators couldn’t check service health, apply a fix or update users from their usual tools. Microsoft asked admins to use status.cloud.microsoft if the admin centre was unavailable. Administrators who had not bookmarked the page had to find an alternative way to access Microsoft’s service updates.
Security teams had a gap too. Defender XDR and Defender for Office 365 were on the affected list, so security tools that run inside Microsoft 365 may not have worked fully during the same hours. If your SOC depends only on Microsoft tools, ask your provider what they could and couldn’t see between Thursday evening and Friday morning. A SIEM that also collects firewall, endpoint and identity logs from outside Microsoft 365 keeps some visibility when Microsoft 365 itself is down.
How email continuity keeps mail running
You can’t fix Microsoft’s servers. You can decide whether your email keeps working when they fail.
That’s the job of an email continuity service. Mimecast and Proofpoint both offer email continuity for Microsoft 365 environments. Both route and retain email through their platforms, so users can still reach their messages when Exchange Online is unavailable. Their continuity mechanisms differ, though, particularly in how an outage is detected, how continuity is activated and where users access their mail. Many UAE organisations already route their mail through one of the two for filtering, so the question is often whether continuity is licensed and set up, not whether to buy a new gateway.
Mimecast Mailbox Continuity
Mimecast treats spotting an outage and switching to continuity as two separate things.
Detection comes from a Continuity Monitor, which an administrator configures in advance in the Mimecast Administration Console. It checks inbound mail flow, outbound mail flow or both, in two-minute cycles, and alerts administrators when the flow stops against the thresholds you set. The monitor is the early warning. Whether an alert leads straight to failover, or simply tells someone it’s time to act, depends on how it has been configured, so check what yours is set to do before you rely on it.
Activation happens through a continuity event. An administrator can start one from the console when an outage hits, or schedule one ahead of planned maintenance. While the event is active, users send and receive through Mimecast instead of Exchange.
Outlook users get an extra layer through the Mimecast for Outlook plug-in, which checks for continuity events every three minutes. When Outlook continuity is enabled, the plug-in can automatically switch users into continuity mode within 15 minutes of an Exchange outage, according to Mimecast’s documentation on managing continuity events. The switch happens when Mimecast holds a message that can’t be found on Exchange, so not every user necessarily moves over at the same time. Users must also be signed in to the plug-in.
In continuity mode, Outlook goes offline, new mail lands in the inbox through Mimecast, and sent mail goes out through Mimecast with a copy saved in Sent Items. Users without the plug-in can use Mimecast’s web and mobile apps. The plug-in also has an automatic failover setting that reacts to Outlook’s own connection state. Mimecast recommends leaving it disabled because that state isn’t always reliable and can trigger continuity when nothing is wrong with Exchange.
Once Exchange is working again, the administrator ends the event and mail flows back through Exchange. Mimecast removes duplicate messages from around the start and end of the event, so users don’t see the same email twice. Mimecast’s email continuity product page and FAQ state that the service supports continuity for up to seven days per outage. Your own order form and service terms are what apply to you, so confirm the duration there.
Proofpoint Emergency Inbox and Enterprise Continuity
Proofpoint Essentials switches on by itself. Its Essentials brief for Office 365 says the Emergency Inbox activates when it detects an Office 365 email outage, with no administrator action needed.
Proofpoint uses three related features here, and they do different jobs:
- Email spooling holds incoming messages while your mail server can’t accept them, then delivers them once it’s available again.
- Emergency Inbox gives users access to that incoming mail during the outage. They sign in to the Proofpoint web interface to read, reply and send. The Emergency Inbox fills as soon as Proofpoint can’t deliver to the affected domain.
- Instant Replay is for recovery afterwards. It lets users resend messages Proofpoint has already filtered to their mail server, for example ones deleted by mistake. It needs a working mail server, so it doesn’t help while Exchange is down.
Proofpoint’s Essentials package documentation lists 30 days for each of the three on eligible Proofpoint Essentials packages. Availability varies by package, so check which features yours includes. Where all three are included, that’s 30 days of Emergency Inbox access and 30 days of spooling during an outage, plus a 30-day window for replaying earlier mail, which are different promises.
Larger organisations running Proofpoint Enterprise Protection use Proofpoint Enterprise Continuity. It gives users access to the most recent 30 days of email, either within Outlook or through a web portal, and routes messages back to the right Inbox or Sent Items folder once the primary service is restored. It’s a separate product, so check it’s on your licence.
The limits of both
- Both services must be licensed and configured before an outage. Proofpoint Essentials can automatically activate its Emergency Inbox when an outage is detected, while Mimecast offers configured monitoring and administrator-controlled continuity activation. Your mail-flow configuration must already be set up to use the provider’s continuity service. Mimecast deployments require the appropriate MX routing, while Proofpoint requirements depend on the deployment method and licensed continuity features.
- They cover email only. Teams, SharePoint, OneDrive, Intune and Copilot stay down.
- Mimecast’s Outlook plug-in only works in continuity mode if Cached Exchange Mode is turned on. Users in online mode won’t get continuity through the plug-in.
- During a Mimecast event, only email and calendar items are delivered, and Exchange mailbox rules don’t run, so mail that normally goes into folders lands in the inbox.
- Proofpoint Essentials users work in a separate web inbox, so staff need to know where it is and how to sign in before they need it.
Where email carries customer service, payments or regulator correspondence, a few hours without it causes real damage. Continuity gives you a second route for sending and receiving while Exchange is down, and it belongs in the business continuity plan alongside everything else.
What to do before the next outage
Some of these steps take one morning, while others need budget approval. Start with the first few while Thursday night is still fresh.
- Record what happened in your organisation. Note when users lost email, when it came back, which services failed and which work stopped. You may need this information when assessing eligibility for a service credit under Microsoft’s SLA and updating your risk register.
- Read Microsoft’s post-incident report when it’s published. Check Service health in the Microsoft 365 admin centre under EX1550543 and MO1550821. Use Microsoft’s own wording in any internal update.
- Give admins a way to get updates outside Microsoft 365. Save status.cloud.microsoft, follow the Microsoft 365 Status account, and make sure at least two people receive alerts on a channel that doesn’t depend on Microsoft 365.
- Decide how you’ll reach staff. If Teams and Outlook both stop, IT still needs a way to update every employee. Choose a backup channel now, such as SMS, a WhatsApp broadcast list or a phone tree, and test it once.
- Warn users about outage-related phishing. Attackers use big outages to send fake “verify your Microsoft account” emails. Send a short note asking staff not to click sign-in links in emails and to open the service directly instead.
- Make a decision on email continuity. If you use Mimecast, check that continuity is licensed, a Continuity Monitor is configured with alerts going to someone who’ll act on them out of hours, the Outlook plug-in is installed and Cached Exchange Mode is on for all users. If you use Proofpoint, confirm whether your package or licence includes the Emergency Inbox or Enterprise Continuity, check that your deployment method supports it, and show staff how to reach it. If you use neither, work out which teams would need email during an outage and whether continuity belongs in your business continuity plan.
- Keep independent backups of Microsoft 365 data. Backups and continuity solve different problems. Email continuity keeps people sending and receiving mail while the service is down. An independent Microsoft 365 backup lets you recover data that has been deleted, corrupted or otherwise lost. An outage like Thursday’s doesn’t automatically mean any data was lost, so a backup wouldn’t have kept email running. You need to decide on each one separately.
Microsoft will fix its servers on its own schedule. How long your organisation goes without email next time depends on what you put in place before then.
iConnect helps organisations assess their Microsoft 365 security, email continuity and wider business continuity arrangements. Our team can review your Microsoft 365, Mimecast or Proofpoint configuration to find where email access could be interrupted and what will reduce that risk.