The Choice Between Outlook’s Junk Email Filter or Tenant-Level Blocks

Should User Junk Email Options Affect Anti-Spam Filters?

A recent article about how end users can bypass Exchange Online Protection related to how a CEO mailbox received a blatant phishing email. The root cause identified by the author was the presence of an entry for the sender address in the mailbox’s safe senders list. This led to a recommendation to use the Set-MailboxJunkEmailConfiguration cmdlet to disable Outlook’s junk email filter rule for all mailboxes and use the tenant allow/block list instead.

The Outlook junk email filter has existed for many years. It dates back to a time when spam and malware traffic circulated at much lower volumes but mail servers, including Exchange Server, didn’t have the same anti-spam capabilities that are available today. Including a rule in Outlook to filter spam-protected users against malicious messages that arrived in the Inbox. Microsoft’s SmartScreen technology (introduced in 2003 and deprecated in 2016) gave Outlook the intelligence to detect problems in arriving messages and move those deemed bad to the Junk Email folder.

Junk Email Options

Outlook’s Junk Email Options (Figure 1) dictate whether Outlook attempts to detect malicious email. The default option is No Automatic Filtering, meaning that Outlook doesn’t attempt to perform anti-spam protection. This is the recommended value for Exchange Online mailboxes.

The reason why is simple. Inbound email for Exchange Online mailboxes pass through Exchange Online Protection or Microsoft 365 Defender XDR for Office 365 (or perhaps a third-party email hygiene service). In other words, a dedicated service that uses up-to-date intelligence checks inbound email. There’s no need for Outlook to apply its now outdated SmartScreen checks.

The Safelist Collection

Guidance for the junk email filter comes from the safelist collection. The collection is composed of three lists: safe senders, blocked senders, and safe recipients. Users manage these lists through the tabs in Outlook Junk Email options and Outlook synchronizes their contents to Exchange Online Protection. The intention is that the safelist collection supplements Exchange Online Protection with extra intelligence based on real-world user activity.

People know who sends them email and they can recognize bad emails if they get through. This is the reason why users can tag senders as safe or block senders as they process messages, or mark email as not junk. The results of these actions end up in the safelist collection, which is stored as a hidden rule in the mailbox and shared by Outlook and OWA.

It’s possible that users make mistakes and include a bad address in their safelist. This is the issue highlighted in the article where an address used by a spammer was marked as a safe sender. When a malicious message arrived from the spammer, Exchange Online Protection recognized it as coming from a safe sender and set its Spam Confidence Level (SCL) to -1.. Instead of being delivered to the Junk Email folder in the destination mailbox, Exchange Online routed the message to the Inbox because its SCL was -1.

The delivery of the problem message to the Inbox flowed from the user’s attestation that they recognized the sender as safe. It can be difficult to distinguish between a perfectly valid message containing hyperlinks to websites from a known correspondent and a phishing message such as those used in business email compromise (BEC) attempts.

What happens next depends on the level of awareness that the recipient has about phishing attempts. Hopefully, they recognize the message as bad and report it to Microsoft. However, the safe sender entry still remains in the safelist collection, meaning that the cycle can restart in the future.

Lack of Safelist Maintenance

Another problem is the simple fact that users seldom pay much attention to the content of their safelist collection. Over time, the number of safe and blocked senders usually accrues. Many of the entries remain valid but some might not be. But no matter what age the entries are, Exchange Online Protection honors the complete safelist collection.

Moving to Tenant Blocks

The possibility that dangerous messages might sneak past the carefully erected anti-spam and anti-malware defenses managed at the tenant level is a driving factor for considering the exclusive use of tenant-wide blocks. The previous article included some PowerShell code to find all mailboxes and disable the Outlook junk email rule for each mailbox. The code works well as a one-time action, but ongoing operations require an expanded approach.

If the tenant doesn’t want users to maintain safe sender and blocked sender lists, some mechanism is needed to allow people to inform administrators when they have a candidate blocked sender. Safe senders can’t be added directly to the tenant allow/block list, and the submission process for Microsoft to check false positives to identify safe senders is very different than adding an email address to the safe sender list in Outlook.

Some might query why Microsoft doesn’t allow administrators to add addresses to the allow list. Well, adding an incorrect entry to a mailbox’s safe sender list can expose that mailbox to unwanted email. Adding an incorrect entry to a tenant’s allow list can expose the entire tenant to threats transmitted in email. I guess the potential for widespread infection is the reason why Microsoft requires that email goes through a submission and review process before they approve the addition of the sender to the allow list. Senders remain on the list for 30 days to allow Microsoft to learn why their original email was blocked. If necessary, Microsoft will extend their presence in the allow list. Eventually, Microsoft’s algorithms should recognize the sender as safe and they leave the allow list.

The amount of work involved in processing user requests to block addresses can create an unwelcome load for administrators, so maximum automation is required. If an administrator approves a user request to block an address, the address should flow through to the tenant allow/block list. Some combination of Power Automate to accept and process user submissions together with a SharePoint list to store details might be a good basis for a solution. Once approved, an Azure Automation runbook running on a schedule can update the tenant allow/block list. These topics are food for thought to cover in other articles. For now, let’s focus on disabling the Outlook junk email rule.

Blocking Outlook Junk Email Rules

New mailboxes join tenants all the time. New mailboxes receive a default Outlook junk email rule. We therefore need a process that checks for newly added mailboxes and:

• Disables the rule.
• Clears out the safelist collection so that Exchange Online Protection ignores their entries.

This is a hard-core approach to the issue. As pointed out in the original article, some advantages accrue from having entries in a safe sender list, not least to have Outlook display embedded images. However, for now, we’ll press on and create code to find and process mailboxes created in the last seven days. Obviously, the job needs to run weekly to be sure of finding mailboxes created since the last run.

Here’s the code to find and update mailboxes.

# Establish how far back we look
[string]$CheckDate = (Get-Date).AddDays(-7)
# Find matching mailboxes
[array]$Mbx = Get-ExoMailbox -RecipientTypeDetails UserMailbox -ResultSize Unlimited -Filter "WhenCreated -gt '$CheckDate'"

If ($Mbx) {
    $Report = [System.Collections.Generic.List[Object]]::new()
    ForEach ($M in $Mbx) {
        $CurrentJunkMailConfiguration = Get-MailboxJunkEmailConfiguration -Identity $M.ExternalDirectoryObjectId
        If ($CurrentJunkMailConfiguration.Enabled -eq $True) {
            Set-MailboxJunkEmailConfiguration -Identity $M.ExternalDirectoryObjectId -Enabled $False `
            -BlockedSendersAndDomains $null -TrustedSendersAndDomains $null -TrustedRecipientsAndDomains $null 
    
            $DataLine = [PSCustomObject][Ordered]@{
                Mailbox                         = $M.DisplayName
                UPN                             = $M.UserPrincipalName
                'Trusted Senders and Domains'   = $CurrentJunkMailConfiguration.TrustedSendersAndDomains.Count
                'Blocked Senders and Domains'   = $CurrentJunkMailConfiguration.BlockedSendersAndDomains.Count
                'Contacts Trusted'              = $CurrentJunkMailConfiguration.ContactsTrusted
            }
            $Report.Add($DataLine)
        } Else {
            Write-Output ("Mailbox {0} already has the junk email rule disabled" -f $M.displayName)
        }
    }   
} Else {
    Write-Output "No mailboxes found to update..."
}

The full script, which includes code to email the output report to an administrator account (Figure 2), is available from GitHub.

Test, Pause, and Reflect

I don’t suggest that any organization dumps the Outlook junk email rule without some thought. People have used Outlook for many years and have accumulated working habits that need adjustment for such a switchover. If you’re interested in moving to tenant-level blocks and removing the ability of users to maintain their safelist collection, I recommend that you test with a selected group of users to understand whether tenant-level blocks are more effective, to develop processes for how people flag false positives and request blocks, and perhaps consider disabling the Junk Email filter for Outlook clients.

Running tests to understand the best approach for a tenant takes time and effort. It’s not something that can happen in a week. From my own experience, disabling the Junk Email filter resulted in a marked increase in the number of quarantined messages. Being forced to deal with quarantine notifications can be a source of user frustration, especially if messages that really should get through are blocked, as in the case of the message shown in Figure 3. If the Outlook Junk Email filter is enabled, I could add Practical365.com to the safe sender list and stop Exchange Online Protection from blocking its messages.

Security experts like Thijs Lecomte and Ru Campbell would dump the Outlook junk email rule in a heartbeat. As with many things we deal with in life, compromise is often required to find balance. In this case, the balance is between security and usability. Finding out how to reach that balance depends on the needs and situations of individual tenants. That means, it’s up to you to decide.