Defender Email threat detection and SCL different per recipient

[Eric_H]

We have been seeing phishing emails reach user inboxes when they shouldn't.  A phishing email will be sent to several users, and Defender will quarantine it for some users, and deliver it to others.  All the users have the same Anti-Spam and Anti-Phishing policies which have been reviewed by Microsoft Gold partners and Microsoft support several times.  These emails also do not have any overrides (transport rules or user settings) that are changing the behavior.  

After many tickets with Microsoft support over the last 6 months (the current one open for over a month), I have discovered that the SCL is different per recipient for the same email.  This doesn't show up very well in the security portal because the portal may only show one version of the header no matter which recipient you look at.  But if I download the messages for each recipient I'll find that some of the recipients see the email as SCL 5 (is spam) in the header, and other recipients for the same email show SCL 1 (not spam) in the header.    And it seems the SCL level directly affects the phish detection / Threat analysis.  When the email comes in with suspicion of being phishing (spoofed domain), Microsoft adds the analysis to the header (SFTY:9.25). Now if the SPAM detection is SCL 5 for a recipient, they go ahead and look at the SFTY header and quarantine the message. If SPAM detection is SCL 1 for a recipient, they seam to ignore the SFTY header and do NOT quarantine the message.

Can anyone tell me if the SCL is designed to be different per recipient?!  One MS Support agent suggested that this is by design, and the Defender AI is deciding the SCL value based on the recipient's past behavior, but they also are not closing the ticket and keep analyzing samples I send them (apparently the ticket is with the "product team").  It seems crazy to evaluate the same inbound email differently per recipient, especially if the Threat/Phishing detection is directly dependent on the SCL level.  If it is a threat for one user, it should be threat to all users.  It also means that my anti-spam and Anti-phish policies are useless to fix this, because I cannot change the SCL level that Defender's AI assigns to the email, I can only act on that analysis.

Just really frustrated with the product and support lately and looking for some clarification on how this is supposed to work.  Thank You!  

[#2]

Recipient X may have personal Outlook junk settings and belong to different anti-spam and anti-phishing policies when compared to recipient Y. Aside from that, recipient should not matter.

Get X and Y to both report the message, or make admin submissions yourself for the copies to X and Y. Turn on all of the columns on the submission portal, then do an export and look at the result. Do X and Y have the same network message ID?

Messages can splinter during processing, and it's really not unusual to see the first copies of a phish get through. ZAP should step in and get those for you anyway.

[#3]

Thank you for your reply. I have verified the example email is processed by the same anti-spam/anti-phish policy for each user, and there are no Outlook junk email overrides being applied. I also confirmed that different behavior is taken for the same network message ID (delivered to multiple recipients). Based on all of this data, this seems to be specifically to do with SCL header values being processed differently per user, and then Defender taking different threat actions based on the SCL. One person direct messaged me and had the exact same issue, and the exact same experience with Microsoft Support. If anyone else has this issue please post to help get this addressed.

[#4]

If these are SCL5 verdicts arising from the Advanced Spam Filter then you want to raise a ticket with product support and be prepared to re-test example cases for them. You are correct not to modify your threshold values, though you might mitigate with a mail flow rule for specific friendly sender domains important to your organisation. As always, consider the risk factor and any other rule predicates you can use to reduce the risk of such an exemption.