554 5.4.6: A mail loop was detected
At a glance
- Type: permanent failure (class 5, RFC 3463 §2). The sending server does not retry; sending the same message again fails the same way until the cause is fixed.
- Basic code 554: “Transaction failed (Or, in the case of a connection-opening response, "No SMTP service here")” (RFC 5321 §4.2.3).
- Enhanced code 5.4.6: “Routing loop detected” in the IANA registry (RFC 3463), in the group network and routing status (RFC 3463 §3.5).
The message went round in a loop. Two or more servers, or forwarding rules, kept passing it between them until one of them counted too many hops and stopped it.
What it means
RFC 3463 §3.5 defines X.4.6 as "routing loop detected": the message was forwarded too many times, because of incorrect routing tables or a forwarding loop set up by users. The RFC describes it as a transient code, but Gmail sends it as a permanent 554: retrying a message that is stuck in a loop would only repeat the loop. The basic code 554 says the transaction failed (RFC 5321 §4.2.3).
Every server that handles a message adds a Received: header. RFC 5321 §6.3 says counting these headers is an effective way to detect loops, recommends a high threshold of normally at least 100 entries, and requires servers to have some way to stop simple loops.
Common causes
- Two mailboxes forward to each other, directly or through a third.
- A mailbox forwards to an external address, and that address forwards back.
- A domain's MX record points to a server that relays the mail back to where it came from.
- A connector or smart host on a hybrid or migrated mail system sends mail for a domain back and forth between two platforms.
How providers use it
- Gmail returns 554 5.4.6 when a message has passed more than 50 hops, which it treats as a probable loop (Google's SMTP error reference).
- Microsoft uses 5.4.6 for a routing loop in on-premises Exchange and 5.4.14 in Exchange Online. It names forwarding rules and misconfigured connectors as causes (Exchange Online NDR reference).
How to fix it
- Open the bounced message's headers and read the
Received:lines from the bottom up. The same two server names repeating show you where the loop is. - Check forwarding on every mailbox involved, including server-side rules and automatic forwarding settings.
- Check the recipient domain's MX records and make sure they point to the system that should store the mail, not to a relay that sends it back.
- On hybrid or migrated setups, check which system is authoritative for the domain and that connectors send mail in one direction only.
- After the fix, send a test and check that the received copy has a normal number of
Received:lines.
If the loop involves automatic forwarding to an outside address, the forwarding may also be blocked by policy; see 5.7.520.
Related codes
- 4.4.7: The message expired in the queue
- 5.7.520: External forwarding is not allowed (Microsoft 365)
- 5.4.1: Recipient address rejected: access denied (Microsoft 365)
See every bounce code in the dictionary.
Many bounces from addresses that do not exist can be avoided: check an address with our free email checker, or clean a whole list before you send.
How we wrote this: drafted by the email-validation.org team with the help of AI writing tools, from our product documentation and the sources linked in the text.