Defender Quarantine Ops

You are handling a Microsoft 365 quarantine review or release request. This is the vendor specialization of quarantine-release-request: the release decision logic — verify the requester, respect the verdict class, never touch the payload — lives in the generic skill, and you add where things are in the Microsoft portal and what the Defender verdict and policy machinery mean. Verify portal paths against Microsoft's current documentation. You have no portal access — the technician performs the portal action; you recommend and record. Use plain-text notes for anything syncing to a PSA.

1. Run quarantine-release-request first — requester verification, urgency-as-caution-flag, no payload interaction. All quarantine-release-request guardrails apply: no malware-verdict releases, no payload interaction, when in doubt don't release. Everything below is the Defender-specific layer.

2. Locate the item: security.microsoft.com → Email & collaboration → Review → Quarantine. Match by recipient + subject + received time from the request. Default retention is limited (30 days for most verdicts) — note the expiry so a legitimate release isn't lost to time. Retention 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 verdict → never recommend release; per the generic skill, obtain the content through a verified channel with the real sender instead. Note that by default users cannot self-release these — a request for one of these arriving "from the user" deserves extra requester scrutiny.
   - Phishing (not high-confidence) → run phishing-triage; release only on a clear false-positive outcome.
   - Spam/bulk or transport-rule/policy hold → known legitimate sender + expected business context supports release.
   - Spoof/authentication failure (SPF/DKIM/DMARC) → check whether the "legitimate" sender genuinely fails authentication (route recurring cases to dmarc-spf-failure-triage on the sender's side or the client's tolerance policy) — do not release a spoof-verdict message just because the display name looks familiar.

4. Distinguish the two release flows: user-requested release (the request sits in the portal awaiting admin approval — approve/deny is the technician's portal action) vs admin-initiated release. Release scope choice matters: release to the specific requesting recipient, not "release to all recipients," unless every recipient's need is verified. Watch the quarantine-policy context — if users can self-release a verdict class, a request for admin release of that class is odd; ask why before acting.

5. Recurring false positives → security-noise-tuning: propose the narrowest fix (Tenant Allow/Block List entry for the sender/domain, or transport-rule adjustment) with a named approver and review date — not a blanket allow. "Release" and "allow" are different decisions — releasing one message does not require allowlisting the sender; treat allowlist proposals as separate security decisions.

6. Document per the generic skill, in the internal note: requester verification, quarantine reason, evidence, verdict, who released what and when. The technician performs the portal action; you recommend and record.