Working as a modern workplace consultant also means that sometimes you have to go deep into Exchange Online options in order to make sure that (sensitive) data of your customer doesn’t leave the organization without the proper security measurements taken. In the Microsoft documentation titled: “Best practices for configuring EOP and Office 365 ATP“, the recommended settings for both Standard and Strict states that Auto-forwarding to external domains should be disallowed or monitored at least.
Automatic email forwarding is one of the possible and still most common way (sensitive) company data might leave the organization. Giving the users the ability to automatically forward emails using either mailbox forwarding or message rules to users outside the organization in that case can be very risky. I’ve seen many cases where corporate email accounts were configured to automatically forward all email to personal gmail.com or hotmail.com accounts. Also still enabled mailboxes which forward mail to users personal accounts while the user doesn’t work at the company anymore is common practice.
It’s also commonly known that if a user somehow gets compromised, hackers usually put a forward on the mailbox of the user in order to gain knowledge about the user in order further continue with their attack methods, or to retrieve sensitive company data for their own gains.
Update August 2020, please also read the following article detailing some upcoming changes which impact this behaviour when you are an ATP customer: Microsoft is making changes related to automatic email forwarding for ATP customers, here is what you need to know
Good reason to disable forwarding of mail to outside of the organization for most of your users, create an exception list in rare circumstances where forwarding is needed and do so in a controlled way so that users are not all of the sudden flooded with non-deliverable emails telling them that auto forwarding is not allowed. This blogpost tries to address the options and a possible scenario on how to take the necessary steps.
Keep in mind that in most cases, the user enables the mail forwarding for a good reason, not aware of the risks. Therefore good communication towards the end-user explaining why automatic forwarding of email isn’t a good idea is necessary.
Ways a user can automatically forward email
A user has several options to automatically forward email to an external users, below are the options within Outlook Web Access (OWA), rules can also be created in Outlook and for forwarding in Outlook the link redirects to the Forwarding page in OWA:
The user configures mailbox forwarding on the mailbox, all email will be send to the external email address (in this case kenneth.vansurksum@wmug.nl which is outside of our organization 
It’s also possible to create a mailbox rule, applying to all messages which redirects to an external email address. 
Another option is to only forward messages meeting certain requirements, like for example having an attachment
If you measure, you know more
Before you start your next steps, it’s a good idea to get an idea of which users are forwarding email within your organization.
To get an idea of how many messages are auto-forwarded within your organization, Microsoft provides a dashboard in the Office 365 Security & Compliance portal. Initially it displays the amount of emails auto-forwarded in the past week, giving a good idea on what you are dealing with.
And if you click through you are presented with a more detailed view detailing how forwarding takes place, you get an overview of the types of forwarding (mail flow, Inbox rules or SMTP forwarding).
If you want even more details, you can click on the Forwarding report, which looks similar as below.
If you have Microsoft Cloud App Security (MCAS), or Office Cloud App Security (CAS) available within your tenant there are several policies available out of the box which can be triggered and send to your Security Operations mailbox.
Disabling Auto-forwarding to external domains
When searching on the internet about the best way to disable auto-forwarding, I quickly found the following article “The many ways to block automatic email forwarding in Exchange Online“. The article, written December 22nd 2017 details the available options in a detailed manner. To summarize, there is no real one click option which does the trick.
You either configure the remote domain option through Exchange Online Admin Center and disable “Allow automatic forwarding”, the big disadvantage of this option is that users are never notified, which is not something you want when disabling auto-forwarding in an existing organization where auto-forwarding is in use.
The other option is to create a transport/mail-flow rule to disable auto forwarding, only disadvantage is that the rule cannot block the Forwarding option on the mailbox of the user. This can be mitigated by creating a custom RBAC role and applying that role to the users. This will remove the forwarding tab from the OWA options at all.
Please read the article carefully and make sure that you are familiar with the options. In this case I decided to use the transport/mail-flow rule in combination with the RBAC role option. The rest of this post will detail my experiences when implementing the suggested options.
Implementation steps
Since we want to implement this change in the environment with minimal impact, we decided to include the users currently having some sort of auto-forwarding enabled in a group for which we will temporarily allow auto forwarding. By doing so, we block any new rules created, and we can reach out to the user already auto-forwarding and help them to find another solution for the reason they setup auto-forwarding to begin with. Once found, we simply can remove the user from the group. We also found that some accounts have a legitimate reason to auto forward, for example a company account which automatically forwards emails with attachments to a specific email address of a SaaS provider which automatically processes the attachment in the system.
Step 1: Investigate which users have auto-forwarding enabled and add them to a mail-enabled security group (in our case called “Allow auto forwarding”)
Step 2: Implement the transport/mail-flow rule from the referenced article in audit only mode and measure what is happening by generating incident reports
Step 3: Modify the transport/mail-flow so that we can exclude a group of users and keep monitoring for incident reports
Step 4: Enforce the transport/mail-flow rule if you a certain that all scenarios are working.
Step 5: Implement a process to review the Allow list on a regular basis
Lessons learned while implementing the mail flow rule
Before implementing the mail-flow rule I first thought about the scenario’s I wanted to test and came up with the following scenario’s:
Scenario 1: Email send from inside or outside of the organization and auto-forwarded to someone outside of the organization must be blocked, unless the user sending the email is member of the “allow auto forward” mail enabled security group.
Scenario 2: Email send form inside or outside the organization and auto-forwarded to someone inside of the organization must be allowed.
Based on the article, the following mail-flow rule was created in audit mode as a starter
Since the proposed configuration lacked some way of reporting I decided to modify the rule and add the option “Generate incident report and send it to…” which sends the email in our case to our Security Operations shared mailbox, monitored by several of our security operators.
Add a shared mailbox which can monitor for the creation of auto-forwarding rules
Make sure that you include just enough content in the email send to your shared mailbox so that you can determine if your security measures are correctly in place.
Challenges while implementing an exclusion group
In order to test the exclusion we modified the transport/mail-flow rule and added the following Except if statement.
While testing the new rule in audit mode to also be able to exclude users we noticed some strange results, some emails from users on the allow list were hit by the rule.
Based on that I decided to test the different scenario’s and use the information in the Incident report to determine the following table:
| Scenario | Int/Ext | Sender | Recipients | To |
| Automatic redirect all messages | External | Sending external email address | Email address forwarded to | Receiving internal email address |
| Internal | Sending internal email address | Email address forwarded to | Receiving internal email address | |
| Automatic forwarding all messages | External | Receiving internal email address | Email address forwarded to | Email address forwarded to |
| Internal | Receiving internal email address | Email address forwarded to | Email address forwarded to | |
| Automatic redirect with attachments | External | Sending external email address | Email address forwarded to | Receiving internal email address |
| Internal | Sending internal email address | Email address forwarded to | Receiving internal email address | |
| Automatic forwarding with attachment | External | Receiving internal email address | Email address forwarded to | Email address forwarded to |
| Internal | Receiving internal email address | Email address forwarded to | Email address forwarded to |
As you can see, when you want to exclude users, the users which are in your allow group sometimes are addressed as Sender, en sometimes as To, therefore we needed to modify the rule to include two Except if statements:
More details about the performed tests can be found at the end of this blogpost, it might come in handy for reference or figuring out what was tested.
Final result
Below is a screenshot of the final result
Conclusion
Do not simply copy everything that is stated in a blogpost from more than 2 years ago, things might have changed in the meantime, or you might have slightly different requirements.
Also make sure that when it comes to transport/mail-flow rules that you fully comprehend the solution and implement ways to measure if what you implemented actually is working as intended. Also using a phased approach when it comes to these kind of changes can come in handy, inform users of your new policy and make your company data more secure one step at a time.
Testing scenario’s
In order to determine the options needed in my transport/mail-flow rule I decided to test several options and investigate the information delivered by the incident send to the shared mailbox
Rules defined on mailbox of user: Ferry Kuhlman (fkuhlman@emshelden.nl), where in every scenario the email gets forwarded to Kenneth van Surksum (kenneth.vansurksum@wmug.nl)
External email used to send email to fkuhlman@emshelden.nl: Kenneth van Surksum (kenneth@vansurksum.com)
Internal email used to send email to fkuhlman@emshelden.nl: Stanley Messie (smessie@emshelden.nl)
Scenario 1: Create a forwarding on the mailbox using the mailbox forwarding option
1a – test using sending an email to the mailbox from an external account
1b – test using sending an email to the mailbox from an internal account
Conclusion: Forwarding is not picked up by the rule, you will not receive any incidents. Hence the reason to disable the option from the console using the custom RBAC role
Scenario 2: Create an automatic forwarding rule on all messages
2a – test using sending an email to the mailbox from an external account
Automatic forwarding (from kenneth@vansurksum.com to fkuhlman@emshelden.nl)
Sender: Ferry Kuhlman, fkuhlman@emshelden.nl
Subject: FW: Autoforwarding test (external)
Recipients: kenneth.vansurksum@wmug.nl
To: kenneth.vansurksum@wmug.nl
2b – test using sending an email to the mailbox from an internal account
Automatic forwarding (from smessie@emshelden.nl to fkuhlman@emshelden.nl)
Sender: Ferry Kuhlman, fkuhlman@emshelden.nl
Subject: FW: Autoforwarding test (internal)
Recipients: kenneth.vansurksum@wmug.nl
To: kenneth.vansurksum@wmug.nl
Conclusion: Automatic forwarding using a rule puts the email to which is being forwarded into both the Recipients and To field
Scenario 3: Create an automatic redirect rule on all messages
3a – test using sending an email to the mailbox from an external account
Automatic redirect (from kenneth@vansurksum.com to fkuhlman@emshelden.nl)
Sender: Kenneth van Surksum, kenneth@vansurksum.com
Subject: Redirect (external)
Recipients: kenneth.vansurksum@wmug.nl
To: Ferry Kuhlman, fkuhlman@emshelden.nl
3b – test using sending an email to the mailbox from an internal account
Automatic redirect (from smessie@emshelden.nl to fkuhlman@emshelden.nl)
Sender: Kenneth van Surksum, smessie@emshelden.nl
Subject: Redirect (internal)
Recipients: kenneth.vansurksum@wmug.nl
To: Ferry Kuhlman, fkuhlman@emshelden.nl
Conclusion: Automatic redirect rules puts the email to which is forwarded into the Recipients field, and the account receiving the email in the To field
Scenario 4: Create an automatic forwarding rule on messages containing an attachment
4a – test using sending an email to the mailbox from an external account
Automatic forwarding with attachment (from kenneth@vansurksum.com to fkuhlman@emshelden.nl)
Sender: Ferry Kuhlman, fkuhlman@emshelden.nl
Subject: FW: Forward with attachment (external)
Recipients: kenneth.vansurksum@wmug.nl
To: kenneth.vansurksum@wmug.nl
4b – test using sending an email to the mailbox from an internal account
Automatic forwarding with attachment (from smessie@emshelden.nl to fkuhlman@emshelden.nl)
Sender: Ferry Kuhlman, fkuhlman@emshelden.nl
Subject: FW: Forward with attachment (internal)
Recipients: kenneth.vansurksum@wmug.nl
To: kenneth.vansurksum@wmug.nl
Conclusion: Automatic forwarding emails with an attachment using a rule puts the email to which is being forwarded into both the Recipients and To field
Scenario 5: Create an automatic redirect rule on messages containing an attachment
5a – test using sending an email to the mailbox from an external account
Automatic redirect with attachments (from kenneth@vansurksum.com to fkuhlman@emshelden.nl)
Sender: Kenneth van Surksum, kenneth@vansurksum.com
Subject: Redirect with attachment (external)
Recipients: kenneth.vansurksum@wmug.nl
To: Ferry Kuhlman, fkuhlman@emshelden.nl
5b – test using sending an email to the mailbox from an internal account
Automatic redirect with attachments (from smessie@emshelden.nl to fkuhlman@emshelden.nl)
Sender: Kenneth van Surksum, smessie@emshelden.nl
Subject: Redirect with attachment (internal)
Recipients: kenneth.vansurksum@wmug.nl
To: Ferry Kuhlman, fkuhlman@emshelden.nl
Conclusion: Automatic redirect emails with an attachment rules puts the email to which is forwarded into the Recipients field, and the account receiving the email in the To field
| Scenario | Int/Ext | Sender | Recipients | To |
| Automatic redirect all messages | External | kenneth@vansurksum.com | kenneth.vansurksum@wmug.nl | fkuhlman@emshelden.nl |
| Internal | smessie@emshelden.nl | kenneth.vansurksum@wmug.nl | fkuhlman@emshelden.nl | |
| Automatic forwarding all messages | External | fkuhlman@emshelden.nl | kenneth.vansurksum@wmug.nl | kenneth.vansurksum@wmug.nl |
| Internal | fkuhlman@emshelden.nl | kenneth.vansurksum@wmug.nl | kenneth.vansurksum@wmug.nl | |
| Automatic redirect with attachments | External | kenneth@vansurksum.com | kenneth.vansurksum@wmug.nl | fkuhlman@emshelden.nl |
| Internal | smessie@emshelden.nl | kenneth.vansurksum@wmug.nl | fkuhlman@emshelden.nl | |
| Automatic forwarding with attachment | External | fkuhlman@emshelden.nl | kenneth.vansurksum@wmug.nl | kenneth.vansurksum@wmug.nl |
| Internal | fkuhlman@emshelden.nl | kenneth.vansurksum@wmug.nl | kenneth.vansurksum@wmug.nl |
transport rule auto-forward blocking doesn’t cover the ‘redirect to’ option in Outlook. So it is ineffective.
http://int21cybersecurityrants.blogspot.com/2020/05/stop-automatic-e-mail-forwarding-in.html
Hi Ron,
First of all, thank you for visiting my blog and leaving a comment.
I’ve read the article you are referring to and finally found some time to further test some scenario’s, but in my environment both the redirect to and forward as attachment mailbox rules are also being blocked by the created Transport rule.
The options described in the article are therefore still valid, it might be do that this behaviour changed in the meantime and at the time you were testing it didn’t work.
Regards,
Kenneth
We are using the ‘Remote Domains’ option to disable Autoforwarding by default in our O365 environment. But there is a third option coming soon to O365 to block Autoforwarding through ATP. See: https://www.microsoft.com/en-us/microsoft-365/roadmap?filters=&searchterms=63831
I was wondering how this new way of blocking Autoforwarding interacts with the ‘Remote Domains’ option. If the ATP setting is changed to ‘block’ on septemer 1st, is it still possible to Autoforward mail to trusted Remote Domains. Does anybody know?
Jeroen,
Good question, I don’t have an answer yet, but will get back on this with my experience after doing some further investigation
Regards,
Kenneth
Jeroen,
The Forwarding option is now available in the “Outbound spam filter policy” – Did some testing with the settings though, and effectively it doesn’t do anything yet.
Asked a question on the usage and whether it’s already working on the documentation page, since documentation is also very vague
https://docs.microsoft.com/en-us/microsoft-365/security/office-365-security/configure-the-outbound-spam-policy?view=o365-worldwide
Good article. If I have existing mail flow rules to forward to external, will it still be allowed?
Kenneth,
Microsoft has written an article about how the outbound spam filter policy settings work with other automatic email forwarding controls. You can read it at the bottom of this article: https://docs.microsoft.com/en-us/microsoft-365/security/office-365-security/external-email-forwarding?view=o365-worldwide
As said before we use Remote Domains to control Automatic Forwarding and to keep it working this way we had to change the Outbound SPAM filter policy to ‘ON’.
The setting ‘Automatic – System-controlled’ setting was disabeling the Autoforwarding in our tenant even to the remote domains that we allowed Autoforwarding to.
Thanks for the info.
Microsoft has changed some stuff. I think you have to update this Blog. If you want to keep using mailflow rules you have to also change the ‘Match sender address in message’ setting to ‘header or envelop’. In some cases the forwarded mail still will be forwarded even if you apply this setting.
For now a better way is to use a Custom Outbound spam filter policy and a custom rule for flows and power apps but unfortunately outbound policy’s aren’t very customizable (for example exclude on certain external domains).
Source:
https://techcommunity.microsoft.com/t5/exchange-team-blog/all-you-need-to-know-about-automatic-email-forwarding-in/ba-p/2074888
https://learn.microsoft.com/en-us/exchange/troubleshoot/email-delivery/autoforward-mail-exclusions-not-honored-transport-rule