In most of the Microsoft 365 environments I work with, the arguments start as soon as an email lands in quarantine. Users want their missed messages back quickly, and the security team wants nothing dangerous getting through. The feature that settles this, and rarely gets much attention, is quarantine policies in Defender. These policies define exactly what users, helpdesk staff and admins can do with quarantined emails. Configure them badly and you'll end up with either a real incident or a flood of support calls.

Quarantine policies sit in the Defender portal and decide who can act on held mail

The settings are in the Microsoft Defender portal under Email & Collaboration → Policies & rules → Threat policies → Quarantine policies. For each policy you decide who can release their own messages (Release), who can only ask an admin to release them (Request release), and when only admins can act. High confidence phish and malware verdicts need the most care. Never enable self-release for these, because that lets users bypass the filters entirely. Set the policy up so that only admins can approve and process those releases. Microsoft's documentation on quarantine policies lists the detailed options and gives a good overview for each verdict type.

Release rights should depend on the verdict

The hard part is finding a balance between productivity and security. Many organizations let users release messages tagged as "Bulk" or regular "Spam" themselves, which cuts helpdesk tickets and frustration. High confidence phishing, malware and Zero-hour Auto Purge (ZAP) verdicts are different, and only admins should handle them. I've seen plenty of tenants where quarantine policies were loosened, usually because end users complained. Sooner or later risky messages get through that way, and sometimes the damage is serious. I recommend checking regularly which verdicts show up most often and confirming that your policy assignments actually stop dangerous releases.

From my own experience, restrict release to admins for high confidence phish and malware, with no exceptions. Nothing else does more to prevent a breach through quarantine.

Notifications keep users informed while policies are assigned inside threat policies

Quarantine notifications are configured globally in the Defender portal ("Email & collaboration" → "Policies & rules" → "Threat policies" → "Quarantine notifications"). Here you set how often users hear about newly quarantined messages, and once a day is usually enough to keep them aware. Keep in mind that notifications don't grant any release rights. Those come only from the assigned quarantine policy.

You don't assign these policies to users directly. You assign them inside your anti-spam, anti-phishing and anti-malware policies. Whenever you create or change one of those rules, you can pick a quarantine policy that governs what happens to the messages it catches. A mistake I see often is sticking with the default policies, which tend to be too permissive, or forgetting to update the assignment after adjusting the anti-spam setup. Microsoft's guide to managing quarantine is a good reference for getting the assignments right.

Admins need a fixed routine for handling release requests

When users can't release messages themselves but can request a release, those requests show up in the Defender portal. Without a clear admin process they pile up and turn into a blind spot. In larger tenants I recommend scheduled reviews and notifications for new requests. To get a quick view of release request activity, run this KQL query in Defender portal → Hunting → Advanced hunting (you need Defender for Office 365 Plan 2 and the right permissions):

EmailEvents
| where ActionType == "QuarantineReleaseRequested"
| project Timestamp, RecipientEmailAddress, Subject, SenderFromAddress

It shows spikes in release requests, which often point to a misconfigured policy or a phishing campaign in progress.

A simple diagram makes the quarantine flow easier to follow

In my workshops, a basic diagram helps teams see how the flow works. This is the overview I use:

flowchart TD
Inbound["Mail received"] --> Filter["Defender filter (Spam/Phish/Malware)"]
Filter -->|"Verdict: Clean"| Inbox["Inbox"]
Filter -->|"Verdict: Spam/Bulk"| Quarantine["Quarantine"]
Filter -->|"Verdict: High Conf. Phish/Malware"| Quarantine
Quarantine --> Policy["Quarantine policy checks user rights"]
Policy -->|"Self-release allowed"| Release["User releases"]
Policy -->|"Request release only"| Request["User requests release"]
Request --> Admin["Admin reviews & releases if safe"]
Policy -->|"Admin-only"| Admin

Figure: Quarantine process with different policy options

My best practices put security first and still reduce tickets

This is what has worked for me across tenants:

  • Never allow self-release for high confidence phish or malware
  • Consider letting users release bulk or spam themselves, and review it regularly
  • Turn on once-daily quarantine notifications so users stay informed
  • Check regularly what actually gets released and by whom
  • Document which policies are assigned to which anti-spam/phish rules

If you stick to these, you'll get fewer helpdesk tickets and better security. Quarantine isn't something you configure once and forget, though. It's an active part of your defense and needs regular review, especially as attack methods change. For more on governing anti-phish and spam settings, read my earlier post on what the Defender for Office 365 preset policies give you.