Office 365: Internal forwarding and remote domains…


In Office 365 I often encourage customers to control user forwarding through the user of remote domains.  You can find two of my blog posts on this topic here:

 

https://blogs.technet.microsoft.com/timmcmic/2015/06/08/exchange-and-office-365-mail-forwarding-2/

https://blogs.technet.microsoft.com/timmcmic/2015/04/19/office-365-determine-accounts-that-have-forwarding-enabled/

 

In a default installation a remote domain is defined in the service only for the * domain. 

 

PS C:\> Get-RemoteDomain

Name                           DomainName                                   AllowedOOFType
----                           ----------                                   --------------
Default                        *                                            External

 

The auto forwarding property can be adjusted to FALSE which prevents autoforwarding from succeeding even if configured by the end user.

 

PS C:\> Get-RemoteDomain | Select-Object AutoForwardEnabled

AutoForwardEnabled
------------------
             False

 

I recently had a customer present with an issue where forwarding was not working.  In this particular instance forwarding was not working when a mailbox in the service created a rule or was using forwarding SMTP address to a user that was not yet migrated.  The recipients mailbox was located on premises in the same organization.  Let us take a look at an example…

 

In Office 365 I have changed the forwarding SMTP address to be a proxy address of an object that has not yet been migrated.  The forwarding smtp address property is treated in the same manner as an inbox rule setting a forwarding or redirect address.  (For a details explanation of the different forwarding methods see my previously mentions posts).

 

Set-Mailbox Contact -ForwardingSmtpAddress journal@contoso.com

 

When the forwarding address as been set all emails directed to this mailbox should also be redirected to the forwarding address.

 

To test the forwarding using an external mailbox outside the organization I addressed an email to the mailbox where forwarding was enabled.  Using message tracing I traced the message and noted that the status now shows as FAILED.

 

PS C:\> Get-MessageTrace -RecipientAddress journal@contoso.com -SenderAddress timmcmic@microsoft.com

Received            Sender Address         Recipient Address       Subject Status
--------            --------------         -----------------       ------- ------
4/9/2018 2:41:08 PM timmcmic@microsoft.com journal@contoso.com     Test    Failed

 

Using get-messageTraceDetail we can review the full path of the message including any drops.

 

PS C:\> $trace=Get-MessageTrace -RecipientAddress journal@contoso.com -SenderAddress timmcmic@microsoft.com | Get-MessageTraceDetail
PS C:\> $trace

Date                   Event                Detail
----                   -----                ------
4/9/2018 2:41:11 PM    Journal              Message was journaled. Journal report was sent to journal@contoso.co...
4/9/2018 2:41:11 PM    Drop                 Reason: [{LED=250 2.1.5 RESOLVER.MSGTYPE.AF; handled AutoForward address...
4/9/2018 2:41:11 PM    Drop                 Reason: [{LED=250 2.1.5 RESOLVER.MSGTYPE.AF; handled AutoForward address...
4/9/2018 2:41:11 PM    Spam Diagnostics

 

In this instance we can see two drop events have occurred.  We can review the specific details of one of the drop events.

 

PS C:\> $trace[1].detail
Reason: [{LED=250 2.1.5 RESOLVER.MSGTYPE.AF; handled AutoForward addressed to external recipient};{MSG=};{FQDN=};{IP=};{LRT=}]

 

This is interesting – the message trace details seem to indicate that the message was dropped to an external recipient.  Why?

 

In this case the message is leaving the office 365 organization and therefore is considered external even though the message is destined to the on premises organization.  Due to transport seeing the forwarding recipient as external – and the remote domain * being the only domain defined and having auto forwarding disabled – the message is turfed.

 

How can we fix this?

 

We can fix this by defining a remote domain for the internal namespace.

 

PS C:\> New-RemoteDomain -DomainName contoso.com -Name "Contoso Remote Domain"

Name                           DomainName                                   AllowedOOFType
----                           ----------                                   --------------
Contoso Remote Domain          contoso.com                                  External

 

PS C:\> Get-RemoteDomain "Contoso Remote Domain" | fl autoForwardEnabled


AutoForwardEnabled : True

 

The entire process can be retested after allowing time for replication.  In this instance we will observe that the forwarded message is now delivered.

 

PS C:\> Get-MessageTrace -RecipientAddress journal@contoso.com -SenderAddress timmcmic@microsoft.com  | where{$_.status -like "Delivered"}

Received            Sender Address         Recipient Address       Subject Status
--------            --------------         -----------------       ------- ------
4/9/2018 3:06:30 PM timmcmic@microsoft.com journal@contoso.com     Test    Delivered

 

 

PS C:\> $trace=Get-MessageTrace -RecipientAddress journal@contoso.org -SenderAddress timmcmic@microsoft.com  | where{$_.status -like "Delivered"} | get-messageTraceDetail
PS C:\> $trace

Date                   Event                Detail
----                   -----                ------
4/9/2018 3:06:33 PM    Journal              Message was journaled. Journal report was sent to journal@contoso.co...
4/9/2018 3:06:33 PM    Journal              Message was journaled. Journal report was sent to journal@contoso.co...
4/9/2018 3:06:33 PM    Journal              Message was journaled. Journal report was sent to journal@contoso.co...
4/9/2018 3:06:34 PM    Send external        Message sent to mail.contoso.com at IPAddress using TLS1.2 w...
4/9/2018 3:06:33 PM    Spam Diagnostics

 

The new remote domain settings are being applied as expected.


Comments (0)

Skip to main content