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 with an efficient exchange online forward policy.

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). Ensuring compliance with the exchange online forward policy helps track dropped messages.

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 with respect to the exchange online forward policy. 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.

FAQs

What are the security implications of not having an Exchange Online forwarding policy in place?

Without a proper Exchange Online forwarding policy, organizations risk data leakage, unauthorized access to sensitive information, and potential compliance violations. Malicious actors could exploit uncontrolled forwarding to exfiltrate data, making it crucial to implement comprehensive Exchange Online forward policy controls.

Can I create different Exchange Online forwarding policy rules for different departments?

Yes, administrators can establish multiple Exchange Online forwarding policy configurations based on departments, security groups, or user roles. This granular control allows organizations to maintain stricter forwarding rules for teams handling sensitive data while providing more flexibility to others.

How often should an Exchange Online forwarding policy be reviewed and updated?

Best practices recommend reviewing your Exchange Online forwarding policy quarterly, or whenever significant organizational changes occur. Regular audits ensure the policy remains aligned with security requirements and compliance standards while identifying any potential gaps in forwarding controls.

What monitoring tools are available for Exchange Online forwarding policy compliance?

Microsoft provides several tools to monitor Exchange Online forwarding policy compliance, including detailed logging capabilities, alert systems, and automated reports. These tools help track policy violations, unauthorized forwarding attempts, and patterns of suspicious forwarding behavior.

How does Exchange Online forwarding policy interact with third-party email security solutions?

Exchange Online forwarding policy can be integrated with third-party security solutions through APIs and connectors. This integration ensures consistent policy enforcement across the email ecosystem while leveraging additional security features from external vendors.