When routing emails in Exchange Hybrid mode, the following error may occur between Exchange on-prem and Microsoft 365 mailboxes when mails are sent from a local mailbox (or an external sender) to an M365 mailbox:
Remote Server returned '554 5.4.108 SMTPSEND.DNS.MxLoopback; DNS records for the next hop domain are configured in a loop -> DnsDomainIsInvalid: InfoMxLoopback'
This error can occur with mailboxes where the setting "Automatically update email addresses based on the email address policy for this recipient" has been deactivated. Here is an example:
For mailboxes where the address policy is not applied, the required remote routing address cannot be configured. Instead of the correct remote routing address, the default e-mail address of the mailbox may be configured as the remote routing address. Here is an example of such a case:
In this case, the redirection of mails to the Microsoft 365 mailbox does not work and the above error occurs. Here is a graphical representation of how email routing works between Exchange on-prem and Microsoft 365:
Explanation: Step 5 (redirecting the mail using the remote routing address) cannot be carried out because the default email address was entered here, resulting in a mail loop. The problem could be solved by configuring the correct remote routing address "alias@tenant.mail.onmicrosoft.com" for the mailbox in question:
The problem described above recently occurred during an Exchange migration to Microsoft 365, unfortunately I was unable to find out exactly how this error occurred. As you can see in the screenshot above, in this case the remote routing address is missing in the configured email addresses because the address policy was not applied. Normally, the mailbox cannot be moved to the cloud and the migration batch fails with the error "Proxy address not found". I therefore suspect that the wrong "Target Delivery Domain" was specified when the migration batch was created (i.e. not tenant.mail.onmicrosoft.com):
The domain "tenant.mail.onmicrosoft.com" should have been selected as the target delivery domain:
It is therefore more likely that no remote routing address is configured in the first place due to the missing update of the address policy and the migration batch does not move the mailbox to M365 in the first place (however, I was unable to verify this in my environment).
The following command can be used to check remote mailboxes for which updating has been switched off via the address policy:
Get-RemoteMailbox | where {$_.EmailAddressPolicyEnabled -eq $False} | select name,RemoteRoutingAddress,WindowsEmailAddress
Local mailboxes can be checked with the following command:
get-mailbox | where {$_.EmailAddressPolicyEnabled -eq $False} | select name,EmailAddresses
