The Hidden Caveat of Safe Senders
If you use any version of Outlook (desktop, mobile, or OWA), you are probably familiar with the Outlook Safe Senders feature. The feature allows users to add email addresses and domains to a block or allow list (Figure 1). While this looks like an innocent setting at first, adding entries to the safe sender list can impact the amount of phishing or spam emails that are delivered to an end user’s inbox.
The Issue
The issue created by the Safe Sender feature might not be apparent at first. When I flag the use of safe senders during a security assessment, customers are often surprised. Most think that the safe senders list does not override the anti-spam policies configured in Exchange Online, but the opposite is true. The effect is documented on Microsoft Learn and depends on your anti-spam policies’ configuration.
What happens when someone adds an address to the safe senders’ list and a message is sent? Let’s explain it with an example where john@practical365.com sends an email to me.
- If the message is phishing or junk.
- If your Exchange anti-spam policy redirects these emails to junk:
- The email is delivered to the inbox.
- If your Exchange anti-spam policy redirects these emails to quarantine and the sender isn’t listed in the Tenant Allow/Block List:
- The email is only delivered to the inbox if I added ‘john@practical365.com’ to the safe senders.
- If I added the entire practical365.com domain, the email would still be delivered in quarantine.
- If your Exchange anti-spam policy redirects these emails to junk:
- If the message is high-confidence spam, phishing, or malware, the mail is always delivered in quarantine or junk folder.
This configuration overrides many protection mechanisms an email administrator implements. While working for a customer, I came across a case where the CEO of the company Contoso received a blatant phishing email using the Contoso.com domain. While investigating the email, I identified that the message failed both SPF and DKIM checks. Nevertheless, the email still arrived in the CEO’s inbox. After investigating, I found that the CEO had added info@contoso.com to their safe sender list, as an email from their marketing team had once ended up in spam. This is just one story of many about this configuration. It is not commonly known to every administrator and can lead to confusion.
Assessing the Impact
If you have a Microsoft Defender for Office 365 Plan 2 license, you can use the Threat Explorer and the ‘Primary override’ filter to see what emails are being delivered to inboxes because of a safe senders configuration. By selecting allowed by user policy, you can view all emails delivered to the inbox because of a safe sender entry (figure 3). If you want to identify all malicious emails delivered in the inbox, add the filter ‘threat type’ and select Malware, Phish, and Spam.
The same information can also be retrieved using advanced hunting. By running the following KQL query in the Microsoft Security portal, you can view all the domains that were delivered in the inbox because of a user’s configuration and were detected as spam, phishing, or malware.
EmailEvents | where Timestamp > ago(30d) | where UserLevelAction == "Allow" and ThreatTypes != "" | summarize count() by SenderFromDomain | order by count_ desc
Fixing the Issue
Fixing this issue can only be done using PowerShell. This is a bit unfortunate because a clear configuration in the Exchange Admin Center would make it more apparent what the effect of this default behavior is.
The junk email configuration is saved in a hidden inbox rule in the user’s mailbox. If you want to retrieve the current configuration of a particular mailbox, you can run the following command after connecting to Exchange Online PowerShell.
Get-MailboxJunkEmailConfiguration -Identity thijs@practical365.com.
This command returns a few properties of interest:
- Enabled: Details whether this configuration is enabled. If the value is true, this setting is enabled and will affect spam filtering.
- TrustedSendersAndDomains: Entries in this list can bypass the built-in EOP scanning depending on the type of detection.
- TrustedRecipientsAndDomains: This setting is reserved for Microsoft and cannot be updated. In my testing, it is the same value as the TrustedSendersAndDomains settings.
- BlockedSendersAndDomains: Emails from recipients on this list are delivered to the junk folder.
If you want to turn off the configuration for a single user, run the following command:
Set-MailboxJunkEmailConfiguration -Identity thijs@practical365.com -Enabled $false
When a mailbox junk mail configuration is disabled, entries in the trusted senders’ list are ignored when Exchange Online checks whether to deliver the email to the inbox or junk folder/quarantine. The configured list of safe and blocked senders remains. To remove all entries in the list, run the following command:
Set-MailboxJunkEmailConfiguration -Identity thijs@practical365.com -TrustedRecipientsAndDomains $null
However, there is still a good reason to add entries to the safe senders list; this is covered in the last section of this article.
Automating the Solution
Unfortunately, the solution above is a process that must be executed for every mailbox. There is no way to configure a default value for mailbox junk email configurations. However, this is something we can easily automate.
If the same configuration should apply to every user, you need to run this script continuously. This can be achieved by running an Azure Automation runbook on a schedule. See this article about using a Managed Identity to run Exchange Online scripts with Azure Automation. The technique explained in that blog can be used to check mailboxes to find those who need an update for their junk mail configuration.
This code is an example of how to automate processing:
Connect-ExchangeOnline -ManagedIdentity -Organization practical365.onmicrosoft.com [array]$mailboxes = Get-ExoMailbox -RecipientTypeDetails UserMailbox -ResultSize Unlimited foreach ($mailbox in $mailboxes) { $currentJunkConfiguration = (Get-MailboxJunkEmailConfiguration $mailbox.UserPrincipalName).Enabled if($currentJunkConfiguration -ne $false){ Write-Host "Updated configuration $($mailbox.UserPrincipalName)" Set-MailboxJunkEmailConfiguration $mailbox.UserPrincipalName -Enabled $false } }
This code will run over every mailbox and disable the setting if it’s not already set.
The Use Case for Safe Senders
Even though you want to disable the junk email configuration for all mailboxes, this does not mean the use case for safe senders goes away. The main advantage of safe senders is that images, within emails from entries in the safe senders lists, are automatically downloaded.
A few of my customers have a use case with emails in specific corporate newsletters, where images should be downloaded automatically. Adding the required domains to the safe senders list ensures that the images within those emails are downloaded automatically.
If you don’t want to run a script on a schedule to add the correct entries, this can also be covered using Intune or GPO. The advantage of configuring it within the cloud junk configuration is that this applies to all applications, whereas the Intune configuration is only active on managed devices.
Shadow Configuration
This setting is one that I describe as ‘shadow configuration’. To me, there is no reason why anyone should be able to override the global configuration made by the Exchange Online Administrator. Adding email addresses or domains to an allow list exposes the organization to risk when someone impersonates that domain. I strongly recommend turning off this setting and managing all safe senders globally using the Tenant Allow/Block list.
Cybersecurity Risk Management for Active Directory
Discover how to prevent and recover from AD attacks through these Cybersecurity Risk Management Solutions.
If using a 3rd party Email filtering system such as mimecast/proffpoint/ barracuda etc this could be controlled at that level. So would it still be worth implementing this when using such services with Exchange Online? Thanks
The requirement is removed if those 3rd party systems send emails to their own quarantaine, instead of O365. If they are still sent to O365, this is still applicable
Does this includes any rules to may have created? If we created a rule to quarantine any from the domain @practical365.com, but a user had added john@practical365.com to their safesenders list, it would be delivered.
It depends on how you setup your transport rule, but yes it is possible.
This is able to override the SCL verdict.
In your use case, the real issue is they need to block all external messages that list their internal domain in the from field, way before it gets to the user.
I 100% agree, there were multiple controls that weren’t in place.