One of the IT constants is that Microsoft will always change the way that things are done. As IT professionals, it falls on us to keep our settings and configurations up to date. In a previous article, I showed you how to prevent auto-forwarding of email off of your domain and how to make an exemption when there was a legitimate need for it. Recently, the transport rule that powered this stopped working for two of my clients. The rest have continued to work, but it’s probably just a matter of time before they stop working too. So, my techs are off making changes proactively right now.
As a refresher, we need to prevent auto-forwarding because it is a favorite tool of criminals to send your email to themselves so that they can learn about the company and plan their spear-phishing, man-in-the-middle, or ransomware attack. This lets them strike with specific knowledge about the company like where your most important files are located, who your customers are, who controls the money, etc. All very important information if you’re in the extortion business.
Threat management policy
The new method of blocking auto-forwarding is managed in threat management policies instead of Exchange transport rules. It is well-hidden with a relatively new default policy called the outbound spam filter policy.
This policy blocks the auto-forwarding of email by default. If you don’t need to make any exceptions, then you’re all set. There’s nothing more to do except remove any existing transport rule that you may have created to block auto-forwarding because it isn’t needed any longer now that blocking is simply a default setting.
Creating an exemption
However, if you need an email to be automatically forwarded from an internal to an external destination, then a custom policy must be created to allow any exceptions.
Most businesses won’t have many exceptions. It should be rare that anyone in business needs to forward all of their email automatically to Gmail. However, we do see some cases where there are specific needs for automatic email forwarding. Generally, you’ll find this to be the case when email needs to go out to a cloud-hosted SAAS app.
My testing has uncovered that you can’t allow auto-forwarding from a mailbox because it is the system that forwards the mail, not the email address of the mailbox itself.
However, you can set an exemption to a group or a shared mailbox. These entities forward the mail as themselves. So, that is the approach that we need to take. We can either create a group if there is a large number of exceptions to make or use a shared mailbox for single instances. There are plenty of places to learn how to create a distribution group or a shared mailbox, so I’ll skip those instructions and move right into creating a new outbound spam policy, which will contain our exception.
Create the custom outbound spam policy
Open the Security console and navigate to Policies. Then open the antispam (Microsoft 365) policy.
You will see four default policies. Notice that they are all “on” by default and cannot be turned off. Further, no exceptions are allowed in the default outbound spam filter policy, so a custom policy will be created. In the end, the policy that we are creating will be at the top and take precedent over the default policy.
Press the “create an outbound policy” button:
Give the policy a name of auto-forwarding exceptions or similar. Then expand the Notifications section and check both boxes.
Press the Add people button. Enter the email address of the person who will get notified when an auto-forward is attempted. This will most likely be the same person.
Why send alerts? Any auto-forward will be noteworthy because it will either be a spear-phishing attempt from a compromised account or a frustrated person trying to enable a legitimate use of the auto-forwarding feature. In both cases, the admin will need to assist in resolving the situation.
Expand the Automatic forwarding section, then set the choice to Forwarding is enabled. It’s a bit counterintuitive at first to make this choice, but our next step is to refine that choice limited only to the group or shared mailbox that requires the auto-forward feature.
Also, expand the “Applied to” section:
In the “Applied if…” option choose “Sender is” and enter the email address you want to exempt. Be sure to hit enter to get it to save into the field.
Finally, save the policy. I would recommend re-opening the policy to make sure that your settings stuck because as I was working through this, I noticed that occasionally they did not, and I had to enter them a second time. Probably, I was making too many changes for the portal to keep up with. But it’s best to check.
Now our policy exists, we need to move into the testing phase to ensure that it is working as expected. But before we do that, we need to disable any pre-existing transport rules that were blocking auto-forward.
Disable the now unused Exchange transport rule
Open the Exchange admin center. Navigate to Mail Flow, then Rules. Then disable an existing Block External auto-forwarding rule by unchecking it.
After testing is complete, return and delete the now unused transport rule for final clean up in the next maintenance cycle.
Test the policy
This policy should block external auto-forwarding for any user who doesn’t have an exception listed. We need to make sure that it blocks auto-forwarding that it is not listed in our exceptions and also that it allows the one that is in the exception list.
Test 1: Create a new shared mailbox. In the mail features settings, choose to forward all email to an external email address. Now send an email to that shared mailbox address and see if it is received at the external address. If it is blocked, then the rule is working correctly.
Test 2: Send an email to the addresses of any exceptions created in the policy we just created. If the forwarding address receives the email, then the rule is working correctly.
How to verify blocked email
Open the Exchange admin center. Navigate to Mail Flow, then Message trace. Here, I’m using the “new exchange admin center.” If you are reading this article close to the date it was written, you may be using the old Exchange admin center. You will then either create your query manually or flip to the new experience.
In Default queries, choose “All failed messages for the last 7 days.”
Narrow the time frame from seven days to just hours so you can easily see the results of the tests you ran. All other settings can remain at the default. Press the search button. A report will be generated that will show the failed message delivery.
In addition, an NDR should be returned to the sender.
The second test is to check for successful email delivery. You know how to do that one. The email arrives. If you don’t have access to the delivery location, you can use the default query, “Messages sent from my primary domain on the last day,” to view the successful delivery notices.
That completes our migration from transport rules to threat management policies. Never fear — when Microsoft makes another change, I’ll be here to write another article on the migration of this system to that one! I know change can be annoying, but change is what keeps us IT pros employed. Enjoy the process.
Featured image: Shutterstock