How to Block Email Forwarding from Power Automate

Email Exfiltration Controls for Office 365 connectors

Updated: 18 June 2021

In May, I wrote two articles about how Office 365 tenants can restrict users autoforwarding email from their Exchange Online mailboxes. The first article covered OWA, the second more general restrictions. In the second article, I pointed out that Power Automate (aka Flow) cheerfully ignores any restrictions imposed by Exchange Online, thus giving those who want to transfer email outside the organization a handy way to accomplish their goal.

That was then and this is now. Microsoft has just introduced some additional capabilities to help tenants control “email exfiltration” through Office 365 connectors. The immediate use case is to stop Power Automate flows sending, forwarding, or replying to email. Exfiltration is an interesting word to choose, and one that will be unfamiliar even to native English speakers. One definition I found that seems to fit is that data exfiltration is any unauthorized movement of data. In this instance, we want to keep email inside Exchange Online so that it’s exposed to compliance and data governance tools, so the unauthorized movement of data is of messages to an external email address.

Exfiltration Headers

There’s nothing complicated in the new controls. Some well-understood and reliable mechanisms are deployed to detect and stop outbound email generated by Power Automate addressed to external recipients. What’s changed recently is that Power Automate now adds an SMTP x-header to messages to identify its traffic. For example, I created a flow to fire when a new item is added to a SharePoint list. The message sent has the following headers:

x-ms-mail-application: to identify that the message comes from Power Automate. For example, my flow generated the following header. The underlined identifier is important because it can be used to allow or block messages from specific flows.

Microsoft Power Automate; User-Agent: azure-logic-apps/1.0 (workflow d356b212a66640dab94fd13546ca88d8; version 08586039113867675952) microsoft-flow/1.0

x-ms-mail-operation-type: to identify whether the message is a send, forward, or reply. In this instance, SharePoint Online creates a new message, so the action noted is Send. The value can also be Forward. Either will work.

To find this information, I sent the message to an Outlook.com address and examined it with the Message Header Analyzer after it was delivered (Figure 1).

Implementing an Email Exfiltration Block in a Transport Rule

Anyone who has ever created an Exchange transport (mail flow) rule knows that all outbound mail passes through the transport service, which examines and applies the conditions set in rules. In this instance, the rule is very simple. Figure 2 shows all that’s needed for a complete block of all email sent to external recipients via Power Automate flows.

The rule is: If the recipient is external, check if the x-ms-mail-application header is present and contains the words “Power Automate.” If it does, block the message and send the user a reject notification.

The rule conditions and action are: If the recipient is external, check if the x-ms-mail-application header is present and contains the words “Power Automate.” If it does, block the message and send the user a reject notification.

You can compose some nice text to explain the problem to the user which Exchange Online will insert into the reject message (Figure 3).

Microsoft’s article explains how to add conditional processing and exceptions. You might want to allow some flows to run because they are needed to send email to invoke an external process, or you might want to allow flows from specific senders or addressed to specific recipient addresses because you’re happy that the email is necessary and doesn’t compromise the organization’s data governance policy.

Good Flow Controls

The email exfiltration control is simple and effective. It’s just strange that it’s taken Microsoft four years since the introduction of Flow in April 2016 to figure out that controls are needed over email generated by Power Automate. In their defense, the data governance landscape was very different in April 2016 and Office 365 did not have the same kind of compliance feature set that’s available now.