When a legitimate message lands in quarantine, the fastest fix is rarely the safest. A mail flow rule that bypasses filtering for a whole domain closes today's ticket and quietly opens a path for tomorrow's phishing. In this post I'll walk through finding the message, reading why it was caught, releasing it, and reporting it so Microsoft's filters and a time-limited allow entry handle the next one.
Prerequisites#
- Permissions. Acting on other users' quarantined mail needs the Quarantine Administrator, Security Administrator or Organization Management role group under Email & collaboration permissions (or the matching Defender XDR unified RBAC permission). Submitting messages to Microsoft needs Security Administrator.
- Just-in-time roles. Roles activated through Privileged Identity Management currently aren't supported in quarantine, so plan for that if your admins elevate on demand.
- Time. Quarantined messages are deleted when they expire and can't be recovered, so don't leave false positives waiting.
Step 1: Find the message#
In the Microsoft Defender portal, go to Email & collaboration › Review › Quarantine and stay on the Email tab. Use Filter rather than the search box: search only looks at entries already loaded on the page, while filters query everything. Useful filters are Recipient address, Sender address, Time received (the default is the last 7 days) and Message ID, which needs the full value including the angle brackets.
Step 2: Read why it was quarantined#
Select the message to open its details. Quarantine reason, Policy type and Policy name tell you most of the story:
| Quarantine reason | What it usually means |
|---|---|
| Spam, Bulk | Anti-spam verdict; by default users can release these themselves |
| Phishing | Anti-spam phishing verdict, or anti-phishing spoof or impersonation protection |
| High confidence phishing, Malware | Admin-only by default; users can at most request release |
| Transport rule | One of your own mail flow rules quarantined it, so fix the rule rather than the filter |
Next, select More › View message headers and paste the header into the Message Header Analyzer linked from the flyout. These fields matter most:
| Field | What to look for |
|---|---|
CAT in X-Forefront-Antispam-Report | The policy category that acted: SPM spam, HSPM high confidence spam, BULK, PHSH phishing, HPHSH or HPHISH high confidence phishing, SPOOF, UIMP/DIMP user or domain impersonation, MALW malware |
SFV in the same header | SPM means spam filtering marked it; SKN means a mail flow rule bypassed filtering; SFE means the recipient's Safe Senders list let it through |
SCL in the same header | Spam confidence level. In cloud mailboxes it doesn't decide the verdict or action, so rely on CAT and DIR instead |
BCL in X-Microsoft-Antispam | Bulk complaint level; higher means more likely to draw complaints |
Authentication-Results | SPF, DKIM, DMARC and compauth; a compauth=fail often sits behind a SPOOF verdict |
If authentication fails for a sender you trust, the lasting fix is on their side (SPF, DKIM, DMARC), so tell them.
Step 3: Release the message, or approve the request#
Select the message and choose Release. In the flyout you can send a copy to other recipients and select Submit the message to Microsoft to improve detection (false positive). That reveals Allow this message, which adds Tenant Allow/Block List entries for the sender and any related URLs or attachments. Remove entry after defaults to 45 days after last used date; you can also pick 1, 7 or 30 days or a specific date.
- Release re-delivers the message, so Outlook shows the release time as its delivery time.
- You can't release a message to the same recipient twice.
- When a user asks for release, the status shows Release requested and the default alert policy User requested to release a quarantined message notifies admins. Approve with Release or reject with Deny; a denial applies to all recipients.
What users can do themselves is set by quarantine policies at Email & collaboration › Policies & rules › Threat policies › Quarantine policies. The built-in AdminOnlyAccessPolicy, DefaultFullAccessPolicy and DefaultFullAccessWithNotificationPolicy are read-only, so create a custom policy (for example, one that lets recipients request release) and assign it in the relevant anti-spam or anti-phishing policy. Changes only affect messages quarantined afterwards, and users can never self-release malware or high confidence phishing.
Step 4: Report through Submissions if you didn't at release#
If the message was released without reporting, or went to Junk instead of quarantine, go to Actions & submissions › Submissions, stay on the Emails tab and select Submit to Microsoft for analysis. Provide the network message ID (from the X-MS-Exchange-Organization-Network-Message-Id header) or upload the .eml or .msg file, choose the affected recipient, and select I've confirmed it's clean. On the next page select Allow this message and keep the default expiry. Admins can submit messages up to 30 days old.
- Allow entries are created only for the parts the filters judged bad; if the sender wasn't the problem, no sender entry appears.
- For impersonation false positives, the sender or domain is added to Trusted senders and domains in the anti-phishing policy that caught it instead.
- Allow entries for spoofed senders never expire.
Verify#
- Check the submission's Result. Policy or override findings appear within minutes; detonation and grader results can take up to a day.
- Confirm the new entries and their expiry on the Tenant Allow/Block Lists page in the Defender portal.
- Use message trace in the Exchange admin center to confirm delivery; a released copy carries
SFV:SKQin its antispam header.
Tips and gotchas: why broad bypass rules backfire#
- They don't fix the cases that matter. Under secure by default, malware and high confidence phishing are quarantined even when a mail flow rule, Safe Senders entry, IP Allow List entry or anti-spam allow list says otherwise. A bypass only weakens protection against spam, phishing and spoofing.
- Domain-only conditions invite spoofing. Microsoft says never to build a bypass-spam-filtering rule on the sender domain alone. If you truly need one, also require the
Authentication-Resultsheader to containdmarc=passordmarc=bestguesspass, stamp a custom header so you can trace it, and never use your own accepted domains or popular domains. - There's an order of preference. Microsoft ranks Tenant Allow/Block List entries first, then mail flow rules, Outlook Safe Senders, the IP Allow List and, last, allowed sender or domain lists in anti-spam policies.
- Real exceptions have a home. Third-party phishing simulations and SecOps mailboxes belong in the advanced delivery policy, not in bypass rules.
- Third-party filtering changes the picture. If your MX record points to a non-Microsoft service, secure by default doesn't apply, and non-Microsoft filtering in the mail path can re-quarantine released messages or strip their content.