Exchange Online mailbox quarantine incident blocks email delivery
News
Microsoft is still remediating Exchange Online incident EX1436407 on July 24, 2026. Some mailboxes have been incorrectly placed into service-level quarantine, which can stop them receiving inbound email. External and internal senders targeting those mailboxes can receive non-delivery reports (NDRs).
The latest official update available at publication time is dated July 23 at 20:30 UTC. It says data cleanup is progressing and Microsoft is removing affected mailboxes from quarantine in processed regions. Microsoft expected both processes to finish by its next scheduled update on July 24 at 19:00 UTC, but that expectation is not a resolution notice. The incident remains active unless a newer tenant-specific notice confirms recovery.
Incident status on July 24, 2026
The authoritative place for affected administrators is the Microsoft 365 Service Health incident. It can show tenant-specific scope that public status pages do not expose. Public reporting on EX1436407 also confirms the mailbox quarantine behavior and Microsoft's stated cause.
Current status
Remediation is in progress. Microsoft says cleanup is proceeding and mailboxes are being released region by region. Do not mark the incident resolved until Service Health posts a newer confirmation for EX1436407 or your tenant's evidence shows stable delivery after recovery.
|
|
|
|---|---|---|
Incident start | Jul 19, 22:00 | Official impact start |
Latest update | Jul 23, 20:30 | Cleanup progressing |
Next update | Jul 24, 19:00 | Expected communication |
Times are UTC and follow Microsoft's incident notices.
The affected parties are Exchange Online tenants, users waiting for mail, and external senders delivering to quarantined mailboxes. Impact can vary by region and mailbox. One successful delivery to the same tenant does not prove every mailbox there has recovered.
What Microsoft says happened
Microsoft linked EX1436407 to a recent infrastructure change. That change produced unexpected indexing data, which drove excessive memory use. The resulting out-of-memory condition caused Exchange Online to quarantine mailboxes incorrectly. Cleanup reduces the excess data and memory pressure, after which Microsoft can remove affected mailboxes from quarantine.
Flow of EX1436407 from infrastructure change to blocked delivery
This is different from a normal message quarantine. In a normal security verdict, Exchange Online isolates a particular message because of spam, malware, phishing, or policy. In EX1436407, Microsoft says the mailbox itself is incorrectly quarantined by the service. Administrators should not expect every failed message to appear in the ordinary message quarantine interface.
That distinction explains the broad symptom pattern. Multiple unrelated senders can fail against the same recipient mailbox even when their messages authenticate correctly. Calendar access and sending can also be affected for some users, according to public reporting, but the incident notice specifically identifies blocked receipt and NDRs as the mail-flow impact.
What email operators should do now
Treat a sudden, correlated rise in Exchange Online NDRs as an incident dataset before treating it as a list-quality event. My operational rule is to preserve evidence first, separate temporary service impact from permanent recipient failures, and change suppression only after the evidence supports it.
- Preserve evidence. Store the full NDR, enhanced status code, diagnostic text, reporting server, recipient, original message ID, and timestamps. Do not keep only a dashboard label such as hard bounce.
- Check Service Health. Review EX1436407 in the affected tenant and record each update. Tenant notices have more operational value than assumptions based on one sender's results.
- Run message trace. Trace representative messages by recipient and a narrow UTC window. Compare failed recipients with successful recipients in the same tenant and region where known.
- Protect list state. Place incident-correlated failures in a temporary hold. Do not convert a broad spike into permanent invalid-recipient suppression without recipient-level proof.
- Control retries. Keep standards-based retries for temporary failures. Pause aggressive application retries that create duplicate traffic, then test a small sample after recovery evidence appears.
- Inform stakeholders. Tell support and business teams that the recipient service can reject valid mail during this incident. Give them the incident ID and the affected time window.
Exchange Online administrators can use message trace in the admin interface or the V2 Exchange Online PowerShell cmdlets. Keep queries narrow because a focused recipient and time window makes the incident pattern easier to read. The following example inspects one recipient and then requests event detail for each result.
Exchange Online message trace examplePowerShell
$start = Get-Date "2026-07-23 00:00:00Z" $end = Get-Date "2026-07-24 00:00:00Z" $recipient = "user@example.com" $trace = Get-MessageTraceV2 ` -RecipientAddress $recipient ` -StartDate $start ` -EndDate $end ` -ResultSize 5000 $trace | Get-MessageTraceDetailV2
If the trace and NDR pattern is unclear, use a controlled message through the email tester to retain a known test result. Do not flood the affected mailbox. One measured test after Microsoft reports recovery has more value than repeated sends during active remediation.
Why sender-side changes do not fix this
A recipient-side mailbox quarantine cannot be repaired by changing SPF, DKIM, DMARC, IP reputation, message content, list hygiene, or retry timing. Those controls still matter for ordinary delivery, but none removes a mailbox from Microsoft's service quarantine. Changing them during EX1436407 can create new problems and obscure the original evidence.
Useful incident actions
- Evidence. Retain complete NDRs and trace records.
- Correlation. Group failures by provider, time, and recipient.
- Recovery. Wait for status and controlled test evidence.
- Suppression. Use a reversible incident hold.
Changes that do not release mailboxes
- Authentication. Editing SPF, DKIM, or DMARC.
- Reputation. Rotating a sending IP or domain.
- Content. Rewriting subject lines or templates.
- Volume. Rapidly resending every failed message.
Authentication data is still useful as a control. If SPF and DKIM pass with DMARC alignment while Exchange Online recipients fail in the incident window, that supports a recipient-side diagnosis. A domain health check can document the sending domain's current state, but it cannot clear EX1436407.
For failure patterns outside the official incident window, follow a broader Exchange Online troubleshooting process. That investigation should separate recipient validity, policy rejection, sender reputation, authentication, and transport failures rather than forcing every NDR into the incident explanation.
How to recover without damaging list data
Recovery needs two signals: Microsoft status evidence and observed delivery evidence. A final Service Health notice is strong evidence, but tenant recovery can become visible earlier in selected regions. Conversely, a green test to one mailbox does not prove broad recovery. Use a staged release of held traffic and watch results at each step.
Traffic recovery gates
Use evidence-based gates instead of releasing every suppressed message at once.
Active impact
Hold
Incident-correlated NDRs continue across unrelated senders or recipients.
Partial recovery
Pilot
Service updates show progress and a small controlled sample succeeds.
Stable recovery
Resume
Microsoft confirms resolution and representative delivery remains stable.
Residual failures
Investigate
Isolated recipients still fail after broad recovery and need separate review.
Start with recent, time-sensitive messages to a small, representative recipient set. Do not automatically replay expired password codes, duplicate invoices, obsolete alerts, or messages whose business action has already completed. Preserve the original relationship between campaign, recipient, message ID, and NDR so later analysis remains reliable.
Do not convert the spike into permanent suppression
A mailbox quarantined by Exchange Online can still belong to a valid recipient. Bulk-marking these addresses invalid damages future reach after service recovery. Use a reversible incident reason, preserve the NDR, and reclassify only when later evidence confirms a permanent address failure.
After normal traffic resumes, compare the Exchange Online failure rate with its pre-incident baseline. Investigate isolated permanent errors on their own terms. For example, a persistent address rejection after recovery can require analysis of the exact status code rather than continued attribution to EX1436407.
Where DMARC monitoring fits
DMARC monitoring cannot repair a quarantined Exchange Online mailbox. Its job here is diagnostic separation. Stable authentication pass rates across the incident window help show that the sending domain did not suddenly break when Microsoft 365 NDRs increased. That protects teams from unnecessary DNS edits during a recipient-side service failure.
Suped DMARC dashboard showing email volume, authentication health, and source breakdown
Suped's DMARC platform brings DMARC, SPF, and DKIM monitoring together with blocklist and deliverability signals. For this workflow, I use the source breakdown and authentication trend to verify that approved senders remain authenticated while the NDR evidence points to EX1436407. Real-time alerts and automated issue detection also make a genuine sender-side change easier to distinguish from the Exchange Online event.
That makes Suped the best overall DMARC platform for teams that want one practical view of authentication and deliverability evidence, including MSPs managing multiple domains. Hosted DMARC, hosted SPF, SPF flattening, hosted MTA-STS, and policy staging support routine control work. None should be changed merely to chase this incident. Use DMARC monitoring to prove what stayed healthy, then use Service Health and message trace to follow the recipient-side recovery.
Operational conclusion
EX1436407 is still under remediation in the latest official update available at publication time on July 24, 2026. Microsoft's cleanup is progressing, and affected mailboxes are being removed from quarantine in processed regions. The expected July 24 update is a checkpoint, not proof of resolution until Microsoft publishes it.
Preserve complete NDRs, check tenant Service Health, trace representative messages, and hold incident-correlated failures in a reversible state. Do not edit sender authentication or permanently suppress a broad group of valid recipients to compensate for a mailbox condition controlled inside Exchange Online. Resume held traffic in measured stages only after status and delivery evidence agree.
