Exchange Online Quarantine Healthy Mailboxes

When Microsoft flags a healthy mailbox for quarantine under incident EX1436407, the instinct is to wait and hope it resolves itself. Sometimes that works. Often it does not, and legitimate email sits blocked while you try to figure out what went wrong.

This is a practical guide for the admin in that situation. It covers what EX1436407 means, how to check whether your mailbox is affected, how to release it, and how to verify that email authentication is not contributing to the problem.

---

What Is the EX1436407 Incident?

EX1436407 is a Microsoft Exchange Online incident in which inbound delivery for legitimate mailboxes was incorrectly blocked and messages were quarantined. Microsoft describes it as an issue affecting the inbound mail flow pipeline, where messages from external senders were being held in quarantine even though the sending domains had no obvious problems.

Microsoft posts incident status at the Microsoft 365 Admin Center under Health > Service health. If your organization is affected, you will see a yellow or red indicator next to Exchange Online. The incident description typically reads something like "Users may experience delays or failures receiving inbound email" with quarantine as a secondary effect.

The timeline for resolution varies. Microsoft usually publishes a post-incident report within 48 hours of resolution that includes root cause, affected user count, and the fix that was applied.

---

How to Check if Your Mailbox Is in Quarantine

The quarantine view in Exchange Online is separate from the regular message trace. Here is where to find it:

1. Sign in to the Microsoft 365 admin center at admin.microsoft.com
2. Go to Exchange admin center (exchange.admin.microsoft.com)
3. Navigate to Mail flow > Message trace (to confirm delivery attempts were made)
4. Then go to Protection > Quarantine (the actual quarantine holding area)

You can also go directly to security.microsoft.com/quarantine for the unified quarantine view in the Microsoft Security portal.

In the quarantine view, filter by:

Recipient address (the mailbox you suspect is affected)

Message direction (inbound)

Not delivered reason (look for "Quarantined" or "Blocked")

If messages appear in quarantine for the affected recipient, note the sender addresses, subject lines, and timestamps. This will help you determine whether the messages are legitimate business correspondence.

---

How to Release a Quarantined Mailbox in Exchange Online

If you confirm the mailbox is quarantined, releasing it requires admin-level action. Regular users cannot release their own mail from quarantine in this scenario.

1. In the Microsoft Security portal (security.microsoft.com), go to Email & collaboration > Review > Quarantine
2. Filter by the affected recipient address
3. Select the quarantined messages
4. Choose Actions > Release to selected messages
5. Confirm the release

The message will be delivered to the mailbox within a few minutes. If release fails, it may be because the message matched a high-confidence policy (for example, high-confidence phishing or malware). In that case you need to check the quarantine policy and may need to add the sender to an allow list in the anti-spam policy.

After releasing, monitor the mailbox for a few hours to confirm normal delivery resumes and no new messages are being diverted.

---

Is the Quarantine a False Positive? A Quick Checklist

Before assuming this was a false positive caused by EX1436407, run through this checklist:

Content scan result: Was the message flagged by content filtering, not just transport rules? Check the quarantine detail panel for the detection reason.
Sender reputation: Does the sending domain have a clean sending history? A sudden spike in volume can trigger threshold-based filtering even for legitimate senders.
Authentication status: Did SPF, DKIM, and DMARC all pass for the sending domain? If authentication failed, quarantine is more likely a correct detection rather than a false positive.
Policy match: Was the message caught by a specific policy rule? Check whether a custom mail flow rule is inadvertently catching legitimate messages.
Message volume anomaly: Was there a sudden increase in inbound volume for this mailbox? High-volume periods during incidents can trigger rate-limiting that manifests as quarantine.

If the answer to most of these is "this looks fine and normal," you are probably dealing with a false positive triggered by the incident rather than a genuine threat.

---

Could Email Authentication Be Causing This?

Email authentication failures do not directly cause Exchange Online to quarantine a mailbox. What they do is remove the authentication cushion that helps legitimate mail survive content filtering. During an incident like EX1436407, that cushion matters more, not less.

Specifically:

SPF failures: If your domain sends email but the SPF record does not include the sending IP, receiving servers may reject or flag the messages. During a Microsoft incident, these flags can manifest as quarantine instead of soft bounce.
DKIM failures: If outgoing mail is not DKIM-signed correctly, it does not directly trigger quarantine. But it degrades deliverability scores and increases the chance a message is held during a period when the mail pipeline is already under stress.
DMARC alignment failures: This is the one that often surprises admins. If your domain sends mail from an IP that is not in your SPF record, or the DKIM signature does not align with your From domain, DMARC alignment fails. The message arrives without any authentication backing, which means the receiving server evaluates it purely on content. During an incident where content filters are more aggressive, that is a bad position to be in.

The practical point: authentication failures do not cause quarantine on their own, but they make quarantine more likely when combined with unusual incident conditions. And if you are already in an incident and you are also sending mail that fails DMARC alignment, you are fighting on two fronts at once.

This is exactly when DMARC reports become useful, even though most teams never look at them. DMARC reports tell you which sending sources are passing SPF and DKIM, and which are failing alignment. During EX1436407, the last thing you need is to discover that a third-party sending service you use has been sending mail that fails DMARC alignment. DMARCFlow parses those incoming DMARC reports and gives you a human-readable summary so you can spot alignment failures before they become a second problem.

---

How to Verify SPF, DKIM, and DMARC Are Working

If you want to rule out authentication as a contributing factor, here is what to check:

SPF verification: Use a DNS lookup tool to check your SPF record. A typical SPF record for a Microsoft 365 tenant looks like:


v=spf1 include:spf.protection.outlook.com -all

Run nslookup -type=TXT yourdomain.com and verify the record exists and includes the correct include statements for your email sending sources.

DKIM verification: In the Microsoft 365 admin center, go to Exchange admin center > Mail flow > DKIM. Check whether DKIM signing is enabled for your domain. You can also send a test message to a tool like check-auth@verifier.port25.com to see whether DKIM passes.

DMARC verification: This is where most teams have the least visibility. A DMARC record lives at _dmarc.yourdomain.com. You can check it with DNS lookup, but the actual reports that tell you what is happening with your mail arrive as XML files from receiving servers, and most teams never open them. During an incident like EX1436407, that is exactly when you need to know whether your sending sources are cleanly passing authentication.

DMARCFlow parses incoming DMARC reports and gives you a plain summary of which sources are passing SPF and DKIM, which are failing, and whether alignment is clean across your domain. If you manage Microsoft 365, the fastest way to audit your authentication posture right now is to check your DMARC reports with DMARCFlow. You will find out within a few minutes whether any of your sending sources are generating alignment failures that would make your mail more vulnerable during an incident.

---

Your Exchange Online Quarantine Recovery Checklist

When a healthy mailbox gets caught in a Microsoft incident, work through this sequence:

1. Check Microsoft 365 Service Health for active incidents (admin.microsoft.com > Health > Service health)
2. Check the quarantine view at security.microsoft.com/quarantine for the affected mailbox
3. Review message trace in Exchange admin center to confirm delivery attempts were made
4. Release quarantined messages if you confirm they are legitimate
5. Check whether an anti-spam policy or mail flow rule is inadvertently catching valid mail
6. Verify SPF, DKIM, and DMARC for your sending domains to rule out authentication as a contributing factor
7. Monitor the mailbox for 24 hours after release to confirm normal operation resumes
8. Document the affected mailboxes, sender addresses, and release actions for reference

---

Frequently Asked Questions

Can DMARC failures cause my mailbox to be quarantined?

No. DMARC failures do not directly trigger Exchange Online quarantine. What they do is remove the authentication cushion that helps legitimate mail survive content filtering. During an incident like EX1436407, mail from a domain with failing DMARC is more likely to be quarantined because it cannot rely on authentication checks to establish legitimacy. Fixing DMARC alignment is not a guarantee against quarantine during incidents, but it removes one variable that works against you.

How long does Exchange Online keep quarantined mail?

By default, Exchange Online holds quarantined messages for 30 days. After that window, the messages are deleted. Spam and bulk mail are held for 15 days. This means if you are dealing with a false positive during an incident, you have time to release the messages, but you should not leave the resolution for weeks.

Who can release a quarantine in Microsoft 365?

Admin roles that can release quarantined messages: Exchange Administrator, Security Administrator, or a custom role with "Quarantine" permissions. A regular end user can only release their own messages if the quarantine policy allows user release, which is typically disabled for high-confidence phishing but enabled for spam and bulk mail.

How do I stop healthy mailboxes from being quarantined during future incidents?

There is no way to prevent Microsoft from quarantining mail during an active incident. What you can do is reduce the likelihood that your own outbound mail triggers filters: keep your SPF record current, enable DKIM signing for your domain, and set a DMARC policy of p=quarantine or p=reject to give receiving servers a clear instruction on what to do with unauthenticated mail from your domain. On the inbound side, review your anti-spam policy thresholds and consider adding trusted senders to an allowed senders list if you are seeing consistent false positives.

---

Related Articles