How to Block Email Forwarding in Exchange Online

The first article in this series discussed how to remove the ability of OWA users to create autoforwarding addresses. This does a lot to stop the forwarding of email outside an organization, but OWA is only one part of the problem. We also need to deal with the other ways that messages can be automatically forwarded to external addresses.

For instance, Outlook rules can forward messages. It’s possible to use PowerShell to scan every mailbox for forwarding rules, but that could take a lot of processing that we would have to do on an ongoing basis. Let’s consider some more robust methods to block outbound automatic forwarding.

Blocking by Domains

Blocking by domain is an effective method to stop autoforwarded messages. Blocking is implemented using the Set-RemoteDomain cmdlet (or, in EAC by editing remote domain setting under Mail Flow). This command stops email autoforwarding to any domain except when explicit settings exist to allow forwarding to a domain.

Set-RemoteDomain -Identity Default -AutoForwardEnabled $False

To check if any domain allows autoforwarding, run this command:

Get-RemoteDomain |?{$_.AutoForwardEnabled -eq $True}| Format-Table DomainName, AutoReplyEnabled

DomainName  AutoReplyEnabled
----------  ----------------
Contoso.com             True

Finding Dropped Messages

Administrators can see if a message is blocking by running a message trace using PowerShell or the Message Trace GUI in the Compliance Center (Figure 1).

Image 1 Expand

Given the number of messages that pass through a tenant daily, it’s easier to find the drop events with PowerShell. Because the Get-MessageTrace command can process a lot of data, it’s wise to restrict the timespan used to fetch message events to as limited a period as possible. This code looks for dropped messages for a two-hour period.

Get-MessageTrace -StartDate "11-Feb-2020 17:36" -EndDate "11-Feb-2020 19:37" | Get-MessageTraceDetail | ?{$_.Event -eq "Drop" -and $_.Data -Match "BlockAFToExternalUser"} | Select MessageID, Date, Event, Detail, Data

Use a Mail Flow Rule

The simplicity and directness of blocking autoforwarding to remote domains is attractive, but it is a blunt instrument. Another approach is to create a mail flow rule to intercept messages of type “Auto-forward” sent to external recipients with an action to reject the message and return a delivery notification to the sender with a suitable reason. For example, “Your message was blocked to ensure confidentiality of organization intellectual property.”

Alternatively, you could deliver the autoforwarded message to its intended destination, but only after applying a restrictive sensitivity label to the message so that the recipient doesn’t have the right to read it. The intention here is to make the point to the recipient that they shouldn’t be trying to view content from our organization. Hopefully the recipient will report their annoyance to the sender, who might then realize that they’re doing something frowned upon by the organization.

Beware Power Automate

After erecting all these barriers to stop users forwarding content outside the organization, we run into the problem that Power Automate cheerfully ignores any restrictions imposed by mail flow rules, domain blocks, or removing autoforward addresses from mailboxes. This problem was documented by Vasil Michev some time ago, but Microsoft has done nothing to improve matters.

Update (September 2020): Power Automate now inserts x-headers into messages that can be used to stop this traffic using transport rules.

For instance, you can create a new flow to forward messages when new items arrive in folder using templates provided by Microsoft. I took a standard template, connected it to my mailbox, amended it to monitor the Archive folder, and opted to send copies to an external address (Figure 2).

Image 2 Expand

The result was that each time Power Automate ran the flow, any new message placed into the Archive folder was forwarded to the external address. Messages show up in the message tracing log but look like normal messages.

The set of audit events captured by Power Automate and ingested into the Office 365 audit log is pretty poor and not much help is gained by investigating there. The only thing seen in the audit log is that the user created a flow using the OpenApiConnection connector.

Sensitivity Labels Might Be the Solution

The common thread is that autoforwarded messages can be read by the recipient. To stop this, we need to prevent the recipient being able to open and access the message content, and the only way to do that is to use protected messages.

S/MIME is one approach, but sensitivity labels are a better long-term solution because Microsoft is investing heavily to increase the usefulness of these labels across Office 365. The simple fact is that only those authorized to open protected messages can access their content, so when the messages are forwarded by rules, autoforwarding addresses, or Power Automate, the external recipient won’t be able to read them.

Organization Call

Deciding if users can autoforward email is a decision that should be taken as part of the organization’s data governance strategy. It’s easy erect barriers to autoforwarding if you decide that email should remain inside the tenant, but if you do, remember to communicate the policy to users.