Two Variables and a Trap: Quarantine Policies in Defender for Office 365

There is a particular ticket that every MSP engineer has closed more times than they can count. A user swears a message never arrived. The sender swears they sent it. Message trace shows the thing was delivered to the tenant, evaluated, and quarantined — and the user was never told. Nobody is wrong, nothing is broken, and the fix is a dropdown two clicks deep in a policy nobody has opened in three years.

Quarantine policies are the part of Defender for Office 365 that decides what a user is allowed to do with their own quarantined mail, and whether they even find out it exists. Most tenants are running the defaults. The defaults are defensible, but one of them is a quiet ticket generator, and it is worth understanding exactly why before you touch anything.

The whole system is two variables

This is the part that makes quarantine policies click. Strip away the naming and there are only two settings that matter:

1. Permission group — No access, Limited access, or Full access. This decides what actions the user gets.
2. Quarantine notifications — on or off. This decides whether they ever learn there is something to act on.

Every built-in policy is a combination of those two. Three built-ins, three combinations. That’s the entire surface area, plus one override that ignores both — which we’ll get to, because it’s the thing that catches people.

The decision map

Read this top to bottom. The important thing to notice is that the quarantine policy is chosen per verdict, not per message — so a single anti-spam policy can route spam to one experience and high confidence phishing to a completely different one.

The middle column is the problem

Look at DefaultFullAccessPolicy again. Full access — the user can release, preview, delete, allow the sender, everything. And notifications off.

That combination is the worst of both worlds. You have handed the user a capability and given them no way to discover it. The message is genuinely sitting there at security.microsoft.com/quarantine, releasable by them, requiring zero admin involvement — and they will never go look, because nothing told them to. So the false positive becomes a phone call, the phone call becomes a ticket, and you spend eight minutes releasing a newsletter that the recipient was already fully authorized to release themselves.

One caveat worth stating plainly, because it changes how urgent this is in a given tenant: in the default anti-spam policy, spam, high confidence spam, and bulk are set to Move to Junk, not Quarantine. The quarantine policy bound to a verdict only matters once that verdict actually quarantines. So the silent-quarantine problem shows up in tenants where someone has already turned those actions up — or where a Standard or Strict preset is doing it for them. Check the action before you go hunting for the policy.

The override that ignores your permissions

This is the detail I most often see people get wrong, including in tenants set up by engineers who clearly knew what they were doing.

Regardless of which quarantine policy you bind, a user can never directly release a message quarantined as malware by an anti-malware policy, as malware or phishing by a Safe Attachments policy, or as high confidence phishing by an anti-spam policy. This is part of secure-by-default and it is not negotiable through the quarantine policy.

What actually happens is subtler than a flat block. If the bound policy grants Release, the user doesn’t get an error — the button quietly becomes Request release, and the request lands in the admin approval queue instead. The permission didn’t fail, it degraded.

The practical consequence: binding DefaultFullAccessPolicy to high confidence phishing does not give your users a release button. It only makes the message visible to them. If your intent was “let users see what got caught,” that works. If your intent was “let users handle their own false positives,” it does not, and you’ve traded silence for a stream of release requests.

The clock nobody mentions

Everything above is about visibility. There is a second variable running underneath it that isn’t part of the quarantine policy at all, and it’s the one that turns a silent quarantine from an annoyance into data loss: retention.

Look at the top row against the bottom five. Anti-spam has the shortest retention in the entire product — and anti-spam is where essentially every false positive lands. Malware, which nobody wants back, is kept for a month. The legitimate invoice misfiled as bulk gets two weeks.

Now stack that on DefaultFullAccessPolicy. The user was allowed to release the message the whole time, was never told it existed, and on day 15 it is permanently deleted and unrecoverable. Every part of that is working as designed.

One wrinkle worth knowing: anti-phishing retention has no setting of its own. It’s governed by the QuarantineRetentionPeriod of the first matching anti-spam policy for that recipient. So if you shorten anti-spam retention, you silently shorten spoof and impersonation retention along with it.

This is also the least-discussed argument for the Standard and Strict presets. They don’t just switch you to the notifying policy — they double anti-spam retention to 30 days at the same time. Notifications and a longer clock, together, from one change.

Two tells for a custom policy

When you inherit a tenant and want to know fast whether someone has been in here, there are two giveaways in the permission grid above:

• Request release appears anywhere. It only exists in the Limited access group, and Limited access has no built-in policy. Somebody built that.
• Block sender is granted. It sits in none of the three preset groups — it can only be switched on individually under Set specific access (Advanced). Same conclusion.

Neither is a problem in itself. Both mean the configuration was deliberate, and you should find out what the deliberation was before you undo it.

Where to change it

The portal path, for anti-spam:

1. Email & collaboration → Policies & rules → Threat policies → Anti-spam (security.microsoft.com/antispam)
2. Open the policy that actually applies — usually Anti-spam inbound policy (Default) unless a custom or preset policy wins the ordering.
3. Under Actions, choose Edit actions.
4. For each verdict, set the action to Quarantine message, then set Select quarantine policy. The dropdown only appears when the action is Quarantine.
5. Save. Same pattern in Anti-phishing (/antiphishing), Anti-malware (/antimalwarev2, under Protection settings), and Safe Attachments (/safeattachmentv2).

Two things that will bite you here.

First, check for a preset security policy before you change anything. When a recipient is covered by more than one policy, the order of application is fixed:

1. Strict preset security policy
2. Standard preset security policy
3. Defender for Office 365 evaluation policies
4. Custom threat policies, by priority (lower number wins)
5. Built-in protection, and the default anti-spam / anti-malware / anti-phishing policies

Processing stops at the first match. So if a Standard preset covers those users, editing the default anti-spam policy accomplishes exactly nothing for them — and preset quarantine policy assignments can’t be edited, so your only move is to scope the users out of the preset first.

Second, Exchange mail flow rules with a Quarantine action don’t support quarantine policies at all — and messages they quarantine are admin-only by default, invisible to the recipient. That’s the same practical outcome as AdminOnlyAccessPolicy, except there’s no dropdown and nothing to change. If you route anything to quarantine with a transport rule, nobody but you is ever going to see it.

Auditing it in PowerShell

The portal shows you one policy at a time, which is the slow way to answer “what is this tenant actually doing.” Connect with Connect-ExchangeOnline first, then:

# What's bound right now, across every anti-spam policy
Get-HostedContentFilterPolicy | Format-List Name,`
  SpamAction,SpamQuarantineTag,`
  HighConfidenceSpamAction,HighConfidenceSpamQuarantineTag,`
  PhishSpamAction,PhishQuarantineTag,`
  HighConfidencePhishAction,HighConfidencePhishQuarantineTag,`
  BulkSpamAction,BulkQuarantineTag

Read the *Action and *QuarantineTag values as pairs — the tag is meaningless unless the action next to it is Quarantine.

To move the three verdicts that benefit most onto the notifying policy:

Set-HostedContentFilterPolicy -Identity "Default" `
  -SpamAction Quarantine               -SpamQuarantineTag DefaultFullAccessWithNotificationPolicy `
  -HighConfidenceSpamAction Quarantine -HighConfidenceSpamQuarantineTag DefaultFullAccessWithNotificationPolicy `
  -BulkSpamAction Quarantine           -BulkQuarantineTag DefaultFullAccessWithNotificationPolicy

And to see every policy in the tenant, built-in and custom, with its permission value and notification state:

Get-QuarantinePolicy | Format-Table Name,EndUserQuarantinePermissionsValue,ESNEnabled

# Tenant-wide notification settings live on a separate object named DefaultGlobalTag
Get-QuarantinePolicy -QuarantinePolicyType GlobalQuarantinePolicy | Format-List

EndUserQuarantinePermissionsValue is a decimal encoding of the permission bits in the table above — add them up and you can read any policy without opening it. 0 is No access, 43 is Limited access. Any other value is a custom policy, and worth a look. Read Full access off the tenant rather than trusting a number from a blog post, this one included.

Anti-spam is only one of four places these get bound. The others:

Set-AntiPhishPolicy      # -SpoofQuarantineTag, -TargetedUserQuarantineTag,
                         # -TargetedDomainQuarantineTag, -MailboxIntelligenceQuarantineTag
Set-MalwareFilterPolicy  # -QuarantineTag
Set-SafeAttachmentPolicy # -QuarantineTag, -QuarantineTagForBlockingEncryptedAttachments

That last parameter is worth knowing about. Safe Attachments quarantines password-protected attachments it can’t scan under their own Password protected item reason, with their own quarantine policy binding. Admins can release those without the password; a user can supply the password to have their own message rescanned, but only if the bound policy lets them.

Two traps in this area. The anti-malware cmdlets are not New-AntiMalwarePolicy / Set-AntiMalwarePolicy — those don’t exist in Exchange Online, despite appearing in at least one Learn syntax block. The real ones are New-MalwareFilterPolicy / Set-MalwareFilterPolicy / Get-MalwareFilterPolicy. And when building a custom policy, never set PermissionToRelease and PermissionToRequestRelease both true — Microsoft’s guidance is one or neither, and setting both produces undefined behavior rather than a helpful error.

Finally, keep a bulk-release one-liner in your runbook. The portal’s bulk release dialog has a habit of failing at exactly the scale you need it — a big false-positive event — and PowerShell doesn’t:

Get-QuarantineMessage -PageSize 1000 |
  Where-Object { $_.SenderAddress -like "*@example.com" } |
  Release-QuarantineMessage -ReleaseToAll

One naming quirk that trips people up: the cmdlet parameters are still -*QuarantineTag. “Quarantine tag” was the pre-2021 name for what the portal now calls a quarantine policy. Same object, older label, never renamed.

Before you turn on notifications

Enabling digests is the right call, but it is a change your users will see, and a few things about it aren’t in the documentation.

Tell people it’s coming. A previously unseen Microsoft-branded email, arriving on a schedule, listing suspicious messages, with Release buttons in it, is an extremely good description of a phishing email. Send the heads-up before you flip the switch, not after the first user reports the digest as phishing.

Frequency and language are tenant-wide, under Quarantine policies → Global settings, not per-policy. You can’t give executives an hourly digest and everyone else a weekly one through the built-ins. Learn documents every four hours, daily, and weekly; an hourly option has been reported to have shipped without the docs being updated, so check what the dropdown actually offers in the tenant in front of you before promising a client anything.

If notifications look broken, check the blocked-sender option first. IncludeMessagesFromBlockedSenderAddress defaults to $false, which suppresses digest entries for messages caught from senders the user already blocked. That’s usually correct behavior being mistaken for a fault.

Two more from the field, both credited to Andres Bohren’s write-up rather than Microsoft: the custom logo in notification emails has been observed failing to render even when configured correctly, so test it to a real mailbox before you promise branding — the custom sender display name works fine. And the multi-language translation fields are all-or-nothing: populate all three MultiLanguage parameters together, because empty strings get rejected.

The digest sender address observed in production is [email protected]. That’s an observation, not a documented contract — useful for telling a user “yes, that one’s real,” but don’t hardcode it into a transport rule.

The takeaway

Quarantine policies are a small surface with an outsized effect on ticket volume. Two variables, three built-ins, one override, and a fifteen-day clock running underneath all of it.

If you do nothing else after reading this, go look at which policy is bound to your quarantined spam and bulk verdicts. If it’s DefaultFullAccessPolicy, your users have been able to fix their own false positives this whole time, nobody ever told them, and whatever they didn’t rescue two weeks ago is already gone.

Verified against Microsoft Learn, August 2026: Quarantine policies · Quarantined email messages · Quarantine notifications · Recommended settings for EOP and Defender for Office 365 · Preset security policies · Set-QuarantinePolicy

Field observations that are not in Microsoft’s documentation — the custom logo rendering failure, the all-or-nothing translation parameters, and the digest sender address — come from Andres Bohren’s write-up on Exchange Online quarantine policies and Nicolas Blank on quarantine confusion. Treat them as reliable by observation, not as contract.