Exchange Server and Office 365 offer many different options for forwarding messages to different recipients. Some of these options exist for users and others are for administrators. Administrators can also control how forwarding is handled within the organization.
The forwarding options available to clients and administrators are described below. Each of these methods has both pros and cons when implemented:
In this post, I’m going to review each of these methods, the pros and cons, and the administrator controls in place for these options.
Forwarding rule within Outlook and Outlook Web App:
Users can create Inbox rules in both Outlook and Outlook Web App (OWA). One of the options is a rule to forward messages to a different recipient, which can be an internal or external recipient. In the example below, a rule has been created that forwards all messages received in the mailbox to an external recipient.
Client-side rules allow a great deal of flexibility when establishing forwarding. For example, say you want to forward emails to another internal or external recipient based on who sent the messages. The rules wizard allows this level of granularity. From an administrative standpoint client-side rules can also be helpful since they can be managed by the user. This obviates the need for administrators to be involved in the day-to-day management of these rules.
Client-side rules though are not immediately obvious to administrators. This may cause issues in environments that want to control where their data is stored and how it is transmitted. No specific permissions are required for users to create rules and there exists no method to limit this type of rule. Messages received by the destination mailbox look like forwarded messages; they have the same presentation as if the end-user selected the forward option on the message and specified the recipient.
Message tracking also confirms that the sender is the mailbox with the forwarding rule enabled and the recipient is the address specified on the forwarding rule.
This may cause issues in message handling, as subsequent replies would go to the mailbox the message was forwarded from rather than the original sender of the message.
When a message is forwarded by a client-side rule an additional header is added to the message: X-MS-Exchange-Organization-AutoForwarded. When the value of this header is set to TRUE this signifies the message was created by auto-forwarding.
Forwarding rule created by the administrator:
In Exchange 2010 and Exchange 2013, administrators have the New-InboxRule cmdlet, which allows them to create client-side rules within a mailbox. To create a forwarding rule that matches the previous rules wizard example you would run a command similar to the following:
PS C:\> New-InboxRule -Name ForwardSharon -Mailbox 2148 -ForwardTo:SHARON@domain.com
Name Enabled Priority RuleIdentity ---- ------- -------- ------------ ForwardSharon True 1 11219471045587107842
When using the Outlook client and viewing the rules in this mailbox, the administrator-created rule is present.
This rule has the same considerations and outcomes as a rule created by a user in Outlook; the only difference is that an administrator added it to the mailbox.
Forwarding using the forwardingSMTPAddress parameter of a mailbox:
Each mailbox has a parameter named forwardingSMTPAddress. This parameter is set by the administrator using Set-Mailbox. Any SMTP address can be specified in this parameter.
PS C:\> Set-Mailbox 2148 -ForwardingSmtpAddress firstname.lastname@example.org
PS C:\> Get-Mailbox 2148 | fl name,forwardingSMTPAddress,delivertomailboxandforward
Name : Tim McMichael ForwardingSmtpAddress : smtp:email@example.com DeliverToMailboxAndForward : False
When this type of forwarding is used, the user has no control and the forwarding process must be administratively managed. In addition, there is no granularity with this implementation; all messages for the mailbox are forwarded to the specified SMTP address. Because the field allows any SMTP address to be specified there is no need to create a mail-enabled object within your directory to establish this type of forwarding.
Messaging handling is also different with this type of forwarding. When the message arrives in the destination mailbox it appears as if it was sent directly to this mailbox. The TO field of the message reflects the original recipient, and the FROM field reflects the original sender. The message does not appear as forwarded.
Message tracking shows that the sender of the message is the original sender and the recipient is the forwarding address.
This allows the recipient to reply to the message and have the message sent directly to the original sender. It is important to understand this behavior in scenarios where compliance or journaling is used, as subsequent replies will bypass the original organization thereby bypassing journaling and compliance processes.
The message header also has appended the X-MS-Exchange-Organization-AutoForwarded header. When the value of this header is set to TRUE, in indicates that the message was created by auto-forwarding.
Forwarding using the forwardingAddress parameter of a mailbox:
The forwardingAddress parameter of a mailbox is also managed by an administrator using Set-Mailbox. Unlike forwardingSMTPAddress, the forwarding address parameter must be an object that is defined within the directory. Attempting to set this value to an object not within the directory returns an error.
PS C:\> Set-Mailbox 2148 -ForwardingAddress firstname.lastname@example.org Couldn't find object "email@example.com". Please make sure that it was spelled correctly or specify a different object. + CategoryInfo : NotSpecified: (:) [Set-Mailbox], ManagementObjectNotFoundException + FullyQualifiedErrorId : [Server=BN1PR06MB101,RequestId=3374349c-1924-43b2-bb21-d2243774a1d4,TimeStamp=7/20/2014 5:37:29 PM] [FailureCategory=Cmdlet-ManagementObjectNotFoundException] F2A1EE0E,Microsoft.Exchange.Management.Reci pientTasks.SetMailbox + PSComputerName : pod51043psh.outlook.com
The forwarding address parameter can be another mailbox-enabled object, a mail-enabled user, or a mail contact. In this example, I have created a mail contact for my external recipient.
PS C:\> New-MailContact -Name Sharon -ExternalEmailAddress firstname.lastname@example.org
Name Alias RecipientType ---- ----- ------------- Sharon Sharon MailContact
I then enabled the forwardingAddress parameter on the mail contact.
PS C:\> Set-Mailbox 2148 -ForwardingAddress Sharon
The setting was validated with Get-Mailbox.
PS C:\> Get-Mailbox 2148 | fl name,forwardingAddress,delivertomailboxandforward
Name : Tim McMichael ForwardingAddress : Sharon DeliverToMailboxAndForward : False
Similar to the fowardingSMTPAdderss parameter the forwardingAddress parameter must be managed by the administrator. The end-user has no control over this specific parameter and the end-user will not know that forwarding is enabled. Unlike client rules, the use of the forwardingAddress parameter applies to all messages received to the destination mailbox; there is no way to allow this function to work on specific messages.
Messaging handling is also similar to using the fowardingSMTPAddress parameter. The message arrives in the destination mailbox as if it was addressed directly to that mailbox. The TO address shows the original recipient and the FROM address shows the original sender.
This allows the forwarded recipient to reply to the message and have it returned directly to the original sender. Messaging tracking also shows that the sender is the original sender and the recipient is the address configured for forwarding.
It is important to understand this behavior in scenarios where compliance or journaling is used as subsequent replies will bypass the original organization thereby bypassing journaling and compliance processes.
In this scenario the X-MS-Exchange-Organization-AutoForwarded header is not stamped on the message.
Autoforwarding and delivertoandforward:
Each mailbox also has a parameter called deliverToAndForward. This allows the administrator to specify if the message should also be delivered to the mailbox where forwarding is enabled. This setting applies ONLY to forwarding that is configured by using the forwardingAddress or forwardingSMTPAddress parameters. Client-side rules are unaware of this setting.
Autoforwarding and remoteDomains:
Within Exchange and Office 365, administrators can create remote domains. By default, every tenant leverages the ‘*’ domain. When a specific remote domain does not exist, the ‘*’ remote domain setting are applied to the message.
A property of a remote domain is autoForwardEnabled property. This allows administrators to define if auto-forwarding is allowed on messages destined to the domain specified.
PS C:\> Get-RemoteDomain | fl name,domainname,autoForwardEnabled
Name : Default DomainName : * AutoForwardEnabled : True
By default auto-forwarding is allowed to all domains. Administrators can use the remote domain settings to control how forwarding outside their organization is handled. Please note: this does not change how forwarding is handled within the organization.
In this example, I am creating a specific remote domain rule and have disabled auto-forwarding.
PS C:\> New-RemoteDomain -Name ExternalDomain -DomainName domain.com
Name DomainName AllowedOOFType ---- ---------- -------------- ExternalDomain domain.com External
PS C:\> Set-RemoteDomain -Identity ExternalDomain -AutoForwardEnabled:$FALSE
The settings can be verified with get-remoteDomain:
PS C:\> Get-RemoteDomain ExternalDomain | fl domainname,autoforwardenabled
DomainName : domain.com AutoForwardEnabled : False
To test this feature I set the forwardingAddress on the mailbox to a recipient in the domain.com domain. When a message is addressed to the mailbox where forwarding is enabled, it never makes it to the destination. The same behavior would occur if a client-side forwarding rule is used.
When a client-side rule or the forwardingSMTPAddress is used, the mail flow process stamps the X-MS-Exchange-Organization-AutoForwarded to TRUE. This header is not viewable on a message as the transport header firewall removes it. When the message is processed by the Transport service, if the remote domain specifically blocks auto-forwarding and the auto-forward header is present and set to TRUE, the message is turfed, and no NDR is generated. If no form of journaling is present and the deliverToAndForward setting of the mailbox is set to FALSE, the message is effectively lost.
When looking at message tracking we can see that the message failed to reach its destination. The message delivery status is NONE and no send events are noted.
Using the same remote domain, the mailbox is configured with a forwardingAddress instead. The mail contact used as the forwardingAddress object has an external email address in domain.com. When sending a message to the mailbox where forwarding is enabled, the mail is successfully delivered. This is also confirmed by message tracking.
In this example, the transport process does not use the X-MS-Exchange-Organization-AutoForwarded but instead adds the forwarded address as a recipient during a different stage of message processing. As the message traverses the transport stack it is not detected as a forwarded message and is therefore allowed to arrive at desired recipient.
Utilizing the forwardingAddress scenario is an excellent way for an administrator to bypass forwarding settings on remote domains while controlling when message forwarding is allowed.
We routinely receive requests on how to enable granular message forwarding or only allow specific users to use auto-forwarding capabilities. Unfortunately, with the forwarding settings being tied to remote domains it is very difficult to enable forwarding for only a subset of users or where granular forwarding on messages attributes is desired. To allow clients to create auto-forwarding rules would mean the remote domain would have to allow auto-forwarding for everyone. Administrators can attempt to discover and remove auto-forwarding rules using Get-InboxRule.
In my experience, in most scenarios forwarding is disallowed on remote domains and enabling of forwarding is restricted to administrator configuration using the forwardingAddress parameter.
Always interesting Tim
I actually got my hands dirty with New-InboxRule recently to see what automatic forwarding options we have in our Office 365 tenant (our users are forced into OWA Light due to an unsupported browser). The request was to figure out a way that a Manager can set
his/her email to be automatically forwarded to their Assistant Manager when they are out of the office. Due to OWA Light they can't create Inbox Rules themselves, but I recalled that Inbox Rules could be controlled via PowerShell. Perhaps setting up a web
form that would allow the Manager to enter the necessary information we can create a rule that would be valid for a specific period of time.
Looking deeper I found that with New-InboxRule I can create a rule with "RedirectTo", which seems to act like setting forwarding on the Mailbox (Set-Mailbox -ForwardingAddress), as it bypasses the intended recipient completely. But setting "ForwardTo" would
act like setting forwarding on the Mailbox along with "DeliverToMailboxAndForward" being enabled, allowing the message to exist in the intended recipient's mailbox along with the Assistant.
Are those fair comparisons?
Ultimately it looks like we can create Inbox Rules for the users and have a nightly script run that will remove any Rules that exist after the "ReceivedBeforeDate" has expired.
Oh, and another great blog! :)
Thanks for the comment. Hopefully you'll get to a supported browser soon where you can enjoy the rich OWA experience.
The web form is always challenging as it has to play well in the background with RBAC and remote powershell (and challenging might be relative to your experience with such things).
I did not test the redirect rule in this scenario - stuck to just straight forwarding.
If the assistant is supposed to just get all the mail - i'd personally stick with the forwardingAddress and specify the assistant manager. Combine this with deliver to and forward and I think that's a more elegant solution then the rule.
I have a question regarding using forwarding/redirect via an Inbox Rule.
I can see the inclusion in the HEADER :
Yet even though the forward is done from one mailbox to another on the same Office 365 Tenant (same domain) it does an SPF check & subsequent fail - when the Original mail sender -has a different domain.
Thank you for sharing this experience! very interesting! I didn't know your blog!
I think I need the same thing as @Brgrant...
Is exist any way for changing "mail from" in the forwarded email? When you forward, the recipient systemMailbox receive a SMTP conversation with a the original sender in "Mail from:". Ideally, the mail from should be "email@example.com", the "forwarder", and
the "reply to" should be the original sender..
What do you think about it?