We value your privacy

We use cookies to analyse site traffic and improve your experience. You can accept all cookies or reject non-essential ones. See our Privacy Policy for details.

GR IT SERVICES
  • Contact
Get a quote
  2. Microsoft security
  3. Quarantine policies
Quarantine policies, UAE

Giving users full access does not let them release malware. That permission is simply not honoured.

It is the detail that resolves most quarantine arguments. Release is ignored for messages quarantined as malware by anti-malware or Safe Attachments policies, and for high confidence phishing. Quarantine policies decide everything else: who sees what, who can act, and who gets told.

Book a quarantine policy reviewSee the permission model
Defender for Office 365 quarantine policies for UAE organisations
  • 3 groupsNo access, limited access, full access
  • 3 defaultsBuilt-in policies you cannot remove or edit
  • 4 hoursFastest notification frequency available
  • Never releasedMalware and high confidence phishing, by users
What quarantine policies control

Eight decisions hiding behind one setting nobody configured.

Quarantine policy is assigned per protection feature and per verdict, which means a tenant can have eight different answers to what happens to a blocked message. Most organisations have never chosen any of them and are running whatever the defaults were.

Three preset permission groups

No access, limited access and full access. The distinction that matters most is between the last two: full access includes allowing recipients to release a message themselves, while limited access instead lets them request release, which routes to an administrator for approval.

Release that is never honoured

Even with full access, allowing recipients to release is not honoured for messages quarantined as malware by anti-malware policies or Safe Attachments policies, or as high confidence phishing by anti-spam policies. Those categories are administrator-only regardless of what your policy says.

Request release as the middle ground

Limited access is described as letting users do anything to their quarantined messages except release them without admin approval. For most organisations that is the right default: users triage their own mail, and a human decision sits in front of anything actually leaving quarantine.

Three built-in policies you cannot change

AdminOnlyAccessPolicy with no access and notifications off, DefaultFullAccessPolicy with full access and notifications off, and DefaultFullAccessWithNotificationPolicy with full access and notifications on. None can be removed, and their permissions and notification settings are read only.

Notifications, which are off in the strictest default

Quarantine notifications are disabled in AdminOnlyAccessPolicy. That is a deliberate design and it produces a common complaint: messages are quarantined correctly and nobody is told. Where notification matters, that requires a different policy rather than a different setting.

Notification frequency and what it really means

The options are within four hours, daily or weekly. Microsoft notes that at four hours, a message quarantined just after the last notification generation reaches the recipient slightly more than four hours later. So four hours is the cadence, not the maximum delay.

Retention, set in the anti-spam policy

How long quarantined messages are held is controlled by the retain spam in quarantine for this many days setting in anti-spam policies, and that retention period applies to messages quarantined by anti-spam and anti-phishing protection. It is a separate setting from the quarantine policy itself.

What new policies inherit if you say nothing

New anti-malware policies created without specifying a quarantine policy use AdminOnlyAccessPolicy, as do Safe Attachments policies for malware detections. Blocking unscannable encrypted attachments without specifying one uses DefaultFullAccessWithNotificationPolicy instead.

The answer to the recurring argument

A user cannot release malware or high confidence phishing, whatever permissions you grant.

Microsoft states this as a footnote to the permission table, and it settles most of the internal debate about how permissive quarantine should be.

  • Allow recipients to release a message from quarantine is not honoured for messages quarantined as malware by anti-malware policies or by Safe Attachments policies, or as high confidence phishing by anti-spam policies. Those verdicts remain administrator-only by design.
  • That changes the risk calculation on granting full access. The nightmare scenario people picture, a user releasing an actual malware sample into their mailbox, is not possible through the permission model. What full access actually permits is release of spam, bulk and lower confidence verdicts.
  • High confidence phishing is already quarantined with AdminOnlyAccessPolicy by default, so in most tenants that verdict is doubly locked: the assigned policy grants no access, and the release permission would not be honoured even if it did.
  • The practical consequence is that limited access is a defensible default for the verdicts where users can act, because it gives them triage and preview while routing any actual release through an administrator. Full access is then a deliberate choice for lower-risk verdicts rather than a blanket setting.
Ask us to map policies to verdicts
How we approach it

Four things that make quarantine work for both sides.

Quarantine configuration is a balance between administrator workload and users losing legitimate mail silently. Getting it wrong in either direction has a real cost, and the defaults sit at one extreme.

We configure per verdict rather than per tenant

Quarantine policy is assigned per protection feature and per verdict, which means malware, high confidence phishing, spam and bulk can each have a different answer. Applying one policy across all of them either over-restricts the harmless verdicts or over-permits the serious ones.

We default to request release rather than release

Limited access lets users do anything with their quarantined messages except release them without admin approval. For most organisations that is the right balance: users triage and preview, and a person makes the release decision. It also creates a queue somebody has to own, which we set up deliberately.

We check whether anybody is actually being told

Quarantine notifications are disabled in AdminOnlyAccessPolicy, and that is the policy applied by default to several verdicts. The result is correctly quarantined mail that nobody knows about. Whether that is right depends on the verdict, and it should be a decision rather than an inheritance.

We explain what the permission model cannot do

The concern that stalls these projects is a user releasing malware. That is not possible: release is not honoured for malware from anti-malware or Safe Attachments policies, or for high confidence phishing. Saying so with the documentation behind it usually unblocks the decision in one meeting.

How a review runs

Four phases across roughly three to four weeks.

Short, because quarantine policy is a configuration exercise rather than a deployment. The value is in deciding deliberately per verdict instead of inheriting whatever was created first.
  1. 01
    Week 1

    Establish what is assigned where

    Quarantine policy is assigned per protection feature and per verdict, so the first job is a matrix: which policy is currently in effect for spam, high confidence spam, phishing, high confidence phishing, bulk, malware, Safe Attachments detections and unscannable encrypted attachments.

    • Current quarantine policy per feature and verdict
    • Notification state per assignment
    • Retention period from the anti-spam policy
    • Preset security policy usage identified
  2. 02
    Week 2

    Decide the target position per verdict

    Not one answer for everything. Malware and high confidence phishing stay administrator-only because release would not be honoured anyway. Spam and bulk are candidates for limited or full access depending on how much administrator time release requests would consume.

    • Target permission group agreed per verdict
    • Release versus request release decision made
    • Notification requirement agreed per verdict
    • Custom policies designed where defaults do not fit
  3. 03
    Week 3

    Build custom policies and assign them

    The three default policies cannot be edited, so anything other than their exact combinations requires a custom policy. Assignment is per feature and per verdict, which is where the configuration work actually is.

    • Custom quarantine policies created
    • Assignment completed per feature and verdict
    • Notification frequency set with the four hour behaviour understood
    • Retention period confirmed as intended
  4. 04
    Week 4

    Brief people and set the operating rhythm

    Users told what they will see and what they can do with it, and administrators given a routine for handling release requests. A request queue nobody watches is worse than not offering the option, because it looks like a route and is not.

    • End user guidance issued
    • Release request handling routine agreed with an owner
    • Response time expectation set
    • Review point scheduled against false positive volume
Where this matters

Six situations where quarantine configuration is the problem.

The symptom is usually either lost mail nobody noticed, or an administrator spending an hour a day releasing messages that users could have handled.

A business losing legitimate mail silently

The classic symptom of AdminOnlyAccessPolicy with notifications off. Mail is quarantined correctly, nobody is told, and the problem surfaces when a customer asks why nobody responded to their enquiry. Turning on notification for the appropriate verdicts fixes it in an afternoon.

An IT team spending hours on release requests

The opposite failure. Every quarantined message becomes a ticket because users can neither preview nor act. Limited access gives them preview and delete and keeps release under approval, which removes most of the volume without changing the security position.

A regulated firm that must approve every release

Where policy requires a human decision on anything leaving quarantine, limited access with request release is the direct expression of that. The approval step is a control with a record, rather than a rule people are asked to follow.

A provider where a missed message has consequences

Referrals, results and appointment mail all arrive by email, and a silently quarantined message is a clinical risk rather than an inconvenience. Notification frequency at four hours for the appropriate verdicts, combined with preview, meaningfully shortens the time to notice.

An organisation using preset security policies

Preset security policies use DefaultFullAccessWithNotificationPolicy to enable quarantine notifications, rather than DefaultFullAccessPolicy where notifications are off. Knowing which of those is in play explains a lot of otherwise confusing behaviour when comparing tenants or user groups.

A business that lost mail to retention expiry

Retention is set by the retain spam in quarantine for this many days setting in the anti-spam policy, and it applies to anti-spam and anti-phishing quarantined mail. Where notification frequency is weekly and retention is short, mail can expire before anybody sees the notice about it.

Three positions

How UAE organisations handle quarantined mail.

The right column is common and it produces a specific failure: legitimate mail sits in quarantine, nobody is notified, and the sender eventually phones to ask why nobody replied.
Users can triage their own mail
Configured per verdictFor safe verdicts
One policy for everythingAll or nothing
Defaults, notifications offNo
Release requires approval where it should
Configured per verdictYes
One policy for everythingDepends
Defaults, notifications offNot offered
Malware release attempted
Configured per verdictNot possible
One policy for everythingNot possible
Defaults, notifications offNot possible
Users notified of quarantined mail
Configured per verdictWhere appropriate
One policy for everythingUniformly
Defaults, notifications offNo
Administrator workload from requests
Configured per verdictPredictable
One policy for everythingHigh or zero
Defaults, notifications offZero
False positives found quickly
Configured per verdictYes
One policy for everythingSometimes
Defaults, notifications offWhen somebody phones
Retention period chosen deliberately
Configured per verdictYes
One policy for everythingInherited
Defaults, notifications offInherited
Notification frequency chosen
Configured per verdictYes
One policy for everythingDefault
Defaults, notifications offNot applicable
Preset policy interaction understood
Configured per verdictYes
One policy for everythingNo
Defaults, notifications offNo
End user experience tested
Configured per verdictYes
One policy for everythingNo
Defaults, notifications offNo
Feature
Configured per verdict
One policy for everything
Defaults, notifications off
Users can triage their own mail
For safe verdictsAll or nothingNo
Release requires approval where it should
YesDependsNot offered
Malware release attempted
Not possibleNot possibleNot possible
Users notified of quarantined mail
Where appropriateUniformlyNo
Administrator workload from requests
PredictableHigh or zeroZero
False positives found quickly
YesSometimesWhen somebody phones
Retention period chosen deliberately
YesInheritedInherited
Notification frequency chosen
YesDefaultNot applicable
Preset policy interaction understood
YesNoNo
End user experience tested
YesNoNo
The permission model

What each preset group actually allows.

Taken from the published permission table. The two rows worth reading twice are the last two, because they are what separates limited access from full access.
PermissionNo accessLimited accessFull access
View message headerYesYesYes
Allow senderNoYesYes
Block senderNoNoNo
DeleteNoYesYes
PreviewNoYesYes
Release a message from quarantineNoNoYes
Request a message be releasedNoYesNo
AdminOnlyAccessPolicy usesThis groupNoNo
DefaultFullAccessPolicy usesNoNoThis group
Quarantine notifications enabledNo, in AdminOnlyAccessPolicyConfigurableDepends on the policy
How an engagement runs

Five steps, and the first is building a matrix nobody has.

Because assignment is per feature and per verdict, the current state is genuinely unknown in most tenants until somebody writes it down.
  1. 1

    Document the current assignment per verdict

    Which quarantine policy applies to spam, high confidence spam, phishing, high confidence phishing, bulk, malware, Safe Attachments detections and unscannable encrypted attachments, plus whether notifications are on for each and what retention is configured.

  2. 2

    Agree the target per verdict with the business

    Malware and high confidence phishing stay administrator-only, since release would not be honoured regardless. Spam and bulk are the real decision, and it turns on how much administrator time you want release requests to consume against how much user autonomy you want.

  3. 3

    Build custom policies where the defaults do not fit

    The three default policies cannot be removed and their permissions and notification settings are read only, so any other combination requires a custom policy. That is common, because full access with notifications and limited access with notifications are both frequently what an organisation wants.

  4. 4

    Assign, set frequency and confirm retention

    Assignment per feature and verdict, notification frequency chosen with the four hour cadence behaviour understood, and retention confirmed in the anti-spam policy so it is long enough for the notification frequency you selected.

  5. 5

    Brief users and give the request queue an owner

    End user guidance covering what they will see and what they can do, and an administrator routine for release requests with a stated response time. A request option nobody monitors is worse than not offering it, because users believe they have a route.

Straight answers

What organisations ask about quarantine policies.

No. Allow recipients to release a message from quarantine is not honoured for messages quarantined as malware by anti-malware policies or Safe Attachments policies, or as high confidence phishing by anti-spam policies. That permission simply does not apply to those verdicts regardless of the policy.

Release is in the full access group and lets the user release the message themselves. Request release is in the limited access group and routes the decision to an administrator. Microsoft describes limited access as letting users do anything except release without admin approval.

It depends on the feature and verdict. High confidence phishing is quarantined with AdminOnlyAccessPolicy by default. New anti-malware policies created without specifying a quarantine policy use AdminOnlyAccessPolicy, as do Safe Attachments policies for malware detections.

Most likely because the verdict is assigned AdminOnlyAccessPolicy, where quarantine notifications are disabled. That is by design rather than a fault. If you want recipients notified for a given verdict, that requires a policy with notifications turned on, which means a different or custom policy.

No. Permissions and notification settings in the default quarantine policies are read only and cannot be modified, and AdminOnlyAccessPolicy, DefaultFullAccessPolicy and DefaultFullAccessWithNotificationPolicy cannot be removed. Anything outside those exact combinations needs a custom policy.

You choose within four hours, daily or weekly. Note what four hours actually means: if a message is quarantined just after the last notification generation, the recipient receives the notification slightly more than four hours later. It is a cadence rather than a maximum delay.

Controlled by the retain spam in quarantine for this many days setting in your anti-spam policies, and that retention period applies to messages quarantined by anti-spam and anti-phishing protection. It is configured separately from the quarantine policy, which catches people out.

Not through the preset permission groups. Block sender is not included in no access, limited access or full access. Allow sender is included in limited and full access, which is the reverse of what people often assume when they first read the permission list.

Very little, and it depends on notifications. If notifications are turned on for no access permissions, users can view their messages in quarantine but the only available action is view message headers. Preview, delete and release are all unavailable.

Yes, and it is worth knowing. Preset security policies use DefaultFullAccessWithNotificationPolicy to enable quarantine notifications, rather than DefaultFullAccessPolicy where notifications are turned off. That explains a lot of apparent inconsistency when comparing tenants.

A default policy with full access and notifications enabled that Microsoft included selectively, so your organisation might not have it. If you do not, the equivalents are DefaultFullAccessWithNotificationPolicy or a custom policy with full access and notifications turned on.

If you block unscanned attachments in a Safe Attachments policy without specifying a quarantine policy for that case, DefaultFullAccessWithNotificationPolicy is used. That is a different default from malware detections in the same policy, which use AdminOnlyAccessPolicy.

In most engagements: administrator-only for malware and high confidence phishing since release is not honoured anyway, and limited access with notifications for spam and bulk so users can triage and preview while release stays under approval. Then adjust based on how much request volume that generates.

Preview is the answer more often than permissions are. Users request release because they cannot tell whether a message matters. Preview is included in both limited and full access, and enabling it with clear guidance typically reduces request volume more than widening permissions would.

We scope by tenant complexity and how many protection policies exist, since assignment is per feature and per verdict. The free first step: check which quarantine policy is assigned to spam and to high confidence phishing in your tenant. Most people find they have never chosen either.

No. Block sender appears in the permission list but is not included in the no access, limited access or full access preset groups. Allow sender is included in limited and full access, which is the opposite of what most people assume when they first read the permission table.

They are unrelated, and Microsoft notes this specifically. Preview is a permission included in limited and full access that lets a user look at a quarantined message. Review message is an action available in quarantine notifications. Enabling one does not imply the other.

Effectively no. Microsoft notes that turning the permission off in PowerShell does not affect the availability of the view message header action, and that if a message is visible to a user in quarantine, view message header is always available for it.

Because they inherit a different default. Safe Attachments policies created without specifying a quarantine policy use AdminOnlyAccessPolicy for malware detections, whereas blocking unscannable encrypted attachments without specifying one uses DefaultFullAccessWithNotificationPolicy. Two defaults in the same policy, which is easy to miss.

Rarely. Notification for spam and bulk helps users find legitimate mail that was caught. Notification for high confidence phishing and malware is usually unnecessary, since those messages will not be released by a user in any case and the notification only invites a request that cannot be granted.

Yes. Anti-phishing policies can quarantine messages detected by spoof intelligence, mailbox intelligence, targeted domain protection and targeted user protection, and a quarantine policy can be assigned to each of those detections separately rather than as one setting for the whole policy.

From a normal user account rather than an administrator one. The permissions, the available actions and whether a notification arrives all differ by assigned policy and by verdict, so the only reliable way to know the experience is to have somebody with ordinary permissions look at it.
Review questions

Fifteen questions about your own quarantine configuration.

Most organisations can answer none of the first group, which is the point. Quarantine policy is assigned per verdict and almost nobody has chosen those assignments deliberately.

Current state

  • Which policy applies to spam?
    Per verdict, not per tenant.
  • Which applies to high confidence phishing?
    AdminOnlyAccessPolicy by default.
  • Which applies to malware?
    AdminOnlyAccessPolicy if unspecified.
  • Which applies to Safe Attachments detections?
    Same default.
  • What is our quarantine retention period?
    Set in the anti-spam policy.

Permissions

  • Do users get release or request release?
    The key distinction.
  • Who approves release requests?
    Name them.
  • How quickly are requests handled?
    Set an expectation.
  • Do users know preview exists?
    It reduces requests.
  • Are we using preset security policies?
    They use a specific default.

Notifications

  • Are notifications on at all?
    Off in AdminOnlyAccessPolicy.
  • What frequency is configured?
    Four hours, daily or weekly.
  • Do users understand the delay?
    Slightly more than four hours.
  • Do notifications reach shared mailboxes?
    Check it.
  • Has anyone tested the end user view?
    From a normal account.
Related reading

The pages around this one.

Defender for Office 365

The protection product these policies belong to.

Learn more

Anti-phishing policies

The detection side of what ends up in quarantine.

Learn more

Email security audit

A full review of the mail protection configuration.

Learn more
Next step

Check which quarantine policy is assigned to spam, and which to high confidence phishing.

They are assigned separately, per verdict, and most organisations have never chosen either. Whatever you find is what your users experience every time something is blocked.

Book a quarantine policy reviewCall +971 56 613 2743

Related Services

Explore more solutions that work great with this service

Tenant Allow/Block List

Manual overrides that do more than you expect

Learn more

Threat Explorer

Answering who received it and who clicked

Learn more

Defender for Office 365

Plan 1 versus Plan 2, and the ten second way to tell which you have

Learn more

Anti-Phishing Policies

Impersonation protection, spoof handling and thresholds

Learn more

Email Security Audit

Authentication, policy, exceptions, routing, mailboxes

Learn more

Safe Links

Time-of-click URL checks in mail, Teams and Office

Learn more

DMARC Audit UAE

Stop exact-domain spoofing, and keep your mail delivering

Learn more

Microsoft 365 Security Audit

Tenant review, and how far back your evidence really goes

Learn more
GR IT SERVICES

Leading IT services provider in Dubai,
delivering enterprise-grade solutions
for businesses across the UAE.

Microsoft CSP PartnerCISGuard

Get the Helpdesk app

Raise and track IT tickets from your phone.

Download on the App StoreGet it on Google Play
Learn more about the app

Microsoft 365

  • Microsoft 365 Administration
  • M365 Reporting & Auditing
  • Microsoft 365 Licensing
  • Microsoft Copilot
  • Microsoft 365 Apps
  • Windows 365 Cloud PC
  • Microsoft SharePoint
  • Outlook & Exchange

Security

  • Microsoft Defender
  • Microsoft Purview
  • Microsoft Intune
  • Microsoft Entra
  • Compliance Manager
  • Cybersecurity Audits
  • Copilot for Security
  • Microsoft Sentinel
  • Microsoft Priva

Infrastructure

  • Google Workspace
  • Cloud Migration Services
  • Data Analytics & BI
  • Active Directory
  • Server Management
  • Apple Business
  • Apple Jamf Pro
  • IP Telephone
  • Data Backup
  • Website Development

IT Services

  • Managed IT Services
  • IT Support Dubai
  • IT AMC Dubai
  • New Office IT Setup
  • IT Relocation
  • Remote IT Support
  • On-Call IT Support
  • Startup IT Business Kit
  • Disaster Recovery & BC

Company

  • About Us
  • Careers
  • Contact
  • Blog

Contact

  • Iris Bay Tower, Office 903,
    Business Bay, Dubai, UAE
  • +971 56 613 2743
  • hello@gritservices.ae
  • gritservices.ae

© 2026 GR IT Services. All rights reserved.

Privacy PolicyTerms of UseCookie Policy