554 5.4.14 Hop Count Exceeded: Mail Loop Bounce Explained

A 554 5.4.14 "hop count exceeded" or "routing loop detected" bounce means the message was handed from one mail server to another so many times that a server stopped it. It is a mail loop, caused by a configuration fault in the sending or receiving mail system, usually forwarding. It does not mean the address does not exist. For a prospect's domain, you cannot fix it: pause the address and try another channel. For your own domain, find the forwarding rule or connector that sends mail back. Verification will not repair a loop, but it clears the genuinely dead addresses around it. SimpleVerifier Pro is $39 a month with the first 100,000 checks a month at full speed, then slower, never cut off, and 100 free checks.

What the code says

RFC 3463 defines the enhanced status X.4.6 as "routing loop detected": a routing loop caused the message to be forwarded too many times, either because of a routing-table fault or a user-forwarding loop. It classes it as a persistent transient error, one that the system might clear on its own.

Microsoft's Exchange Online nondelivery report documentation, which we read on 10 November 2026, lists "5.4.6 or 5.4.14 Routing loop detected" and explains:

• A configuration error caused an email loop.
• An on-premises Exchange server generates 5.4.6, which you see in hybrid environments. Exchange Online generates 5.4.14.
• By default, after 20 iterations of an email loop, Exchange interrupts the loop and sends a nondelivery report to the sender.
• Typical causes are a configuration error on the sending mail server, the receiving mail server, or both, and Microsoft suggests checking automatic forwarding on the sender's and recipient's mailboxes.

Other servers phrase the same thing as "too many hops", "hop count exceeded" or "message exceeded 50 hops, this may indicate a mail loop". Each Received header a server adds counts as one hop, and a server gives up after a set number. Our reference page for the code is /smtp/554-5-4-14.

What a mail loop looks like

A loop happens when two systems each believe the other is the next stop for a message. Examples:

• Mailbox A forwards everything to mailbox B, and mailbox B forwards everything back to mailbox A.
• A domain's mail is hosted at one provider, but a connector or smart host sends outbound mail for that domain back to the first provider.
• MX records point at a server that relays mail straight back to the sender's system.
• An auto-reply rule that answers its own auto-replies.

Microsoft's description of the cause is that delivery of a message generates another message, which generates a third, and the cycle repeats until Exchange breaks it.

Whose fault is it, and does the address stay on your list?

Where the loop is	What you can do
Your own domain or mailboxes	Fix it: forwarding rules, connectors, MX
A prospect or customer domain	Nothing. Only their administrator can change it
A shared or role address with auto-forwarding	Try a named person instead

The address is not proven dead, so do not mark it invalid. But do not keep sending either: each loop bounce is another failure against your sending domain.

Step by step

1. Read the full bounce. Look for "hop count", "too many hops" or "routing loop". Check the sending domain in the headers too: if the bounce was generated by your own system, the loop is probably yours.
2. Is it one address or many? One address on one domain is that domain's forwarding. Many addresses on the same domain point to a domain-level mail setup problem. Group the bounces with the bounce domain hotspot finder.
3. If it is your own domain: in Microsoft 365, check mailbox forwarding rules and inbox rules, connectors, and whether the domain is set as internal relay when its mail is actually hosted elsewhere. Microsoft's guidance for 5.4.6 and 5.4.14 covers these. After a change, test by sending to the affected address yourself.
4. If it is theirs: pause the address. If it is worth the effort, reach the person another way and mention that mail to them is looping. Do not retry in a loop of your own.
5. Try once later. Loops are sometimes fixed within a day. One careful retry is reasonable. A second identical failure means move on.
6. Move it out of the active sequence, but do not label it invalid. Keep a note so it is not reimported as fresh.
7. Check the domain's mail servers with the bulk MX lookup. If the MX records point somewhere odd, that supports a domain-level fault.

For a general read of what the bounce text says, paste it into the bounce message analyzer or the SMTP transcript explainer.

How it differs from a bad address

A bad address returns a code like 550 5.1.1, user unknown. A mail loop returns after the message has already been accepted by one server and passed around. It is a delivery-chain failure. The two need opposite handling: a dead address you remove, a looped address you hold. That is why reading the code beats counting bounces. See hard bounce vs soft bounce for how to classify the rest.

Where verification helps

Honesty first: a mailbox check cannot detect a forwarding loop. The loop occurs after acceptance, in the delivery chain, not at the point where a verifier asks whether the address exists. An address behind a loop can come back valid, or risky if the server will not confirm it.

What verification does is remove the avoidable bounces that surround a loop. When a send produces a handful of loop bounces and a hundred dead-address bounces, you want to eliminate the hundred, so the few real oddities are visible and your bounce rate stays small. SimpleVerifier asks the recipient's mail server whether it would accept the address, without sending anything, and labels each row valid, risky or invalid. Our post on verified emails that still bounce explains what any check can and cannot know.

Try one address with the free email checker, or run a file through /verify.

How SimpleVerifier fits

SimpleVerifier Pro is $39 a month. The first 100,000 checks a month run at full speed, then slower, and you are never cut off. Start with 100 free checks, no card. See pricing.

Preventing loops on your own domain

If loops are yours, a few habits help:

• Avoid forwarding between two mailboxes that can forward to each other.
• When you add a connector or smart host, test mail in both directions.
• Document where each domain's mail is hosted, and check it when you change providers.
• Be careful with auto-replies on shared mailboxes that receive their own auto-replies.
• After any change to mail routing, send a test to an outside address and read the headers.

For sending infrastructure, the email DNS error checker catches common DNS-side mistakes.

What not to do

• Do not delete the address as invalid. It may be a perfectly good mailbox behind a broken route.
• Do not hammer retries. The loop will not clear faster.
• Do not blame the verifier if a verified address loops. The loop occurs after the check.
• Do not leave it unread. A cluster of loop bounces on your own domain can mean a misconfiguration that hits customers too.

Bottom line

554 5.4.14 means a mail loop: a configuration fault that sends the message round in circles until a server stops it. It is not about whether the address exists. Fix it if the domain is yours, hold the address if it is theirs, and use verification to remove the dead addresses that make real oddities hard to see. The bounce doctor is the next stop if bounces are climbing and you are not sure why.