Forum Discussion
Help me understand why this email was quarantined?
I'm pretty familiar with Defender's Threat Policies. I've probably set them up on 40 tenants. I know the Hosted Content Filter Policy is backend for Anti Spam Inbound policy. I know that, confusingly, the AntiSpam Inbound Policies contain the actions for High Confidence/Normal Confidence Phishing - NOT the AntiPhishing policies (which seem more geared towards impersonation). What I DON'T know is why this was quarantined - and whether the anti-phish policy had anything to do with it. The Policy Type linked is the IB Anti Spam. This tenant is one of the few we have set at a BCL tolerance level of 7 - which shows me that 0 messages in the last 60 days would've been caught for this reason (which would include the email in question). So it was either the SCL or some 'anti phish' component of the anti-spam policy. I have none of the custom 'increase spam score' markers here. I was sure there was a 'evidence' tab within email entity, but i guess not - the only info I have about the detection (now released) is the following:
This particular sender does not send reliably over 45 days, but also has been a business partner of this tenant for decades. So rather than the Tenant Allow/Block list which allows a max of 45 days, I want to add it to the offending policy. which SEEMS like it would be the inbound anti-spam - except that it also says it's phishing everywhere. I don't want to bypass both the phishing and spam policies unless I have to - but I don't really know why this got blocked.
It's an external address that had sent an email days ago that got through without issue... This one has an attached pdf, but so do they all.
Thoughts?
Thank you for the detailed breakdown. Based on what you shared and the quarantine report screenshot, the key trigger here seems to be the High Confidence Phish classification applied by the Hosted Content Filter Policy, which, as you know, is part of the Anti-Spam Inbound layer.
Even though the BCL tolerance is set to 7 and historical data shows no BCL based filtering, BCL wouldn’t play a role in “phish” detections those are typically driven by SCL or additional anti-phish logic within the Anti-Spam Inbound policy. It appears the message likely hit an SCL of 8 or 9 behind the scenes, triggering the quarantine action.
It’s also worth noting that Defender’s anti-phish protections are layered and sometimes ambiguous. The Anti-Phishing policies generally focus on impersonation and domain spoofing, but if the Anti-Spam Inbound policy detects strong phishing indicators especially based on heuristics, header anomalies, or content patterns it can override and trigger quarantine with a “High Confidence Phish” flag, even if impersonation policies didn’t directly contribute.
Given the sender is a long-term business partner but exhibits unreliable sending patterns, it’s possible their infrastructure or sending behavior triggered heuristics, especially with attachments like PDFs involved.
Suggested Approach:
- Before bypassing both anti-phish and anti-spam protections globally, I’d recommend:
- Reviewing message headers (especially SCL and any X-MS-Exchange-Organization-* indicators).
- If truly confident it’s a false positive, use Allowed Senders/Domain within the specific Inbound Anti-Spam policy rather than relying solely on the Tenant Allow/Block list or global exclusions.
- Avoid broad bypasses for both spam and phish unless absolutely necessary.
Unfortunately, yes, the evidence tab you were looking for (detection reasons, AI triggers, etc.) isn’t exposed as granularly as we’d like for all cases post-release. Raising a support ticket may be the only way to extract deeper detection logs if still needed.
Best Regards,
Ali Koc
4 Replies
This page - View email security reports in the Microsoft Defender portal - states this about "Advanced Filter":
- Advanced filter: Phishing signals based on machine learning.
...and it has that exact statement 3 times. So I hope they're correct. It seems correct when we look at their definition for "General Filter":
- General filter: Phishing signals based on analyst rules.
Thanks for the analysis. The trigger was the High Confidence Phish flag from the hosted content filter. BCL wasn’t a factor; likely caused by an SCL score of 8 or 9. Heuristics or suspicious PDFs can trigger quarantine, even without spoofing. I suggest reviewing headers (SCL/X-MS) and using Allowed Senders in the inbound policy. Avoid global overrides unless absolutely necessary. For deeper insights, a support ticket may be required.
Thank you for the detailed breakdown. Based on what you shared and the quarantine report screenshot, the key trigger here seems to be the High Confidence Phish classification applied by the Hosted Content Filter Policy, which, as you know, is part of the Anti-Spam Inbound layer.
Even though the BCL tolerance is set to 7 and historical data shows no BCL based filtering, BCL wouldn’t play a role in “phish” detections those are typically driven by SCL or additional anti-phish logic within the Anti-Spam Inbound policy. It appears the message likely hit an SCL of 8 or 9 behind the scenes, triggering the quarantine action.
It’s also worth noting that Defender’s anti-phish protections are layered and sometimes ambiguous. The Anti-Phishing policies generally focus on impersonation and domain spoofing, but if the Anti-Spam Inbound policy detects strong phishing indicators especially based on heuristics, header anomalies, or content patterns it can override and trigger quarantine with a “High Confidence Phish” flag, even if impersonation policies didn’t directly contribute.
Given the sender is a long-term business partner but exhibits unreliable sending patterns, it’s possible their infrastructure or sending behavior triggered heuristics, especially with attachments like PDFs involved.
Suggested Approach:
- Before bypassing both anti-phish and anti-spam protections globally, I’d recommend:
- Reviewing message headers (especially SCL and any X-MS-Exchange-Organization-* indicators).
- If truly confident it’s a false positive, use Allowed Senders/Domain within the specific Inbound Anti-Spam policy rather than relying solely on the Tenant Allow/Block list or global exclusions.
- Avoid broad bypasses for both spam and phish unless absolutely necessary.
Unfortunately, yes, the evidence tab you were looking for (detection reasons, AI triggers, etc.) isn’t exposed as granularly as we’d like for all cases post-release. Raising a support ticket may be the only way to extract deeper detection logs if still needed.
Best Regards,
Ali Koc
Based on what you shared, the quarantine likely came from the Anti-Spam policy due to phishing detection (SCL rating or anti-phish signals within that policy), even though it’s not the Anti-Phish policy itself. Since the sender isn’t consistent over 45 days, Defender might treat them as suspicious despite the history.
To allow this sender long-term, adding them to the Inbound Anti-Spam policy’s allow list is a good move. That way, you avoid bypassing phishing filters unless truly necessary.
