Verdict-based access, review, release, submissions, expiration, and audit
Run quarantine as a controlled security queue—not a hidden mailbox. Match user and administrator capabilities to the reason a message was quarantined, inspect evidence without increasing exposure, govern release and request-release decisions, connect false positives to submissions and sender remediation, monitor expiration, and preserve an auditable record of every action.
Operating objective
Quarantine contains potentially unwanted or dangerous messages and files. What a recipient can see or do depends on the protection feature, verdict, and assigned quarantine policy. Microsoft’s default behavior keeps high-confidence phishing, malware, Safe Attachments malware/phishing, and messages quarantined directly by mail-flow rules under administrator control. Custom quarantine policies can make supported user capabilities more or less restrictive, but they cannot grant self-release for certain high-risk categories.
Operations must begin with the quarantine reason and policy type, not only the sender or subject. Bulk, spam, high-confidence spam, phishing, high-confidence phishing, spoof/impersonation, malware, Safe Attachments, and transport-rule quarantine carry different risk and permission expectations. The mapped quarantine policy determines whether users can preview, delete, release, request release, block a sender, or receive notifications.
Quarantine is time-limited, not an archive. Anti-spam policy settings control relevant retention, and Microsoft documents 30 days as the maximum quarantine retention. Expired items are permanently deleted and unrecoverable. Review queues and business-critical requests must therefore be prioritized before the expiration deadline.
Control statement: Every release or denial should identify the item, recipients, quarantine reason, policy type, sender/authentication evidence, reviewer, decision, scope, submission status, release validation, and expiration deadline. High-risk content must remain admin-controlled.
Permission architecture
Appropriate for lower-risk categories such as wanted bulk or ordinary spam when the quarantine policy permits it. Users should understand sender/context checks, reporting, release consequences, and how to escalate uncertainty.
Use for messages users may inspect but should not independently release. The request must reach a staffed reviewer queue with an SLA, expiration awareness, evidence requirements, denial reason, and escalation path.
Keep malware, high-confidence phishing, Safe Attachments malware/phishing, and other high-risk or rule-governed items restricted. Use least-privileged roles, isolated analysis, dual review where warranted, and no end-user preview.
Recommended boundary: Microsoft’s quarantine guidance recommends AdminOnlyPolicy for malware and high-confidence phishing, limited request-release access for regular-confidence phishing, and carefully governed user access for bulk and spam.
Verdict and action matrix
| Reason / source | Default user boundary | Reviewer checks | Permitted outcome | Evidence to retain |
|---|---|---|---|---|
| Bulk / spam | Users commonly can view, release and delete under historical default policies; custom policy may restrict. | BCL/SCL, business relationship, sender history, unsubscribe quality, authentication, cohort preference and campaign pattern. | Release selected recipients, report/submit, delete, block, or retain until expiry according to policy. | Quarantine details, headers, recipient scope, user/admin action, release/submission result and recurring-sender decision. |
| High-confidence spam | May be user-manageable under defaults, but organizations often apply stricter release governance. | SCL 9, TABL/block source, sender reputation, content pattern, authentication, other recipients and campaign evidence. | Admin confirm/release and submit when legitimate; deny/delete when malicious or unwanted. | Classification, policy hit, release authority, Microsoft result and exception expiration. |
| Phishing / spoof / impersonation | Regular phishing and spoof/impersonation capabilities depend on assigned quarantine policy. | Composite authentication, SPF/DKIM/DMARC, lookalike/impersonation target, URLs, reply-to, display name, relationship and campaign. | Request release or admin release only after evidence; submit false positive/negative; remediate sender or block threat. | Headers, URL/entity evidence, submission ID, reviewer decision, release verification and follow-up. |
| High-confidence phishing | Users cannot self-release regardless of custom quarantine policy; request release may be presented where configured. | Full threat investigation, campaign/incident context, credential lure, URLs/files, authentication and recipient blast radius. | Admin-only denial/delete or exceptional evidence-backed release with submission and validation. | Security approval, investigation, submission, selected recipients, post-release monitoring and incident linkage. |
| Malware / Safe Attachments malware or phishing | Admin-only; users cannot release these items. | Attachment/file verdict, hashes, detonations or entity evidence where licensed, related messages, endpoint/identity indicators and campaign. | Do not release without exceptional validated false-positive procedure; submit and use isolated analysis. | File/message identifiers, analysis location, chain of custody, submission, decision and incident/remediation record. |
| Mail-flow rule quarantine | Admin-only by default; direct rule quarantine isn't visible to users. | Rule name, conditions/exceptions, business purpose, sender/recipient context, headers and whether the rule still matches design. | Release or deny under rule-owner approval; correct the transport rule through change control if behavior is wrong. | Rule/version, match evidence, ticket, owner approval, release result and rule-change link. |
| Post-delivery or ZAP-related item | Capability depends on protection feature and reason. | Original delivery, later verdict change, user interaction, related campaign, mailbox/endpoint impact and remediation status. | Coordinate quarantine decision with incident investigation; do not treat release as an isolated mail-delivery task. | Timeline, alert/incident, original and updated verdict, remediation, reviewer and closure. |
Twelve-step operations runbook
Record the tenant, portal, reviewer identity/role, ticket, user or admin request, and whether the item affects one recipient, a group/shared mailbox, many recipients, or an active incident.
Use filters for time, sender, recipient, quarantine reason, policy type, release status and expiry. Search boxes may operate on the current view; use full filters rather than assuming a subject search covers all items.
Determine bulk/spam self-service, request-release, or admin-only handling from the actual reason and quarantine policy. Stop if the reviewer lacks the required role or malware isolation procedure.
Capture message ID, timestamps, sender, recipients, policy/reason, expiry, release state and relevant details before changing anything. Minimize subject/body/PII in tickets and screenshots.
Review headers, authentication, sender/recipient relationship, URLs and attachment metadata. Do not click live links, open attachments on a normal endpoint, forward the message, or expose hidden content to an untrusted viewer.
Check message trace, Explorer/Real-time detections where licensed, submissions, TABL, policies, similar recipients, alerts, campaigns, sign-ins and endpoint telemetry. A single clean-looking message is not proof.
For multi-recipient messages, decide exactly who should receive a release. Confirm shared mailbox and group behavior; avoid releasing to everyone when only one recipient has a valid business need.
For false positives or missed threats, use admin submissions and record the tracking result. Create only narrow temporary allow/block entries and assign sender authentication or application remediation to an owner.
Apply the correct action with reason, reviewer and approval. Treat release as a security decision; treat delete as potentially irreversible; preserve required evidence before expiration or deletion.
Confirm release status and selected-recipient delivery, check Junk/Inbox behavior, obtain user confirmation when appropriate, watch for URL/attachment blocking, and verify no new campaign or incident signal emerged.
Update anti-spam/phishing, quarantine, transport, Safe Links/Attachments, sender authentication, vendor or user guidance through their own controlled change process. Do not normalize recurring manual release.
Confirm the action appears in audit evidence, close the ticket, protect evidence, record time-to-review/release and decision quality, and schedule follow-up for exceptions, policy changes, repeat senders and reviewer coverage.
Safe review, release, and notification design
Prefer metadata, headers and protected preview. Download only when required for approved analysis, with least privilege, an isolated environment, file-handling procedure, encryption, limited retention and chain of custody. Never use a routine workstation.
User release is appropriate only where verdict and policy allow it. Request release needs a monitored queue, reviewer schedule, SLA, expiry prioritization, denial message and audit trail. High-risk categories remain admin-controlled.
Actions in notifications reflect quarantine-policy permissions. Global notification settings can use four-hour, daily or weekly frequency. Balance urgency and fatigue, protect branded sender trust, and test links and mobile behavior.
Microsoft supports quarantine notifications for shared mailboxes only for users with Full Access. Document who receives and reviews notices, how multiple delegates avoid duplicate/conflicting actions, and who confirms delivery.
Distribution and mail-enabled security group notifications can reach all group members. Microsoft 365 Group notification behavior also depends on whether group conversations/events are copied to members. Test before assuming an owner sees the item.
Surface the expiry date in triage views and prioritize business-critical/requested items. Quarantine is not backup or legal preservation; expired messages are unrecoverable. Export only the minimum evidence allowed by policy.
Top quarantine operations risks and misconfigurations
A reviewer releases by sender/subject without noticing high-confidence phishing, malware, Safe Attachments, or rule-based containment.
A permissive quarantine policy lets users release phishing-like content without request-and-review safeguards.
Malware, HPHISH, rule items and release requests expire because no least-privileged reviewer owns the queue.
Reviewers click live links, open attachments, enable content, or download to unmanaged endpoints.
A message is released to every original recipient when only one recipient has validated need—or the required recipient is omitted.
A false positive is repeatedly released but never submitted or remediated, creating permanent manual work and future expiry risk.
A broad TABL or policy exception outlives the incident and weakens protection for spoofed or compromised sender infrastructure.
Users ignore noisy notices or trust notification links without validation, while critical request-release messages lack prioritization.
Multiple delegates act inconsistently, or nobody receives the relevant notification due to mailbox/group configuration.
Teams expect expired items to be recoverable or use quarantine instead of backup, eDiscovery, retention, or incident evidence preservation.
Evidence and cadence
Review high-risk/admin-only items, release requests, imminent expiry, incidents and business-critical escalations.
Analyze release/denial quality, repeat senders, notification issues, shared/group workflows, submissions and exceptions.
Reconcile quarantine policies, notification settings, reviewer roles, audit coverage, SLAs, retention and metrics.
Test the full workflow, reviewer isolation, group/shared cases, high-risk escalation, policy mappings and failback.
Authoritative resources and related guidance
Frequently asked questions
No. Microsoft states that users cannot self-release high-confidence phishing, anti-malware malware, or Safe Attachments malware/phishing regardless of quarantine-policy configuration. A configured user action may become a request for administrator release.
Retention depends on the protection source and relevant policy; Microsoft documents 30 days as the maximum and anti-spam retention as configurable. The exact expiry is shown on the item. Expired messages are permanently deleted and unrecoverable.
Microsoft documents that user and administrator actions on quarantined messages are audited. Operations should also retain the ticket, reviewer, reason, submission, selected recipients and post-release validation.
Only when necessary and authorized. Prefer metadata, headers and protected preview. Downloads require appropriate permissions, isolated analysis, malware/file-handling controls, minimum retention and chain of custody.
Microsoft supports them for users with Full Access to the shared mailbox. Document the responsible delegates and test that notification, request/release and duplicate-action handling work as intended.
Confirm delivery to the intended recipients, submit the false positive, review any temporary allow, remediate sender authentication or policy root cause, watch for repeat classification, and close with audit evidence.
Recover legitimate mail without weakening containment
IT Perfection helps Orange County and Southern California organizations design verdict-based quarantine permissions, staff review and request-release queues, configure notifications, protect reviewers, integrate submissions and sender remediation, reduce repeat false positives, and preserve evidence for Microsoft 365 operations and security.
Created by Ali Hassani, CISO — 25+ years of IT, cybersecurity, compliance, and infrastructure experience. This guide is for initial guidance only and does not replace a professional cybersecurity audit, compliance assessment, penetration test, incident investigation, malware analysis, legal/compliance review, eDiscovery/retention decision, or tested mail recovery plan.
