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.

How End-users Can Bypass Exchange Online Protection
Figure 1: Configuring safe senders in OWA              

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 the message is high-confidence spam, phishing, or malware, the mail is always delivered in quarantine or junk folder.
How End-users Can Bypass Exchange Online Protection
Figure 2: Actions defined in an anti-spam policy

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.

How End-users Can Bypass Exchange Online Protection
Figure 3: Using the Threat Explorer to assess the impact

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.

About the Author

Thijs Lecomte

Thijs is a security consultant out of Belgium, working at The Collective, an MSSP with a Microsoft-focused Security Operations Center. His work consists out of leading the SOC team and implementing Microsoft Security solutions (such as Microsoft Sentinel and Defender) as a consultant. He is an MVP in the Security category and is a regular speaker at events and user groups. His best-known publication is as co-author of the 'Microsoft 365 Security for the IT Pro' ebook.

Comments

  1. Darren DeHaven

    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.

    1. Avatar photo
      Thijs Lecomte

      I 100% agree, there were multiple controls that weren’t in place.

Leave a Reply