5.4.6

Enhanced Status Code 5.4.6: Routing Loop Detected

Permanent failure High severity Network RFC 3463
What it means

Enhanced Status Code 5.4.6 means “Routing Loop Detected.” The message was forwarded between servers too many times and was stopped to prevent an endless loop. Two systems are each convinced the other should deliver it.

At a glance
Code5.4.6
Bounce typeHard (permanent)
SeverityHigh
CategoryNetwork
What to doSuppress the address; do not retry
StandardRFC 3463
What it looks like in your mail logs 
554 5.4.6 Message exceeded 50 hops, this may indicate a mail loop

What does 5.4.6 mean?

Enhanced status code 5.4.6 means a routing loop was detected. RFC 3463 defines it as a loop that caused the message to be forwarded too many times, either because of a configuration error or a deliberate attempt to consume resources. Google returns it as 554 5.4.6 after a message exceeds fifty hops, and Microsoft reports it as 5.4.6 or 5.4.14.

The classic cause is two-way forwarding. A mailbox forwards to an address that forwards back, and the message circulates until the hop count trips. Mail systems count Received headers to detect this, which is why the limit is expressed in hops rather than time. A subtler version happens with split domains, where two servers each believe the other is authoritative for a domain and neither will accept final delivery.

These are almost always configuration faults and they are usually recent, because a loop that existed before would have been noticed. When one appears, look at what changed: a newly added forwarding rule, a migration that left an old server still answering for the domain, or an MX record updated on one side of a split setup but not the other.

How 5.4.6 plays out

Your server attempts delivery
The recipient server returns a permanent 5.4.6 rejection
This is a hard bounce: the message will not be accepted as sent
Suppress the address and fix the root cause before resending

Where 5.4.6 sits: soft vs hard bounce

Soft bounce (4xx) Hard bounce (5xx)
NatureTemporaryPermanent
SMTP class4xx5xx
What to doLet it retrySuppress the address
Recoverable?OftenNo
5.4.6 is✓ this code

Common causes of 5.4.6

  • Two mailboxes forward to each other, directly or through a chain
  • A migration left an old server still accepting mail for the domain
  • Split domain routing where two servers each defer to the other
  • An out-of-office or auto-reply rule responding to its own replies
  • A distribution list containing an address that expands back to the list
  • A transport rule that redirects mail back into the path it came from

How to fix 5.4.6

  • Read the Received headers on the looping message, which show the exact cycle
  • Look for forwarding rules added recently on both mailboxes involved
  • For split domains, confirm exactly one server is authoritative for final delivery
  • Check distribution lists for members that expand back into the list
  • Decommission old servers properly after a migration rather than leaving them answering
  • Disable the offending forward or transport rule rather than raising the hop limit

Frequently asked questions

What does 554 5.4.6 mean?
It means a routing loop was detected: the message was forwarded between servers so many times that a hop limit was reached, and it was stopped to prevent it circulating indefinitely. Google applies a fifty hop limit. It is a permanent failure and always indicates a configuration fault rather than a transient condition.
How do I find the loop?
Read the Received headers on the bounced message. They are added in order by each server that handled it, so the repeating pattern shows exactly which two systems are passing it back and forth. This is one of the few problems where the message itself contains a complete diagnosis.
What usually causes a mail loop?
Two-way forwarding is the most common: mailbox A forwards to B, and B forwards back to A. After that come migrations where an old server was never fully decommissioned and still answers for the domain, and split domain setups where two servers each believe the other should deliver.
Can auto-replies cause a loop?
They can, when two auto-responders reply to each other. Correctly implemented auto-replies suppress responses to mail with a null envelope sender and do not reply more than once to the same correspondent, which prevents this. Homegrown responders that skip both checks are a frequent source of loops.
Should I raise the hop limit to fix this?
No. The limit is what stops a loop consuming resources indefinitely; raising it makes the symptom take longer to appear while the loop continues. Find the cycle in the Received headers and remove the rule causing it.

Related bounce codes

5.4.4 Unable to Route 5.4.1 Relay Access Denied 4.4.7 Delivery Time Expired 5.1.6 Destination Mailbox Has Moved 554 Transaction Failed

Sources & further reading

RFC 3463 · The standard that defines this reply code IANA registry · The authoritative list of enhanced status codes and their meanings Gmail SMTP errors and codes · Google Workspace reference for every code Gmail returns
Reviewed by Jennifer Jackson, Email Deliverability Analyst · June 2026 ← All bounce codes