Hop Count Exceeded - Possible Mail Loop
Hi Everyone,
I came across a strange issue recently, and wanted to throw it out there in case anyone runs by this in O365 land.
Background
An organization was running in a Hybrid Coexistence with O365 Wave 15. An Exchange 2007 user was migrated to the cloud. Later, the mailbox was moved back on-prem for some reason. Unfortunately, I don’t have the details to provide around the mailbox moves. Anyway, the user then reported that O365 users were unable to email the newly migrated on premise Exchange 2007 mailbox. External users were able to send mail to this mailbox without issue.
The NDR
Diagnostic information for administrators:
Generating server: XXXXXXXXXX.xxxxxxxxx.prod.outlook.com
xxxxxx@xxxxxxx.xxxx.onmicrosoft.com
XXXXXXXXXX.mail.protection.outlook.com
Remote Server returned '554 5.4.6 Hop count exceeded - possible mail loop'
Initial Thoughts and Troubleshooting
If you search for this NDR on the internet, you’ll come across several articles which point in the direction of duplicate domain configurations, SPF records, accepted domains, connector configuration etc. In our case these did not seem to apply after a quick review. It was apparent these potential causes did not apply to our case, as this was the only person impacted by this issue post migration back the on premise environment. So now what…
Let’s look at the NDR a little closer. The generating server is in O365 so no need to check anything on premise just yet. It appears that the email address being sent to, is resolving to an address with @domain.onmicrosoft.com, when it should be sending to and address of @domain.com. Once that was identified, I review the user account and mail contact in O365 to see if there is any correlation to this unexpected name resolution. Sure enough, the mail contact was configured with an external email address of @domain.onmicrsoft.com. There’s our problem
Issue identified, time to wrap it up? Not just yet…
With the issue potentially identified, all I need to do is update the mail user object in O365. Easier said than done in a Hybrid environment running DirSync. I first attempted the cmdlet below through a Remote PowerShell session:
Set-MailUser <user> -ExternalEmailAddress <primary smtp address>
And got the dreaded red output below…
The operation on mailbox "xxxxxxx" failed because it's out of the current user's write scope. The action 'Set-MailUser', 'ExternalEmailAddress', can't be performed on the object ‘xxxxx' because the object is being synchronized from your on-premises organization. This action should be performed on the object in your on-premises organization.
Ok, no problem here. I have to make the change on-prem. Let’s go look at the on premise environment, update the attribute there, run Dirsync, and allow it to sync across. A quick couple of PowerShell commands and AD checks later, still don’t know where this is coming from….everything looks good.
- Get-Recipient <recipient> | fl PrimarySmtpAddress
PrimarySmtpAddress: xxxx.xxxx@domain.com
- Get-Mailbox <mailbox> | fl PrimarySmtpAddress, WindowsEmailAddress,
PrimarySmtpAddress: xxxx.xxxx@domain.com
WindowsEmailAddress: xxxx.xxxx@domain.com
- I reviewed the properties from ADSIEdit, and verified the TargetAddress is blank (which is what we would expect). This is the actual attribute which syncs to O365 and populates the ExternalEmailAddress on the mail user object.
So now what?
Finally Resolved
I ran through the steps below hoping for the best, and email started flowing again…
- Updated the on premise targetaddress attribute through ADSIEdit
- Should be in the “SMTP:xxxx@domain.com” format (no quotes)
- Ran DirSync
- Verified the ExternalEmailAddress attribute was updated on the O365 mail user object
- Sent a test message
- Received another NDR for ‘Hop count exceeded - possible mail loop’ (arrgggghhhhh!!!)
- Noticed this time the NDR’s originating server was on premise this time
- Removed the on premise targetaddress
- Ran DirSync
- Ensured it wasn’t removed from the mail user object
- Verified the message was successfully delivered
Root cause remains unknown, but it’s assumed to be that the mailbox move back to on premise Exchange 2007 didn’t properly update the externalemailaddress mail user attribute on the O365 mail user object. I don’t think this is a common issue out there in O365 land, but I didn’t see anything written about it in my initial search online, so thought it would be worth sharing. Thanks,