Microsoft Defender for Email & Collaboration - "Whitelist"

[somaji]

We have "Whitelisted" some domains (e.g. appriver.com) by adding the domain to "Add trusted senders and domains" in the Spam policies; as well as adding a rule in Microsoft365 Exchange Mail flow Rule with the following settings:

Rule description

Apply this rule if

sender's address domain portion belongs to any of these domains: '<domain>.com' Do the following

Set the spam confidence level (SCL) to '0'

As these time-sensitive messages arrive within/out of business hours. The messages are still quarantined for the users.

Any suggestions on how to resolve the issue is much appreciated.

[#2]

Hello @somaji,

1. Try to change the SCL to -1.

2. Go to Quarantine and check the reason why these emails were quarantined. Probably, there is another reason (Phish). 

[#3]

@mikhailf
Thank you.

I had the SCL set to -1; I switched to 1 following Microsoft's SCL scaling documentation.;since it was not working.

Quarantine details
Quarantine Reason: Spam
Policy type: Anti-spam Policy (Name: Strict Preset Policy),
Delivery Action: Blocked
Location: Quarantine
Primary Override: Source Blocked by user policy; Sender address list
DMARC Pass
DKIM Pass
SPF Soft fail
Composite Auth: Pass

Any suggestions?

[#4]

"Primary Override: Source Blocked by user policy; Sender address list"
Check the Blocked domain/sender lists in the Anti-spam policy.

[#5]

Hi @somaji
Please also try to give the rule a higher priority.

[#6]

@mikhailf

For the policy, the domains are in Allowed Domains list; the e-mail addresses are also in Allowed Senders list; which is redundant I think. When one didn't work, I added the other. I think either the issue is somewhere else, or I am not understanding where to make the change (Defender Portal -> Email & Collaboration -> Policies & Rules -> Threat Policies -> Anti-Spam Policies -> Anti-Spam inbound policy)

[#7]

Ensure that in all policies you have the Sender is not in blocked senders and domains.
For example, when you open Anti-Spam policy and scroll down, you will see there "Allowed and blocked senders and domains" -> Blocked senders / Blocked domains.

In addition to that, check if you have Preset policies. You can try to exclude the sender there as well.

[#8]

Hey @somaji! - hope you're well :)

I'd love to help you get this resolved.

Firstly, allowlisting (new terminology for whitelisting) domains / senders / IPs is not a decent solution, my personal analogy to explain why is that if the diagnostic fault light came on in your car, that's the car telling you something is wrong. - simply adding an allow-list entry is like putting a piece of tape over that light so you can't see it anymore, you're ignoring the issue which needs to be fixed.

An email being sent to the quarantine can be seen as Defender telling you theres something wrong with the email, so we need to fix the underlying issue, which usually is one of a few things:

- There is actually a problem with the email or its contents, for example it could be a URL inside that email which is malicious, or the authentication failed causing a DMARC failure.

- There isn't an issue with the email, and we've got our verdict wrong, in which case you should complete an admin submission (which will also allow you to temporarily allow whatever was causing the detection while we update the underlying reason the detection technology caught it. 

- However, this looks like a third possible problem the fact I see you posted "Blocked by user policy; Sender address list" indicates the recipient of the message has added the sender to their personal block list, aka they do not want to recieve emails from that sender / domain. - this in turn is setting the SCL to a level where the strict preset policy then quarantines it. (so all very by design) - I'd expect you to find "SFV:BLK" in the headers when viewed in quarantine.

To rectify this, the user(s) can remove the block entries from their personal allow / block list in OWA, but you can also view to be sure (or adminstratively control) using the Set-MailboxJunkEmailConfiguration cmdlet 

Hope that is of use! - please let me know if I've misunderstood the issue and you need more help.

Ben.

[#9]

@Ben_Harris,
I could not have phrased it better (paragraph 1). The messages, appriver included, are from a third party solution that has an automated e-mail sent out to us, as well as having hundreds, if not thousands or of clients; which leads me believe we would not be the only client that has this issue; and may resolved it by now. The cause may be in my e-mail protection; so I whitelisted (oh, allowlisted ) the domain as well as the source e-mail adress; which still has not resolved the issue.

As per your suggestions for a third possible problem, I am unable to find SFV:BLK in the header. But, I see some hint of an issue. Would you mind helping?

Here are some portions of the header that may be of use:

X-MS-Exchange-Organization-InternalOrgSender: False
Authentication-Results: spf=softfail (sender IP is x.xxx.xxx.xx)
smtp.mailfrom=domain.com; dkim=pass (signature was verified)
header.d=domain.com;dmarc=pass action=none
header.from=domain.com;compauth=pass reason=100
Received-SPF: SoftFail (protection.outlook.com: domain of transitioning
domain.com discourages use of nnn.nnn.nnn.nnn as permitted sender)
X-ALLOW: ALLOWED SENDER FOUND
X-Virus-Scan: V-
X-Note: Spam Tests Failed:
X-Note: Mail Class: ALLOWEDSENDER
X-MS-Exchange-Organization-CompAuthRes: pass
X-MS-Exchange-Organization-CompAuthReason: 100
X-MS-Exchange-Organization-SenderRep-Score: 3
X-MS-Exchange-Organization-SenderRep-Data:
IpClassLargeGrayOther_GrayOther_GrayOther
X-MS-Exchange-Organization-VBR-Class: GrayOther
X-MS-Exchange-Organization-HMATPModel-Spf: 3
X-MS-Exchange-Organization-HMATPModel-Recipient:
X-MS-Exchange-Organization-TransportTrafficType: Email
X-MS-PublicTrafficType: Email
X-MS-Exchange-Organization-MessageLatency:
X-MS-Exchange-Organization-Auth-DmarcStatus: Pass
X-MS-Exchange-Organization-VerifiedDkimDomainsList: domain.com;domain.com

[#10]

@somaji Thanks, I understand your issue I believe, and would expect that your allow list entry would not fix it, as it looks to be from what you've posted, a personal block list overriding the verdict. - can you please let me know the "SFV:" verdict in the headers of one of the affected emails? - I'm expecting to see SFV:BLK

Anti-spam message headers - Office 365 | Microsoft Learn

[#11 · Accepted solution]

I do see SFV:BLK in the header.

[#12]

@somaji - Perfect, in which case this text from the documentation should be of assistance. 

Filtering was skipped and the message was blocked because it was sent from an address in a user's Blocked Senders list.

For more information about how admins can manage a user's Blocked Senders list, see Configure junk email settings on Exchange Online mailboxes.

Thanks :)

Ben.