All you need to know about automatic email forwarding in Exchange Online
Published Jan 19 2021 08:50 AM 175K Views

Update: Starting November 2022, protection.microsoft.com URL does not work anymore. Please go to security.microsoft.com instead for the AntiSpam feature mentioned in this post.

We realize that many customers have genuine business requirements to configure automatic email forwarding. On the other hand, email forwarding may lead to data leakage. For example, if we have a compromised account, the attacker might create a forwarding rule for a particular mailbox, and the user might be unaware that their mail is being forwarded. This is a very common tactic used when accounts are compromised.

It is therefore important for administrators to know all mailboxes that have forwarding enabled and where the mail is been forwarded to. We have various insights and alerts that help administrators monitor such activities, but prevention is always better than the cure. In this blog post, we thought to revisit (and update) various auto forward controls, how they work together and how they can help you achieve a requirement of allowing automatic forwarding for users who really need this feature.

Various ways to set up forwarding

Before discussing how to control automatic forwarding, let’s review a few different ways in which automatic forwarding can be setup:

  • A forwarding rule can be setup within the Rules wizard in Outlook on the desktop. User can set this Automatic forwarding from Outlook > File > Manage Rules and Alerts. Using Outlook on the web, this can be done using Inbox rules. Forwarding rule configured on a public folder (using PF assistant) works similarly to Inbox rule.
  • User can also configure automatic forwarding while creating Out of Office rule in Outlook on the desktop. File > Automatic Replies (Out of Office) > Rules > Add Rule > Forward To option. Note that although OOF replies are sent only once per sender, this rule will forward emails for every message as long as OOF is enabled.
  • Using Outlook on the web (OWA) the user can also set the ForwardingSmtpAddress parameter on the mailbox. This option is available via Settings > Mail > Forwarding.
  • Users can also set auto forward using Power Automate (used to be called Microsoft Flow).
  • Administrators can configure forwarding from the properties of the mailbox from Exchange Admin Center. This option is available on mailbox properties under Email forwarding tab in the EAC. Configuring internal automatic forwarding from the properties of the mailbox will populate the ForwardingAddress parameter on the mailbox. But configuring external automatic forwarding from the properties of the mailbox will populate the ForwardingSmtpAddress parameter on the mailbox.
  • Administrators can also configure forwarding from Microsoft 365 Admin Center. Configuring forwarding from Microsoft 365 Admin Center will set the ForwardingSmtpAddress parameter on the mailbox (but will show if ForwardingAddress is populated).

Controlling automatic forwarding

Administrators have several methods to prevent and regulate automatic forwarding of emails outside the organization:

External email forward control using Outbound spam filter policy

Recently released, this feature is available in (updated) Microsoft 365 Defender portal under Outbound spam filter policy (to get the exact portal page, go here). As you see in the following screenshot, there are three possible options. The default configuration is “Automatic system-controlled.” Other options are Off and On. “Off” means auto forward is disabled and “On” means auto forward is enabled.

ForwardingRevisited01.jpg

Note: If you see the option is set as “Automatic system-controlled”, most probably you have not configured the setting at all. For tenants where the setting is left at “Automatic system-controlled”, as we continue to move the service toward being more secure by default, this setting will be enforced and behave as “Off” (forwarding disabled). This enforcement process has started in phases and very soon, all tenants will get this setting enforced. Therefore, “Automatic system-controlled” will behave as “Off” and automatic forwarding will not work. Our recommendation is that all customers should configure the policy as appropriate for their organization and enable external auto forwarding only for the users who really need it (by leaving the default policy in disabled state, creating a different policy that allows forwarding and then assigning it to specific mailboxes only). If for your tenant, “Automatic system-controlled” still does not block email forwarding, you should make this change as soon as possible (as soon, it will).

When external automatic forwarding is blocked by Outbound spam filter policy, a NDR is sent back to the original sender and not the mailbox that is forwarding the message. The NDR will contain the following diagnostic information:

Remote Server returned '550 5.7.520 Access denied, Your organization does not allow external forwarding. Please contact your administrator for further assistance. AS(7550)'

Advantages of this method:

  • It blocks all types of auto forwarding including ForwardingAddress and ForwardingSmtpAddress mailbox parameters.
  • Blocks redirect rules configured using Outlook.
  • Easier to configure and administrators can selectively allow/block external auto forwarding for a few or all mailboxes.

Disadvantages of this method:

  • Forwarding using Power Automate (Flow) is not covered as of now. To block external forwarding which is setup using Power Automate, follow the steps mentioned in our Email exfiltration controls for connectors article.

Block automatic forwarding using Remote Domains

This option is available under the Mail flow tab in the new Exchange Admin Center preview:

ForwardingRevisited02.jpg

ForwardingRevisited03.jpg

Advantages of this method:

  • This setting can block auto forward rules configured using Outlook inbox rules as well as Outlook on the web options. (ForwardingSmtpAddress parameter). It can also block external automatic forward set from the properties of the mailbox from Exchange Admin Center.

Disadvantages of this method:

  • This blocks auto forward to the specific remote domain. There is no granular control – cannot allow forwarding for certain users, and block for others.
  • The user is not notified that their auto forwarded message is dropped, no rejection (NDR) is sent.

Block auto forward using a transport rule

You can create a transport rule from Exchange Admin Center > Mail Flow > Rules to block automatic forward:

ForwardingRevisited04.jpg

Advantages of this method:

  • Allows granular control on conditions and actions.
  • Admins have the option to send rejection message (NDR).

Disadvantages of this method:

  • Matches auto forward messages based on message class (IPM.note.forward). The Outlook web app forwarding (ForwardingSmtpAddress) or forwarding set by the admins on the properties of the mailbox (ForwardingAddress) have normal message class (IPM.Note), so transport rules won’t block them.
  • Difficult to manage at times when too many transport rules are configured.

Hiding auto forward options using Role Based Access Control (RBAC) RBAC

While this is not really a method of blocking forwarding, it is related in a way that it can help remove forwarding options from users if they are using Outlook on the web.

Advantages of this method:

  • In OWA, users simply do not see the option to setup forwarding in their mail options

Disadvantages of this method:

  • Does not remove the option in Outlook desktop.
  • Any forwarding that was already configured will continue to work.

Overview

If you want to quickly compare various methods, you can refer to the following table:

Automatic forwarding option

Remote domain

Transport rule

Outbound spam filter policy

Block Outlook forwarding using inbox rules 

Yes

Yes

Yes

Block Outlook forwarding configured using OOF rule 

Yes

Yes

Yes

Block OWA forwarding setting (ForwardingSmtpAddress)

Yes

No

Yes

Block external forwarding set by the admin using EAC (ForwardingSMTPAddress)

Yes

No

Yes

Block forwarding using Power Automate / Flow

No

Yes

No

Does the sender get NDR when auto forward is blocked?

No

Yes

Yes

Customization and granular control

No

Yes

Yes

What happens if auto forward is controlled in multiple places mentioned above?

One question we encounter frequently is, how all these techniques work together? What if auto forward is blocked in one of the above methods but allowed in another? For example, auto forward is blocked by a remote domain setting or a transport rule but allowed in Outbound spam filter policy; what happens? The answer to that is that a restriction in one place will restrict auto forward for all.

For example:

  • Automatic forwarding is On (allowed) in the Outbound spam filter policy.
  • Automatic forwarding is disabled for the remote domain.

Will the automatically forwarded message be blocked by the remote domain? Yes, remote domain would block automatic forward as would an Exchange transport rule.

Depending on what you want to achieve, you can use combination of above features. There’s no one size fits all option. You can implement all four options if you really want, depending on your requirement. For example, the remote domain option controls the recipient domain and comes handy if you want to restrict auto forwarding for all except a few external domains. Outbound spam filter policies on the other hand can control the sender. If you want to allow external auto forwarding for only a few mailboxes (users with genuine business requirements to configure automatic forwarding) and block external auto forwarding for everyone else, Outbound spam filter policy is most preferred. Or you can use combination of these two options if you want to allow auto forwarding only for few mailboxes and to only a few external domains. Here is another example which is slightly more complex:

Let’s say you have the following requirements:

  • By default, automatic forwarding should be blocked.
  • Automatic forwarding to an external domain contoso.com should be allowed for all users.
  • Allow users Jack and Jill to also be able to forward to northwindtraders.com, but no one else.

There are multiple methods to achieve this, the following is one such solution:

  • Keep the new external forwarding control under Outbound spam filter policy setting to “On”.
  • Disable automatic forward for default * domain in remote domain setting.
  • Create a new remote domain for contoso.com and northwindtraders.com and allow automatic forward for these remote domains.
  • Create a transport rule to block auto forward from all to northwindtraders.com but put an exception for users Jack and Jill.
  • As transport rule will not block forwarding set using Outlook on the web (ForwardingSMTPAddress parameter) you can use RBAC rule to stop users from creating auto forward setting from OWA.

But wait, there is more!

To protect you further from attackers if a user mailbox is compromised (and for whom external automatic forward could be enabled without their knowledge), a new Email Forward Alert Policy has been released recently which is available under Alert Policies of our Security & Compliance portal. It is called “Suspicious Email Forwarding Activity.” This new alert will track all "forwarding scenarios" and detects when a user has automated the sending of messages external to the organization​. Once we find any suspicious activity, we will alert the tenant administrator once per day as long as the user continues to forward to that external recipient​. This policy has a Medium severity setting. Although it is rare, an alert generated by this policy may be an anomaly. Administrators should always check to confirm whether the user account is compromised. A screenshot of the policy:

ForwardingRevisited05.jpg

A sample alert sent to the administrator:

ForwardingRevisited06.jpg

That’s it for now! Hope you find this helpful. I also want to take a moment to thank Mike Brown, Nino Bilic for reviewing this.

Arindam Thokder

82 Comments
Copper Contributor

Good to see thi new feature implementation with New Exchange Admin center 

Looking for more updates in future. Keep up the hard work :thumbs_up:

Copper Contributor

Good one Arindam

I wonder if this change in any way part of a Message Center announcement?

 

Steel Contributor

There is a 6th way to set up automatic forwarding which is currently well hidden and cannot be interrogated via the Exchange Admin Center or PowerShell,

 

In the Outlook client, go to File / Automatic Replies (Out of Office) / Rules... / Add Rule... / Forward / To

This is actually a security hole as I believe if a hacker sets up forwarding here, it does not trigger the normal 'mail forwarding' alerts'.

 

Please could you mention this in the first few bullet points and document whether it is blocked by the above methods (Remote Domain / Transport Rule / Outbound spam filter policy)?

 

There is also an outstanding UserVoice request to allow administrators to audit this setting via Exchange Admin Center and PowerShell. At present this seems to be a security blind spot in Office 365 as an administrator cannot check the status of this setting.

 

Any attention that can be drawn to this outstanding issue would be appreciated.

 

https://social.technet.microsoft.com/Forums/msonline/en-US/642d571f-2f1a-4fc4-bb84-5dd86df7dee6/outl...

 

https://github.com/MicrosoftDocs/office-docs-powershell/issues/1708

 

https://office365.uservoice.com/forums/273493-office-365-admin/suggestions/35353714-use-powershell-t...

 

Microsoft

@Thomas Stensitzki - I am assuming that you are referring to the Outbound spam filter policy change? If so - message center posts on that started back in July 2020...

Thank you @Nino Bilic. It would be helpful if the corresponding message center ID or a roadmap ID would be linked in this or future posts.

Regarding the different ways of blocking/disallowing external forwarding, it would be interesting, if any or all of these options are analyzed by security and compliance score.

Microsoft

@ChrisAtMaf Thanks for pointing that out. We are adding about forwarding configured through OOF template and the expected behavior of various blocking method when Automatic Forward is configured from OOF template. 

 

Microsoft

@ChrisAtMaf - we have now added this; thanks! To be clear - this only works while OOF is turned on (and that is definitely visible to end users). Good call!

Steel Contributor

The table above that says Transport rule blocks Outlook Rules is incomplete because you can create an Outlook Rule that uses the "Redirect" message and that will bypass the transport rule block. In our testing, only the Remote Domain option will block the Outlook Rule that uses the Redirect method. This redirect method is also not blocked with the new “Automatic system-controlled” control.

Microsoft

@Joe Stocker - Hi Joe, this blog is mainly for Automatic Forward Rule, that's why we mentioned "Block Outlook forwarding using inbox rules" in the table to make it clear. By the way "Redirect rule" can be blocked by the  Outbound spam filter policy as well based on my earlier testing.

Steel Contributor

@Nino Bilic Hey, appreciate that - good to know the article is comprehensive. Re user visibility, that's right - but if an account gets hacked in the mean time, there's currently no visibility for an administrator - nor can it be administratively disabled without resetting the user's password as far as I am aware. I don't think the Security & Compliance 'Forwarding report' (https://protection.office.com/reportv2?id=MailFlowForwarding&pivot=Name), for example, reports it. For something that allows hackers to exfiltrate as much mailbox data as they like once they've hacked the account - that's a big blind spot :)

Microsoft

@ChrisAtMaf  - actually, administrator CAN modify user's OOF message without resetting the user password. It's been a few years that the functionality has been in Microsoft 365 Admin Center (Users > Active users > click on the user that has an Exchange license > Mail tab > Automatic replies).

That being said - you first have to know that this is turned on and I need to check if the Forwarding report calls this out (I would be surprised if it does not, but I will check).

Also note that users themselves will get a notification when they launch a client that their OOF is turned on. Still does not address what you mean exactly, but it is something that users will be aware of, if enabled.

Copper Contributor

What are the options for Exchange Server 2016/2019 on premises? 

 

Microsoft

@IT-Engineer - apart from forward control using Outbound spam filter policy, other options are available to regulate External Autoforwarding for Exchange Server 2016/2019 on premises

Microsoft

@ChrisAtMaf - Also, the Security & Compliance 'Forwarding report' (https://protection.office.com/reportv2?id=MailFlowForwarding&pivot=Name), does show the Forwarding configured from OOF templet. 

Copper Contributor

@Arindam Thokder 

Hiding Auto-Forward options using Role-Based Access Control (RBAC) RBAC only works for normal user accounts.

 

The user who holds elevated permission in Exchange Online can still use the Forwarding option in OWA. I am referring to a scenario where Helpdesk engineers have been given some elevated permission to do basic Exchange management work.

 

I have tested this with Multiple M365 Tenant, Microsoft support also confirms the same.

Can you confirm this ?

Microsoft

@Mukesh Rawat - This is expected behavior, the RBAC role is assigned to the user. The Helpdesk users using elevated permission does not have the RBAC role assigned. For that you need to create a new role and assign to the helpdesk. 

Steel Contributor

Once you have blocked forwarding for "all tenants", will you actually remove the choice "Automatic system-controlled" and just leave On or Off there?

Microsoft

@Jonas Back - That's the plan. However it will take some time.

Steel Contributor

@Arindam Thokder Awesome that you confirm this - helps me better communicate the plan to all my M365 customers.

Copper Contributor

Hi,

 

Could someone please share all Message Center ID's pertaining to this change?

Steel Contributor

@hmalhotra007MC221113, MC221119, MC223421

Brass Contributor

I've disabled auto-forwarding as of today, but the NDR part confuses me:

 

  • A NDR is sent back to the mailbox that configured auto forwarding to external user if the policy is set to block automatic forwarding for that mailbox. The NDR will contain the following diagnostic information:

Remote Server returned '550 5.7.520 Access denied, Your organization does not allow external forwarding. Please contact your administrator for further assistance. AS(7550)'

 

The NDR isn't send to the user that has configured the forwarding. It's send to the original e-mail sender.. And that sender is confused, because he hasn't setup any forwarding. 

 

To be clear:

 

Person B has forwarding to external enabled.

 

Person A sends mail to Person B --> Person A gets the NDR, that's meant for Person B (with the rule). 

 

 

 

Microsoft

@molislaegers - There are few scenarios if the sender is External and with certain type of forwarding, the NDR is sent to the Actual Sender (Person A in your case), we are working on this to make the behavior uniform.  

 

Brass Contributor

@Arindam Thokder Sender (Person A) and Forwarder (Person B) where internal. The e-mail was send to a distributiongroup where Person B was member off. Forwarding was done by SMTPforwarding.

 

I've now removed all forwarding rules with Powershell, to avoid confusion:

Get-Mailbox -ResultSize Unlimited | Where {($_.ForwardingAddress –ne $Null) –or ($_.ForwardingsmtpAddress –ne $Null)} | Set-Mailbox -ForwardingAddress $null -ForwardingSmtpAddress $null

 

 

Copper Contributor

Does the 'Off' setting prevent forwarding for Shared Mailboxes?  That is an admin-controlled setting and isn't available to users.

 

Thank you

Microsoft

@Nobody2020 - Do you mean forwarding set from the properties of the shared mailbox from EAC? In that case "off" would prevent external automatic forwarding

Brass Contributor

You can find all mailboxes with forwarding setup with this powershell command:

 

Get-Mailbox -ResultSize Unlimited | Where {($_.ForwardingAddress -ne $Null) -or ($_.ForwardingsmtpAddress -ne $Null)} | Select Name, ForwardingAddress,ForwardingsmtpAddress, DeliverToMailboxAndForward

Microsoft

@Nobody2020 - You can get the details of all shared mailboxes from PowerShell and filter for forwardingaddress parameter. That will tell you all the Sharedmailboxes where this type of forwarding is set. 

Copper Contributor

Thanks molislaegers and Arindam!

Copper Contributor

I can't find "Settings > Mail > Forwarding" in Outlook on the web for Exchange Server 2019.

Though Help menu from there leads to Outlook on the web for Exchange Server 2016 page where I can find instructions mentioning this option. The same on the official site: https://support.microsoft.com/en-us/office/turn-on-automatic-forwarding-in-outlook-on-the-web-7f2670...

Is this functionality broken in Outlook on the web for Exchange Server 2019 or the documentation is wrong?

Microsoft

@aliverru - I think the option is not there for On-Premises for quite some time, even with Exchange 2016 and Exchange 2013. Could you please confirm that you are able to see the option with Exchange 2016 Outlook on the web ? I might need to change the article which you mentioned in your comment. 

Copper Contributor
Hi Arindam! Thank you for a quick reply. Unfortunately, we only have Exchange 2019 here. I could not find elsewhere any confirmation that this option exists in Exchange 2019. So it seems to start/stop auto forwarding using ForwardingSmtpAddress parameter for on-premises server is using powershell.
Microsoft

@aliverru - that seems to be the case for On-premises versions. But thanks for letting us know, I will check if this is expected. If it is, I will update the article. 

Copper Contributor

I was going about my business of replacing mailbox forwarding with Transport rules that do the same thing when I ran into an issue.  I could not create a transport rule to Forward mail from one mailbox to another.  It throws this error:

“SentTo predicate does not allow distribution groups. 'mailbox@domain.com'.”

 

The strange thing is that that neither item are a distribution group.  One is a Shared mailbox, and the other is a user mailbox.  I looked up the error message, and they all say 'you cant use transport rules to forward mail to a distro group, but that can't be the problem since neither are a distro group.  Any ideas?

Microsoft

@Nobody2020 - There is some active investigation going on for this issue. I would suggest you to open a support ticket so that we can involve the right team. 

Copper Contributor

Hello,

I followed the guide for the transport rule and it worked in our tests but now that it is active the exception group doesn't work anymore.

Do you have any tips why it doesn't work?

 

Copper Contributor

Hi,

We have a hybrid envionment and our users are on EOL but have some shared mailboxes onprem which we cannot migrate just yet.

When a EOL user creates a outlook forwarding rule to a shared mailbox onprem it just drops the message no NDR, i have already created a outbound policy to allow auto forwarding but does not work. 

Example if a message arrives from an external domain an outlook rule is inplace to forward that to the shared mailbox onpremis, the error generated when tracking the message is below

eason: [{LED=250 2.1.5 RESOLVER.MSGTYPE.AF; handled AutoForward addressed to external recipient};{MSG=};{FQDN=};{IP=};{LRT=}]

Not sure why this is being treated as external as the mail has already arrived in the users mailbox and should just forward to the shared mailbox which is part of the same domain.

Is this supported or any work arounds?, we have 100 shared mailboxes which are impacted

Microsoft

@vin0109 - looks like its dropped because of the remote domain setting

Copper Contributor

Hello all, I am trying to get my NDR's to forward into a CRM but it appears the only way to send the NDR's is manually. I have tried using a redirect rule, forward rule and forward as attachment. Any ideas how I can make this an automated process? Every rule applies except the one that is support to forward it to the CRM. So it moves folders, marks as priority and filters properly. 

Copper Contributor

Crklundt, I believe a transport rule needs to be created.

Microsoft

@crklundt - This is expected behavior. Transport rule does not apply on NDR and other system messages. 

Copper Contributor

@Arindam Thokder @Nobody2020 

 

We did see that the transport rule didn't work, but my question is this: Is there another way we can have these messages automatically forwarded into our CRM? We have a requirement for certain NDR's to be followed up on and we are trying to make this an automated process rather than having someone manually go into the inbox and forward each of these emails. 

Copper Contributor

@crklundt, if the transport rule didn't work, perhaps it needs to be moved further up the list of rules.  If that doesn't help, I would recommend contacting support.  That's extremely strange!

Copper Contributor

Following the new changes with the Outbound Spam Policies and blocking external forwarding by default I have had to change the way our emails are forwarded to our external customer services email platform hosted by a third party.

 

I have set up forwarding on the email addresses via the Exchange Admin Center on the Mail flow settings for the individual accounts. However, we are not getting all the spam emails appearing on our customer service platform.

 

My question is, does forwarding an email address in this way bypass the spam filtering?

Copper Contributor

Hello everyone,

my emails are automatically forwarded to another (non Microsoft) email address. I set this up years ago.
I no longer want this forwarding and am desperately trying to turn it off, but don't know where.

 

Under "Gear > Show all Outlook settings > Email > Forwarding" no forwardings are listed.
Moreover, I have not set any rules.

 

Any hints & advice would be greatly appreciated.

Best regards

Katrin

Copper Contributor

Hello Everyone,

 

I have used the Anit-spam auto-forwarding policy to disable the auto-forwarding which is working as expected but the only problem is if anyone whose forwarding is not enabled sending email to the person whose forwarding is enabled getting NDR don't know why.

 

Why the sender is getting informed about the recipient auto-forwarding is disabled. The emails are getting delivered to the recipient (whose forwarding is enabled) but getting NDR at the same time why?????????????

 

It means when any internal or external user sending email to the person whose auto-forwarding is enabled getting NDR. (Confused)

 

Tried under my test tenant but it's the same behavior which actually Microsoft needs to look into.

 

Why is the SENDER is informed that the RECEIPIENT is not allowed to forward their e-mails?

 

 

Microsoft

Hi everyone,

 

Just found out there are different behaviors regarding to the NDR if the auto-forwarding is disabled via outbound connector (auto-forwarding in remote domain setting enabled).

 

So for user who enabled auto-forwarding with "saving a copy", NDR will successfully deliver to this user:

 

Nick_Gong_0-1634879917095.png

Nick_Gong_1-1634879937068.png

Nick_Gong_2-1634879955230.png

 

But if user enabled auto-forwarding without "saving a copy", no NDR will sent to this user. The original sender will not get NDR either:

Nick_Gong_3-1634880036666.png

Nick_Gong_4-1634880057061.png

Nick_Gong_5-1634880074420.png

 

 

So the initial issue is: user who set auto-forwarding without saving a copy will not know the forwarding failed, and either will the user have any access to the original email since there's no copy saved.

 

Is this the normal behavior?

 

Thanks!

 

 

 

Steel Contributor

@Nick_Gong can't answer if this is normal behavior by good that you bring this to attention since I've noticed something like this to. Let's see if @The_Exchange_Team can comment?

Microsoft
@Nick_Gong  - This is expected behavior. The NDR would get auto-forwarded too and would fail because of the policy block. 

 

Co-Authors
Version history
Last update:
‎Dec 08 2023 12:31 PM
Updated by: