Microsoft 365 Outage: Exchange Online Blocked – No Access to Mailboxes, but Data Intact
From 31 August 2026, 14:56 UTC, until 3 September 2026, 10:00 UTC, access to Exchange Online was disrupted worldwide: sign-ins failed, emails were stuck, and mailbox search returned nothing. Microsoft traced the incident (ID EX1464935, cross-service MO1465074) back to a core authentication configuration. There is no evidence of deleted mailbox data.
For those affected, this is the single most important distinction: no access is not the same as data loss. Anyone who overlooks that difference in the heat of the moment and starts deleting profiles, removing licences or recreating mailboxes can turn a temporary service outage into genuine, permanent data loss. That is exactly what this article is about.
What Exactly Happened During the Microsoft 365 Outage EX1464935?
On 31 August 2026, Microsoft announced via its official status channel that reports of problems with Exchange Online were being investigated:
“We're investigating reports of Exchange Online issues. Please see EX1464935 in the admin center for more information.” – Microsoft 365 Status (@MSFT365Status)
Shortly afterwards, Microsoft confirmed limited functionality in several areas of Exchange Online and then determined that the cause was not confined to the mail service:
“We've confirmed that the authentication component issue impacts other services beyond Exchange Online.” – Microsoft 365 Status (@MSFT365Status)
The final, cross-service advisory MO1465074 describes the cause as follows:
“An issue within a core authentication configuration used by multiple Microsoft 365 services was resulting in impact.” – Microsoft Service Health, MO1465074
In plain terms: a central sign-in component – the part of the cloud that checks whether a user or an application is allowed to connect – was misconfigured. Because several Microsoft 365 services use the same component, a whole range of different access paths failed simultaneously: Outlook on the web, Outlook for iOS and Android, Outlook for Mac, Exchange Web Services (EWS, the programming interface for calendar and mailbox access) and functions in the Exchange Admin Center.
On 1 September 2026, sending and receiving largely recovered according to heise online, though Microsoft was still working through a delivery backlog; calendar functions remained partially limited. On 2 September, Microsoft reported stable service availability of over 99 per cent, according to BleepingComputer. On 3 September 2026 at 10:00 UTC, the entry in MO1465074 read simply: “Impact is fully resolved.” By 5 September 2026, the incident was listed as “postIncidentReviewPublished”, and the public status page showed all products as operational.
A Figure That Is Often Misread
On 3 September, Microsoft stated that the remaining Outlook impact affected less than one per cent of the infrastructure. That is explicitly not a statement about less than one per cent of users. Microsoft has not published any reliable global figure for affected individuals or tenants. BleepingComputer, citing Downdetector, reported tens of thousands of user reports – that is an indication of sentiment, not a verified number of affected users.
Who and Which Devices Are Affected?
No device, hard drive or SSD was affected – this was a cloud service. There is therefore no affected Outlook version, no firmware level and no operating system to which the outage could be pinned. According to MO1465074, potentially all connection methods to Exchange Online were affected.
Services and functions explicitly named:
- Exchange Online: sending and receiving emails, mailbox search, EWS, room finder in the Outlook calendar, temporarily the download of email attachments, and administrative actions in the Exchange Admin Center.
- Dependent Microsoft 365 workloads: Microsoft Graph, Microsoft Teams (including search and presence status), Microsoft Purview, Defender XDR, Copilot, OneDrive for Business, SharePoint Online, Universal Print and the Microsoft 365 Admin Center.
How to Tell Whether You Were Affected
- Delays or error messages when sending and receiving emails.
- Sign-in errors or no connection to the mailbox at all – regardless of whether via browser, smartphone app or desktop client.
- Empty, incomplete or very slow search results in the mailbox.
- Calendars open, but the room finder does not work.
- Attachments cannot be downloaded.
- Sign-in to the Microsoft 365 Admin Center fails, or administrative actions abort.
- Beyond mail: Teams search and presence sluggish, SharePoint and OneDrive synchronisation stalling, Copilot requests involving Microsoft 365 failing.
How to Check Whether You Are Affected by the Exchange Online Outage
All of the following steps are harmless – they change nothing about your data.
- Check the public status page: at status.cloud.microsoft you can see the current global state. If all products are listed as “operational” there, that is an indication of the overall situation – but no proof regarding your individual mailbox or a specific message.
- Review Service Health in the Admin Center: authorised Microsoft 365 administrators will find the history view under Health > Service health. Search there for EX1464935 and MO1465074 and compare the time period, affected services and your own observations. Microsoft documents the ID, start time, impact, status and all updates there.
- If sign-in does not work: during the outage, authentication for the Admin Center itself was temporarily limited. For such cases, Microsoft points to the public status page and the @MSFT365Status channel.
- Run a functional test after the outage is resolved: send a non-critical test message to an external recipient and then check sending, receiving, search, calendar access and attachment download. Note the time, sender, recipient and any error messages.
- Trace individual disputed messages: authorised Exchange administrators can use Mail flow > Message trace in the Exchange Admin Center. Message tracing shows whether a message was accepted, deferred, rejected or delivered. Look out for status values such as Pending, Failed or Delivered – and bear in mind that this data can be delayed by five to ten minutes.
- Report remaining cases properly: if a specific problem persists after 3 September 2026, collect examples and open a case with Microsoft 365 Support. Do not automatically treat this as proof of deletion.
What You Should Do Now
The outage has been resolved. There are still sensible steps to take – but only those that cannot make anything worse:
- Stay calm and document. Record which messages you expected during the window from 31 August to 3 September and which never arrived. This list is the basis for any later investigation.
- Check first, then act. A functional test and message tracing come before any change to accounts, licences or mailboxes.
- Do not send mass re-sends. As long as the service status is unclear, repeated attempts to send identical mails only lead to duplicate deliveries and additional load. Instead, flag individual critical messages for later tracing.
- Only use alternative channels if they have already been approved. An outage is not a good time to spontaneously introduce new communication routes.
- Catch up on precautions. A cloud mailbox is not a backup. Anyone whose business-critical communication resides exclusively in Exchange Online should consider what an independent backup might look like – our backup assistant can help you weigh up the options.
What You Must Never Do
This is the most important section. In the case of EX1464935, no action has been documented that would have destroyed mailbox data – simply because Microsoft has published no evidence of lost mailbox data. The danger lies not in the outage itself, but in the reactions to it. The following steps can turn a pure access problem into definitive data loss:
- Deleting a mailbox or user account. A “recreate it and it'll work again” approach is useless in the face of a server-side authentication problem – and potentially fatal. Microsoft describes it as follows: after a hard delete, or once the 30-day retention period has expired, emails, contacts and files are permanently deleted and cannot be recovered. This applies in particular to removal via Remove-Mailbox -PermanentlyDelete.
- Removing the Exchange Online licence as a troubleshooting step. According to Microsoft's documentation, the associated data is only retained for a 30-day grace period and is deleted afterwards. Removing a licence does not repair an authentication configuration in the cloud – it merely starts a clock that runs against you.
- Resetting local Outlook profiles, deleting cache files or reinstalling clients while the server state is still unstable. In a situation like this, cached mailbox content is sometimes the only thing you can still access. Anyone who clears it away on reflex loses that buffer.
- Running data recovery software on local drives. The cause lay in the cloud infrastructure, not on your hard drive or SSD. A recovery tool writing to the very same drive only causes damage in this situation, without solving any problem at all.
- Initiating large-scale migrations or exports before Service Health and message tracing have been checked. Migrations carried out during an ongoing delivery backlog create inconsistencies that are difficult to untangle afterwards.
- Deleting emails, folders or calendar entries in a panic. Whatever is stuck in the backlog often arrives late. Whatever you deleted beforehand will not come back.
It is a pattern we see in data recovery every day: it is not the original fault that destroys the data, but the well-meant rescue attempt that follows. The delete command that was “only meant to tidy up”. The reinstallation that “will surely help”. The recovery program that writes to precisely the drive the data is supposed to be rescued from. These very actions are the most common reason why data ends up beyond saving.
Why Cases Like This Belong in Professional Hands – and How RESQ Helps in Practice
Neither you nor we can repair a cloud outage like EX1464935; the fix took place exclusively on Microsoft's service infrastructure. There was no client update, no firmware measure and no recall. What comes afterwards, however, is very much a job for specialists: the sober clarification of whether any data is actually missing – and if so, where it might still be.
The decisive difference between professional data recovery and an attempt at the kitchen table is the order of operations. At home, people usually act first and look afterwards. In professional data recovery, the opposite principle applies: first the condition, then a backup copy, and only then an intervention – and never on the original. We always work on a copy of the data set, so that every analysis step remains reversible. For local storage media, that means workstations with specialised equipment and, where the damage requires it, the cleanroom. For cases involving email outages, it means structured analysis: which messages demonstrably never arrived? Which are sitting in local caches, archives or on an old laptop that has not been switched on for weeks? Which drive holds the last complete export?
Often it turns out that the actual problem is not the cloud at all, but a device alongside it: a defective hard drive in the workstation holding the local mail archive, a NAS whose RAID array no longer starts up cleanly, or a laptop that will no longer boot. Our data recovery service at RESQ is designed for exactly these damage scenarios – from hard drive data recovery to RAID and NAS data recovery. If it is purely a device defect without data loss, repair is the right route.
How It Works at RESQ
- Free initial assessment. You describe the case to us – which device, what symptoms, what has already been tried. This assessment is provided in advance and free of charge: request a quote.
- An honest statement about the prospects. We tell you what is realistic based on our experience – even if the answer is: “There is no data loss here at all, just wait for the service to recover.” Data recovery is always assessed case by case; a successful outcome can never be seriously promised in advance.
- Quote. You receive a concrete breakdown before anything happens.
- Your decision. The actual work only begins once you give your approval. If you would like to get started right away, you can create an order via your customer account.
The core of our recommendation is simple: if you want to be sure your data is not lost through DIY attempts, have the case examined rather than experimenting with it.
Conclusion: Your Mailboxes Were Blocked – Not Deleted
The Microsoft 365 outage EX1464935, or MO1465074, was an availability and authentication incident, not a documented case of data loss. From 31 August 2026, 14:56 UTC, until 3 September 2026, 10:00 UTC, Exchange Online and numerous dependent services were restricted; Microsoft subsequently declared the impact fully resolved and announced a review of the core authentication configurations as well as additional monitoring.
So check the service status first, then message tracing – and leave mailboxes, accounts and licences untouched. If, after this check, you really are facing missing data, on a defective drive, a failing hard disk, a NAS that can no longer be reached or a laptop that will not start: do not touch anything further and have RESQ assess your case free of charge. A factual assessment costs you nothing – a hasty delete command can cost you everything.
