Defender for Office 365 quarantine workflow

When Defender for Office 365 (or its EOP foundation) detects spam, phishing, malware, or suspicious bulk mail, the message lands in quarantine rather than reaching the user's inbox. The quarantine workflow — who can see what, what actions they can take, what notifications they get — is one of the more configuration-heavy surfaces in Defender for Office 365. Getting it right balances security against user friction.

What goes to quarantine

Messages are quarantined based on filter outcome:

• Spam — high SCL but not phishing.
• High-confidence spam — very high SCL.
• Phishing — credential phishing or business email compromise patterns.
• High-confidence phishing — very high-confidence phish detections.
• Bulk — large-volume marketing email (depending on policy).
• Malware — files containing known or suspected malware.
• Spoof — failed authentication checks (SPF, DKIM, DMARC).
• Impersonation — appearing to be from a protected user or domain.

Each category has its own default behaviour and admin / user permission set.

Quarantine policies

A quarantine policy defines:

• Which actions users can take on quarantined messages of each type.
• Whether users get notifications about quarantined messages.
• Whether users can release messages themselves or must request release from admins.

Microsoft ships three preset policies:

• AdminOnlyAccessPolicy — only admins can see and act; users see nothing.
• DefaultFullAccessPolicy — users can view, release, report.
• DefaultFullAccessWithNotificationPolicy — same plus periodic notification emails to users.

For low-risk categories (Bulk, Spam), users typically get full access. For high-risk (High-confidence Phishing, Malware), admin-only is the right default.

User notifications

When configured, users receive a periodic notification email listing recently quarantined messages with summary info and links to act on them. Configurable cadence — usually daily.

Users can also browse their own quarantine in the Defender quarantine portal at security.microsoft.com/quarantine (with user permissions). They see only messages addressed to them, with the actions the policy allows.

User actions

Depending on policy, users can:

• Preview the message content (with safe rendering — links are not clickable).
• Release the message to their inbox.
• Request release for an admin to approve.
• Report as not junk (false positive feedback).
• Block sender (add to their personal block list).
• Delete the quarantined copy.

For high-confidence phishing, the default is request release — users can request, admins approve. Prevents users from inadvertently releasing real phishing.

Admin actions

The full admin quarantine view at security.microsoft.com/quarantine:

• View all quarantined messages across the tenant.
• Filter by recipient, sender, subject, detection type, date.
• Bulk actions — release many at once.
• Submit to Microsoft as false positive or false negative for filter improvement.
• Approve user release requests.
• Custom retention — extend beyond the default 30 days for specific investigations.

Default retention

Quarantined messages are retained for 30 days by default, then auto-deleted. Configurable per policy (down to a minimum or up to 30 days maximum).

After auto-deletion, the messages are unrecoverable. For investigations on older events, query the audit log for the quarantine event, not the message itself.

Common configuration patterns

A reasonable starting baseline:

• High-confidence phishing, Malware — admin-only access, no user notification. Admin reviews and decides.
• Phishing — request-release for users, with admin approval.
• High-confidence spam — full user access, daily notifications.
• Bulk — full user access, daily notifications.
• Spoof — request-release.

Adjust based on observed false-positive rates and user feedback.

Submission and Microsoft feedback loop

When users / admins submit quarantined items as false positive ("this isn't really spam") or genuinely-missed mail as false negative, the data flows to Microsoft's filter team for engine improvement. Healthy submission practice contributes to better filtering over time.

Configure user reported settings in the Defender portal to route Outlook's "Report" button reports to the right submission pipeline.

Operational considerations

• Tune false positives during initial rollout — be ready for user complaints.
• Track approval-request volume — high volume signals filter tuning needed.
• Educate users about quarantine — many ignore notifications without understanding the value.
• Audit periodically — what's being quarantined, what's being released, false positive trends.

For tenants with significant inbound email volume, quarantine is a daily operational surface. Get the policies right; communicate to users; iterate based on patterns. The alternative — broken filters releasing phishing or blocking legitimate mail — has real costs.