Handle a Microsoft 365 quarantine review or release request — the vendor specialization of
quarantine-release-request. The release logic (verify the requester, respect the verdict
class, never touch the payload, when in doubt don't release) lives in the generic skill; you
add where things are in the Microsoft portal and what the Defender verdict and policy
machinery mean. You have no portal access — the technician performs the portal action, you
recommend and record. Use plain-text notes, no markdown or emojis, for anything syncing to
a PSA.
1. Run quarantine-release-request first. All of its guardrails apply, malware verdicts
included. Everything below is the Defender layer.
2. Locate the item: security.microsoft.com → Email & collaboration → Review → Quarantine.
Match on recipient, subject and received time. Default retention is limited (30 days for
most verdicts), so note the expiry before a legitimate release is lost. Expiry is not a verdict — an expired item is gone, not exonerated.
3. Read the Defender quarantine reason as the scrutiny floor:
- High-confidence phishing or malware → never recommend release; get the content through a
verified channel with the real sender instead. Users cannot self-release these by
default, so a request for one arriving "from the user" deserves extra requester scrutiny.
- Phishing that isn't high-confidence → run phishing-triage; release only on a clear
false-positive outcome.
- Spam, bulk, or a transport-rule or policy hold → a known legitimate sender plus expected
business context supports release.
- Spoof or authentication failure (SPF, DKIM, DMARC) → check whether the "legitimate"
sender genuinely fails authentication, and route recurring cases to
dmarc-spf-failure-triage on the sender's side or to the client's tolerance policy. Never
release a spoof verdict because the display name looks familiar.
4. Separate the two release flows: a user-requested release sits in the portal awaiting admin
approval (approve or deny is the technician's portal action), versus an admin-initiated
release. Release to the specific requesting recipient, not to all recipients, unless every
recipient's need is verified. Watch the quarantine-policy context: if users can self-release
a verdict class, an admin-release request for that class is odd — ask why before acting.
5. Send recurring false positives to security-noise-tuning: the narrowest fix (a Tenant
Allow/Block List entry for the sender or domain, or a transport-rule adjustment) with a
named approver and a review date, never a blanket allow. Release and allow are different
decisions — releasing one message does not require allowlisting the sender.
6. Document per the generic skill: requester verification, quarantine reason, evidence,
verdict, and who released what and when.
Magic Library