Master & Cmd-R

Inbox rules: Inconsistent Forwarding

The issue: Inconsistent Forwarding Rules

I ran into an interesting issue on a recent migration: my client had a rather complicated forwarding scenario set up to manage a number of email subscriptions. Various folks around the (global) organization had signed up for these subscriptions, and they wanted to be able to distribute them throughout the company.

In order to facilitate this requirement, each subscription user had inbox rules set up to forward these subscriptions to a single mailbox, which then had around 50 inbox rules that were taking these emails and forwarding them on to a number of distribution groups, and then filing the email away in a folder – complicated, right?

First Rule: External Subscription to User:


Second Rule: Forward Subscription to Group:


Interestingly enough, this scenario worked in their old hosted environment, but once these mailboxes were migrated to Office 365 these rules started failing in a strange way: the rule would fire and move the message to the appropriate folder, but it wouldn’t actually forward the message on to the distribution group!

We tried recreating the rules, changing the wording of the rules, redirection vs. forwarding, etc. – nothing worked. Even weirder, if you tried to trigger the rule manually by sending an email from the source mailbox which met the rule criteria, the rule would trigger properly, making us think we actually had it solved this time. However, the next time the rule was activated automatically it would go back to the old behavior of filing but not forwarding.

So. Frustrating.

 

The Answer: “By Design”

Eventually I found the answer on the following forum post: Basically, as long as Exchange detects that the email was forwarded or redirected via a rule (mail headers include the field X-MS-Exchange-Inbox-Rules-Loop), it will not forward it a second time. This is by design in order to prevent unlimited loop forwarding.

This is also why we could trigger the rule manually by sending an email from the source mailbox – since the email was not forwarded it wouldn’t be caught by this behavior.

 

The Fix: Easier than you’d think

Thankfully, once we realized why this was happening, it was easy to resolve – simply remove the first forwarding rule (eliminating the loop potential), and instead replace it with a transport rule in Exchange Online.

For this rule, you can match the settings of the original inbox rule: If the sender is someone, do something. Depending on your requirements, you can choose to have it redirect the message, or simply Bcc the message to another user. Remember that if you choose redirection, the email will no longer go to the original user, so you might want to choose Bcc instead.


If you want to filter it better than this (the rule above might catch more emails than you want), simply click more options at the bottom of the rule window:


Once you have more options enabled, you can add as much details as you need to make sure you’re just catching the email you want, and not casting too wide a net:


Once you save your rule and activate it, make sure you disable or delete the original inbox rule so that you’re not generating duplicate emails, and then sit back and enjoy the magic!


About the Author:


2 Responses to “Inbox rules: Inconsistent Forwarding”

  1. Jason Selby

    January 4, 2018

    Hi Jeremy,
    This is happening in my organisation and i went onto https://testconnectivity.microsoft.com/ and added the message header. Under the header X-MS-Exchange-Inbox-Rules-Loop it has my email address as the value. Any ideas how i can stop this happening ?

    Reply
    • Jeremy Dahl

      January 4, 2018

      Hi Jason,
      I tested this out (as it’s been a while since I dealt with these forwarding issues), and the email address in the X-MS-Exchange-Inbox-Rules-Loop matches the person who initiated the forward via inbox rule. I’d assume that if your email address in the header field, then it’d be your mailbox that’s triggering the forward. Does that make sense, or am I missing something?

      Jeremy

      Reply

Leave a Reply