SOLVED

Remote Domains, Automatic Forwarding, and ForwardingAddress VS ForwardingSMTPAddress

Steel Contributor

The many ways to block automatic email forwarding in Exchange Online 

Reducing or increasing information flow to another company 

Forward email from Office 365 to another email account 

Configure email forwarding for a mailbox Set-Mailbox 

 

Hello.  I'm asking a question that relates to the above articles.  I can't find it documented anywhere so far in my searches.  The "Reduce or increase...." link above is where I think it would be best documented, but really in all of those articles it should be covered.

 

I believe that ForwardingAddress is not subject to Remote Domain's AutoForwardEnabled setting, while ForwardingSMTPAddress is subject to Remote Domain's AutoForwardEnabled setting.  I've tested in Exchange Online as well as Exchange on-premises (hybrid deployment) where 2010/2016 coexist - the findings all point to this being correct (that ForwardingSMTPAddress will be subject to Remote Domains' AutoForwardEnabled True/False setting).

 

Can I please get a confirmation of this from anyone internal to Microsoft/Exchange Team?  Going back to the "Reduce or increase..." article - it states that when administrators enable forwarding on a recipient, that won't be subject to the Remote Domain settings.  But that's not entirely true, if in fact I'm correct that ForwardingSMTPAddresss IS subject to Remote Domain settings.  It would remain true that when administrators enable fowarding using FowardingAddress, that won't be subject to Remote Domain settings.

 

This is an important distinction that in my opinion should have been covered in all of the above linked articles.  I will open GitHub issues for the ones that I can, but I'll hold off until I get concrete confirmation.

3 Replies
best response confirmed by VI_Migration (Silver Contributor)
Solution
I had the realization of the explanation for the 'why' - ForwardingAddress takes only existing recipients (RecipientId) and so if the specified recipient happens to be a MailContact / MailUser with an ExternalEmailAddress, well that is no longer 'automatic forwarding' to the remote domain, the forwarding was to the internally existing recipient, so the external email address of that recipient is not part of the AutoForwardEnabled evaluation.

ForwardingSMTPAddress takes an SMTP (email) address, not a RecipientId, so suddenly this address is part of the evaluation.

The main thing that isn't documented is just that even if an administrator sets ForwardingSMTPAddress, it's still subject to Remote Domain AutoForwardEnabled.

I'll see if I can get this into the docs I linked earlier via GitHub issues (where possible).

That, and the fact that only admins can set the ForwardingAddress property on a mailbox. 

Thanks and good point. I think they do mention that in one of those articles I linked, but in its own context, not quite in relation to Remote Domain, and possibly not quite as concisely.

I'll make sure to point it out when suggesting edits.
1 best response

Accepted Solutions
best response confirmed by VI_Migration (Silver Contributor)
Solution
I had the realization of the explanation for the 'why' - ForwardingAddress takes only existing recipients (RecipientId) and so if the specified recipient happens to be a MailContact / MailUser with an ExternalEmailAddress, well that is no longer 'automatic forwarding' to the remote domain, the forwarding was to the internally existing recipient, so the external email address of that recipient is not part of the AutoForwardEnabled evaluation.

ForwardingSMTPAddress takes an SMTP (email) address, not a RecipientId, so suddenly this address is part of the evaluation.

The main thing that isn't documented is just that even if an administrator sets ForwardingSMTPAddress, it's still subject to Remote Domain AutoForwardEnabled.

I'll see if I can get this into the docs I linked earlier via GitHub issues (where possible).

View solution in original post