554 5.4.14 hop count exceeded: how to find the mail loop
554 5.4.14 Hop count exceeded means a message was handed between servers until a limit stopped it. Find the pair of hops that repeat, then break that route.
On this page(8 sections)
- What does 554 5.4.14 hop count exceeded mean?
- Which error code is it, and who generated it?
- Is it a real loop or just a low limit?
- How do I find the loop in the headers?
- What usually causes it?
- Two forwards that point at each other
- A domain that is not set up as the right accepted domain
- Hybrid connectors that route the wrong way
- A gateway that sends mail back where it came from
- An automated reply that answers an automated reply
- How do I fix it, step by step?
- What should a sender do if the fault is on the other side?
- Bottom line
554 5.4.14 Hop count exceeded - possible mail loop means a message was passed from server to server so many times that a safety limit cancelled it. Almost always two routing rules point at each other, so the message bounces back and forth until the counter runs out. The fix is never to raise the limit. It is to find the two hops that repeat and remove the rule that sends the message back.
This guide shows how to read the bounce, find the repeating pair in the headers, and fix the usual causes in Microsoft 365, Google Workspace and plain forwarding setups. If you have not read headers before, start with tracing a delivery through Received headers.
What does 554 5.4.14 hop count exceeded mean?
It is a permanent failure from Exchange Online saying the message went through too many hops, most likely because it is stuck in a loop. A hop is one server handing the message to the next, and each server adds a Received: header when it does. RFC 5321 (section 6.3) describes counting those Received: lines as a way to detect loops and says servers using it should use a large threshold, normally at least 100 entries.
Microsoft's own page on NDR 5.4.6 and 5.4.14 draws the line this way: 5.4.6 is a loop or routing problem in on-premises Exchange Server, and 5.4.14 is one inside Exchange Online. The full text of the Exchange Online version ends in a suffix such as ATTR34.
Which error code is it, and who generated it?
The code tells you which system gave up. Use it to decide whose configuration to inspect first.
| Bounce text | Generated by | Where to look |
|---|---|---|
554 5.4.14 Hop count exceeded - possible mail loop ATTR34 |
Exchange Online | Accepted domains, hybrid connectors, mailbox forwarding |
554 5.4.6 Hop count exceeded - possible mail loop |
On-premises Exchange Server | Send and receive connectors, hybrid routing |
Message exceeded 50 hops, this may show a mail loop (554 5.4.6) |
Google Workspace | Routing and Compliance rules, third-party gateways, forwarding |
Google documents the third row on its SMTP relay service error messages page: the message went through more than 50 hops. Note that Google reuses 5.4.6 for this error, so the number alone does not tell you the vendor. Read the text after it.
Is it a real loop or just a low limit?
It is a real loop in almost every case. A limit that is too low would fail legitimate mail that simply passes through several gateways, which is rare. If the bounce says "possible mail loop" and the same recipient fails every time, assume a loop and go look for the repeating pair.
A quick test: send a message to the same address from an unrelated account. If that one also bounces, the loop sits on the recipient's side of the route. If only one sender bounces, check that sender's own outbound rules and connectors first.
How do I find the loop in the headers?
Open the original message from the bounce (the NDR usually attaches or quotes it), view its full headers, and read the Received: lines from the bottom up. The bottom line is the first hop. A loop shows up as the same two servers appearing in turn.
Received: from mx-gateway.example.net by mail.contoso.example ...
Received: from mail.contoso.example by mx-gateway.example.net ...
Received: from mx-gateway.example.net by mail.contoso.example ...
Received: from mail.contoso.example by mx-gateway.example.net ...That pattern, A to B to A to B, is the loop. The two servers in it are the two systems whose rules you have to compare. The addresses and server names above are placeholders.
If you only have the bounce and not the original message, use the provider's trace instead:
- Exchange Online: run a message trace in the Exchange admin center for the failed message and read each routing event.
- Google Workspace: trace the message in Email Log Search, as Google's page above advises, and look for the same hop repeating.
- Hybrid setups: compare the Exchange Online trace with the on-premises message tracking logs around the same UTC timestamp so you can see where the message re-enters.
What usually causes it?
These are the causes that Microsoft and Google document, plus the one self-inflicted cause that is the most common of all.
Two forwards that point at each other
sales@ forwards to team@, and team@ forwards back to sales@. This is the simplest loop and the easiest to miss, because each rule looks reasonable on its own. Check mailbox forwarding, inbox rules, aliases and groups on both addresses. Our post on forwarding rules gone wrong covers the patterns in detail.
A domain that is not set up as the right accepted domain
Microsoft's first fix is to confirm the recipient's domain is configured as an authoritative accepted domain in Exchange Online. If Exchange Online accepts mail for a domain but thinks the mailbox lives elsewhere, it may route the message out and have it come straight back.
Hybrid connectors that route the wrong way
In a hybrid deployment, Microsoft lists two cases. First, the MX record for the hybrid domain points to Exchange Online while the connector toward on-premises uses DNS routing instead of smart host routing. Second, all outgoing mail is routed through the on-premises server, but the connector coming back into Exchange Online is missing, is not of type On-premises, or is scoped to specific accepted domains. Microsoft says the easiest fix for both is to rerun the Hybrid Configuration Wizard.
A gateway that sends mail back where it came from
A content filter, archiver or compliance gateway that receives mail from your platform and relays it back into the same platform can loop if the platform's rule also matches mail returning from the gateway. Google's advice is to make outbound and inbound routing rules exclude mail that already arrives from the gateway, and not to relay Workspace-originated mail through a gateway that sends it back to smtp-relay.gmail.com.
An automated reply that answers an automated reply
Two auto-responders, or an auto-responder and a helpdesk that notifies a monitored address, can generate a stream of messages. That produces a flood rather than one bounce, but the cure is the same: stop the cycle at its source. See an auto-reply that never loops for the headers that prevent it.
How do I fix it, step by step?
Work through this list in order. Stop as soon as a test message gets through.
- Read the exact bounce text and note the code, the generating system and any suffix such as
ATTR34. - Identify the repeating pair from the headers or the message trace.
- On the receiving side, look for forwarding on the recipient's mailbox, group or alias. Remove any forward that points back toward the sender's route.
- Confirm the recipient domain is an authoritative accepted domain where you expect mail to be delivered, not an internal relay domain by mistake.
- Review connectors and routing rules for the two systems you found. Exclude mail that already arrived from the other system.
- Send a fresh test message. Do not resend the stuck one; a message that already carries a long chain of
Received:lines will keep failing. - Watch the next few real messages for a day before you call it fixed.
What should a sender do if the fault is on the other side?
Tell the recipient's admin, and send them the full bounce. Microsoft is explicit that these errors typically can only be fixed by an Exchange Online admin and not the average sender. In the meantime, stop retrying the address in bulk, and treat it as a temporary hold rather than a bad address. This is a routing failure on their side, not a sign that the mailbox does not exist, so do not count it like a hard bounce that should permanently suppress the contact.
Bottom line
554 5.4.14 Hop count exceeded is Exchange Online telling you a message went around in circles. Read the headers bottom-up, spot the pair of servers that repeat, and remove the forward, connector setting or routing rule that sends the message back. Check the vendor's own code table first: 5.4.14 points at Exchange Online, 5.4.6 at on-premises Exchange, and Google uses its own "exceeded 50 hops" text.
Start with Koltrix
Your domain, one inbox, and an API that sends.
A team inbox where AI sorts and drafts (nothing is sent without your click), plus the transactional API and SMTP relay your product sends with. 7 days free, no card.
