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/
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
The is internal value should be set on the newly created remote domain to that Exchange Online treats the domain as internal for other service purposes.
PS C:\> Set-RemoteDomain -Identity "Consoto Remote Domain" -IsInternal:$TRUE
Using the get-remoteDomain command we can validate the autoForwarding and isInternal settings.
PS C:\> Get-RemoteDomain "Contoso Remote Domain" | fl autoForwardEnabled,isInternal
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.