554 5.4.6 hop count exceeded: finding the mail loop in Exchange routing

Fix it now

Microsoft publishes 5.4.6 as Routing loop detected, and states that Exchange interrupts a mail loop after 20 iterations by default and returns a non-delivery report. The ceiling is the safety net, not the fault: something is sending mail in a circle.

Get-Mailbox user@contoso.com | Format-List ForwardingAddress,ForwardingSmtpAddress,DeliverToMailboxAndForward

Get-InboxRule -Mailbox user@contoso.com | Format-List Name,ForwardTo,RedirectTo,Enabled

Get-AcceptedDomain | Format-List Name,DomainName,DomainType

1. Open the bounced message and read the Received headers from the bottom upwards. A loop shows as the same two or three host names repeating in sequence.
2. Check forwarding on the recipient the loop centres on, at both levels: the mailbox properties and the user’s own inbox rules. A redirect rule is invisible in Get-Mailbox.
3. Confirm the domain is authoritative on exactly one system. A domain marked authoritative on two will loop between them.
4. In a hybrid organisation, check that the connector routing mail from Exchange Online to your servers uses smart host routing rather than DNS routing, and that the connector to your organisation has the on-premises connector type.
5. Trace the message: Get-MessageTrackingLog -MessageSubject 'test' -Start (Get-Date).AddHours(-2) | Format-Table Timestamp,EventId,Source,ServerHostname,Recipients

5.4.6 is generated by on-premises Exchange Server, which is why it usually shows up in a hybrid organisation. Exchange Online generates 5.4.14 for the same condition.

If a test message now makes a single pass, you are finished. If the code is 5.4.8, that is an MTA-STS validation failure and not a loop at all – the next section explains the difference.

Why it happens

A mail loop is self-amplifying. Nothing in SMTP stops two systems handing a message back and forth indefinitely, and one looping message can consume a queue, a disk and eventually a server. Microsoft’s stated protection is an iteration count: by default, after 20 iterations of a loop, Exchange interrupts it and generates a non-delivery report to the sender. The published cause is that delivery of a message generates another message in response, which generates a third, and the process repeats.

The same condition produces two codes depending on which system notices. On-premises Exchange Server generates 5.4.6, which is why it is the one you see in a hybrid organisation, and Exchange Online generates 5.4.14. Microsoft’s guidance for both starts in the same place: verify that the recipient’s domain is configured as an authoritative accepted domain, then check whether automatic forwarding is enabled by reading the sender’s and the recipient’s mailbox rules.

In a hybrid organisation Microsoft names three specific configuration faults. Incoming mail routed through Exchange Online loops when the connector used to route mail from Exchange Online to the on-premises organisation is configured for DNS routing instead of smart host routing. Outgoing mail routed through the on-premises server loops when there is no connector from Microsoft 365 to your organisation’s mail server with the connector type On-premises, or when that connector is scoped to one or more accepted domains. Rerunning the Hybrid Configuration Wizard is the documented remedy for the connector faults.

One code in this group is not about loops at all. Microsoft publishes 5.4.8 as MX hosts of <domain> failed MTA-STS validation – the destination MX host was not the host the domain’s MTA-STS policy expects. It sits next to the loop codes numerically and nowhere near them in cause.

Full reference

The four shapes a loop takes in the headers

The codes, and which is not a loop

5.4.8 is a different problem with a different fix

If you have 5.4.8, stop looking for forwarding rules. The destination domain publishes an MTA-STS policy naming the MX hosts it expects, and the host Exchange reached was not on that list. That is either a stale policy at their end or a change of MX record they have not reflected in it. Nothing in your accepted domains, your connectors or your inbox rules affects it, and there is nothing to fix on your side beyond telling them.

Reading Received headers

1. Open the message and view its internet headers through message properties, or read them from the non-delivery report.
2. The headers are stacked newest first, so read from the bottom upwards to follow the message forwards through time.
3. Each hop names the host that handed the message on and the host that received it.
4. Count the repetitions. A loop that reached the ceiling shows the same pair twenty times over.
5. Note the recipient address the repetitions centre on – that is the object to investigate, not the original sender.

Do not respond to this by trying to raise the loop ceiling or by disabling loop detection. Microsoft’s stated reason for interrupting after 20 iterations is to protect against exhausting system resources. Removing that protection lets a looping message multiply until the transport queue database fills, at which point back pressure stops the server accepting new mail for everybody.

Finding forwarding you did not know about

• Mailbox forwarding, in ForwardingAddress and ForwardingSmtpAddress, is set by an administrator and visible in Get-Mailbox.
• Inbox rules with ForwardTo or RedirectTo are set by the user and only visible in Get-InboxRule.
• Transport rules can redirect messages organisation-wide and are visible in neither.
• Mail contacts and mail users inside a group can point at an address that comes straight back.
• A resource mailbox with a delegate can generate responses that re-enter the loop.

Proving it is gone

One test message, to the address that was looping, delivered once, with a single set of Received headers rather than a repeating pattern. Then check the tracking log for one DELIVER event rather than a series of TRANSFER events between the same two hosts, and watch queue depth return to normal. A loop that has been running for a while leaves a backlog behind it, and the queue is where you will see whether it has actually stopped.

Every code this article covers

Confirm the fix worked

1. A test message to the affected address is delivered once, with a single set of Received headers.
2. Get-Mailbox and Get-InboxRule show no forwarding or redirect remaining on the mailbox that was looping.
3. The tracking log shows one DELIVER event for the recipient, not a series of TRANSFER events between the same two hosts.
4. Get-AcceptedDomain shows the domain authoritative on exactly one system.
5. Queue depth returns to normal and no new loop reports appear over the following day.

Questions people ask about this