Message quarantine in Microsoft 365: what an SME should and should not release

What message quarantine is and is not

Quarantine is not the Junk Email folder in Outlook and not Deleted Items. It is separate storage in Microsoft 365 where messages land when filters mark them as spam, phishing, malware, or a policy block — depending on your policies and licences. Users do not see that mail in the inbox by default; someone with the right permissions (or a quarantine notification, if you allow them) must act deliberately: release, delete, or leave until retention expires.

It is also not a substitute for email authentication. SPF, DKIM and DMARC help decide whether a sending domain checks out; quarantine catches what still looks risky after or beside that. See SPF, DKIM and DMARC for SME email: those records and policies belong with quarantine, not as either/or.

Who may release — and who should not

Three patterns show up in SMEs. Everyone gets quarantine notifications and clicks Release because “it looks like an invoice” — that is the risk: one convincing phish is then delivered anyway. Only the director has rights but is never available — then “missing mail” complaints pile up with no process. Or only the MSP may release, but nobody agreed when the customer may decide about a known vendor.

The practical line: limit quarantine rights to a small group (IT contact, a director’s decision, or Floor ICT); give ordinary users at most a notification with “do not release if unsure”; and tie release to named users with MFA — not a shared admin password. See also admin accounts.

False positive versus real threat

False positive: a known vendor, the right domain, content that matches an open order — but the filter was too strict (new domain, attachment type, bulk behaviour). Release can be right, ideally after a quick check of sender and link.

Real threat: unknown sender, urgency (“pay now”, “your mailbox will close”), an unexpected attachment or link, or a lookalike domain. Then “do not release” is the default; escalate to your MSP or security contact. Releasing malware or credential phishing undercuts MFA and training — see security awareness.

Unsure = do not release. Ask Floor ICT or the process owner; note what you did.

What you decide in writing

Keep it short enough to decide this quarter:

• who may view quarantine and release messages (names or role — not “anyone with Outlook”);
• whether end users get quarantine notifications, and the instruction when unsure;
• when you escalate to Floor ICT (attachment, unknown sender, VIP target, repeated phishing);
• that release is an incident-like choice: note date, who, which message (subject/sender), and why;
• review cadence: periodically check whether too many false positives mean policy is too strict or too loose;
• link to mail authentication: SPF/DKIM/DMARC and Defender policies belong in the same mail hygiene.

Write those points on one page. That is your quarantine agreement; the tenant follows that text.

What Floor ICT configures — and what you decide

In the Microsoft 365 tenant we typically set: anti-spam and anti-phishing policies that match your licence; quarantine tags and notifications per your choice; permissions for who may manage quarantine; and a workflow for “unsure → ticket to Floor ICT” instead of random releases. We help analyse false positives (filter too strict versus real threat) and tie this to SPF/DKIM/DMARC and MFA.

You still decide: who in your organisation may release; whether a specific vendor is “always OK” after review; and how strict you want filtering versus how often you accept false positives. Technical toggles without that agreement are false comfort; policy without working quarantine is not enough either.