Freigeben über

Hop Count Exceeded - Possible Mail Loop

  • Artikel

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…

  1. Updated the on premise targetaddress attribute through ADSIEdit
    • Should be in the “SMTP:xxxx@domain.com” format (no quotes)
  2. Ran DirSync
  3. Verified the ExternalEmailAddress attribute was updated on the O365 mail user object
  4. Sent a test message
  5. Received another NDR for ‘Hop count exceeded - possible mail loop’ (arrgggghhhhh!!!)
  6. Noticed this time the NDR’s originating server was on premise this time
  7. Removed the on premise targetaddress
  8. Ran DirSync
  9. Ensured it wasn’t removed from the mail user object
  10. 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,

Comments

  • Anonymous
    February 03, 2014
    Hi, Thanks for this resolved my issue as well I knew exactly what was wrong but could not initate a full sync. May be helpful to provide instructions on how initate a full dir sync. Go to C:Program FilesMicrosoft Online Directory Sync in powershell and open the ps1 file .DirSyncConfigShell.psc1 this will open a new powershell window run the following command. Start-OnlineCoexistenceSync Regards, Kevin
  • Anonymous
    June 03, 2015
    I concur.
  • Anonymous
    August 11, 2015
    "Removed the on premise targetaddress" fixed my problem.
    We aren't using O365 but we are using Exchange 2013. Our Exchange server thought the address was external and emails went to our anti-spam filter only to have it go back to Exchange and loop back to anti-spam.
  • Anonymous
    September 29, 2015
    Thank you so much for sharing this helpful knowledge with us. Thank Dear William.
  • Anonymous
    December 09, 2015
    7135189388