554 5.4.6 and 5.4.14 Hop count exceeded: finding and fixing Exchange mail loops

A "hop count exceeded" NDR means a message went round in a circle until a server refused to pass it on. Raising the limit never fixes it. You have to find the hop that sends the message back. This post shows how to read the NDR, trace the loop with message tracking, and correct the accepted domain, connector or recipient that causes it, on Exchange Server SE and 2019 and in hybrid.

Symptoms#

The sender receives an NDR with one of these lines:

554 5.4.6 Hop count exceeded - possible mail loop
554 5.4.14 Hop count exceeded - possible mail loop ATTR34

• Microsoft documents 5.4.6 as always generated by on-premises Exchange Server and 5.4.14 (with an ATTR suffix) as generated by Exchange Online. The code tells you which side gave up, not which side is misconfigured.
• The NDR often arrives minutes later. Its original headers contain dozens of Received: lines in which the same two hosts take turns.
• Usually only some addresses are affected: a deleted user, a forwarded mailbox, one migrated user, or a whole domain after a routing change.

Why it happens#

Every server that handles a message adds a Received: header. Exchange receive connectors refuse messages that carry too many of them. This is controlled by the MaxHopCount and MaxLocalHopCount settings, and MaxHopCount is 60 by default. A loop needs two places that each believe the other is responsible for the recipient. These are the patterns behind most loops:

How to fix it#

1. Read the NDR and its headers#

Note the code and the generating server, then open the original message headers. Read the Received: lines from the bottom up and mark the first host pair that repeats. The system that sends the message back the first time is where the fix belongs.

2. Trace the message across all servers#

Get-TransportService | Get-MessageTrackingLog -Recipients bob@contoso.com -Start (Get-Date).AddDays(-1) -ResultSize Unlimited |
  Sort-Object Timestamp |
  Format-Table Timestamp,ServerHostname,EventId,Source,ConnectorId,RecipientStatus -AutoSize

The signature of a loop is the same message repeating RECEIVE and SEND every few seconds, usually entering on one connector and leaving on another (for example Outbound to Office 365), until a FAIL event with the hop count status. The ConnectorId on the SEND events names the send connector that keeps routing it away.

3. Check accepted domains#

Get-AcceptedDomain | Format-Table Name,DomainName,DomainType,Default -AutoSize

If every recipient for the domain lives in this organization, make it authoritative. Unknown recipients then get an immediate "recipient not found" NDR instead of being relayed:

Set-AcceptedDomain -Identity contoso.com -DomainType Authoritative

If the namespace really is shared, keep InternalRelay, but make sure the other system is authoritative for the addresses it holds and rejects the rest, so nothing comes back.

4. Check send connectors#

Get-SendConnector | Format-Table Name,AddressSpaces,SmartHosts,DNSRoutingEnabled,Enabled -AutoSize -Wrap

Look for your own domain in an address space, smart hosts that resolve to your own Exchange servers or their load balancer, and a * connector going through a gateway that accepts your domain and hands it back.

5. Check the recipient objects#

Get-Recipient -ResultSize Unlimited -Filter "EmailAddresses -eq 'smtp:bob@contoso.com'" |
  Format-List Name,RecipientTypeDetails,ExternalEmailAddress
Get-Mailbox -ResultSize Unlimited | Where-Object { $_.ForwardingAddress -or $_.ForwardingSmtpAddress } |
  Format-Table Name,ForwardingAddress,ForwardingSmtpAddress
Get-RemoteMailbox -ResultSize Unlimited | Where-Object { $_.RemoteRoutingAddress -notlike '*.mail.onmicrosoft.com' } |
  Format-Table Name,RemoteRoutingAddress

Fix whatever points back into your own organization. For example, give a remote mailbox its routing address in the tenant's coexistence domain:

Set-RemoteMailbox -Identity bob -RemoteRoutingAddress bob@contoso.mail.onmicrosoft.com

More on these attributes in remote mailboxes in Exchange hybrid.

6. In hybrid, check the Exchange Online side#

In Exchange Online PowerShell:

Get-AcceptedDomain | Format-Table DomainName,DomainType
Get-OutboundConnector | Format-List Name,ConnectorType,UseMXRecord,SmartHosts,RecipientDomains,RouteAllMessagesViaOnPremises

The connector to on-premises should be an On-premises type connector that routes to your hybrid servers as smart hosts. With centralized mail transport, it must not be scoped to accepted domains. The cleanest way to correct either problem is to re-run the Hybrid Configuration Wizard. See hybrid mail flow connectors and HCW errors. Also confirm that every domain used in proxy addresses is verified in the tenant.

Verify the fix#

• Send a new test to the affected address and re-run the tracking query. Good looks like one RECEIVE followed by DELIVER, or a single SEND to the correct destination, with no repeats.
• Send to an address that doesn't exist. A healthy setup returns a prompt "recipient not found" NDR instead of a hop count NDR minutes later.
• Check that no copies are still circulating:

Get-TransportService | Get-Queue | Where-Object { $_.MessageCount -gt 0 } |
  Format-Table Identity,DeliveryType,Status,MessageCount,NextHopDomain -AutoSize

Prevent it next time#

• Give each namespace exactly one final owner. Use internal relay only when the downstream system is authoritative and rejects unknown recipients.
• Let the Hybrid Configuration Wizard manage hybrid connectors instead of editing them by hand, and document every send connector and smart host.
• Before you remove a mailbox or change a domain's type, check for forwarding, contacts and connectors that reference it.

References#

• Fix NDR error 5.4.6 or 5.4.14 in Exchange Online (Microsoft Learn)
• 554 5.4.14 Hop Count exceeded (Microsoft Learn)