If quarantined emails have stopped reaching the quarantine folder in your tenant, Exchange Online is why, not your mail flow rules. Microsoft traced this to a service-side code error it shipped itself, and the incident was still open as late as 22:01 UTC with a fix only partially deployed.
Started
11:38 UTC
Duration
Not closed by vendor
Source
IsDown
Next time
Microsoft 365 is degraded. Is your product working?
An incident on their side does not always mean an outage on yours, and the only way to know is to already be watching your own endpoints. Set that up in under a minute and you will be notified the next time your own site is affected. And there will be a next time.
50 monitors for your own websites. No card.
Affected components: Exchange Online
What happened?
Microsoft opened this incident at 11:38 UTC after reports that some users' email messages were not being quarantined and failed to be stored in the quarantine folder. The symptom was specific: legitimate messages that should have been held for review were instead failing with the message trace error "550 5.1.10 Failed to deliver to Quarantine store", which meant affected mail could not be released through the normal Microsoft Defender quarantine workflow. Microsoft's first few updates describe a slow investigation: reviewing support case details, then message IDs, then working with affected users to collect network message IDs to narrow down the failure. By 21:49 UTC Microsoft named a root cause, a recent service-side update that unintentionally introduced a code error causing the behaviour, and gave a start time of 12:56 AM UTC on 23 September, a day before this page's own incident start time. Microsoft then moved to developing and testing a code fix, and by the last update shown, at 22:01 UTC, the fix had reached 88 percent saturation across the affected environment, with completion estimated for 7:00 PM UTC on 2 October. Exchange Online is the only component Microsoft lists against this incident. Separately, the day's user reports to UptimeRobot cover a wider spread of complaints, including Planner failing to load, HTTP 500 errors on planner.cloud.microsoft, Power Apps unable to retrieve data from SQL, slow SQL connectors, and one US report of a tenant unable to send or receive email at 17:48 UTC. Microsoft's status page ties none of these other reports to this quarantine incident, and no separate filing from Microsoft explains them. Over the past 90 days Microsoft has logged 46 incidents with a median duration of 9 hours 25 minutes, and this one had already run well past that median by its final recorded update.
Learning
This incident sat inside Exchange Online's quarantine pipeline, a backend mail processing step that has no exposed endpoint for you to ping from outside. A synthetic check against your own mail servers or API endpoints would stay green throughout, because nothing on your side broke. The fault lived in Microsoft's own code deployment, confirmed by Microsoft's own root cause note, and only showed up as a message trace error that your support team would have to go looking for. That is the general shape of this kind of failure: the provider's internal processing breaks while every endpoint you control keeps answering normally. Watching your own infrastructure tells you your half is fine, it says nothing about whether mail quarantine is silently dropping legitimate messages. Your monitoring covers your half, UptimeRobot now watches the provider's half too, so next time you know which side broke without guessing.
