5.4.0Message rejected for exceeding the mail system's hop limit (routing-loop protection)

Exact corpus evidence alone places concrete code 5.4.0 here: one production non-delivery report in which a receiving mail system used the digits 5.4.0 specifically to signal a hop-count loop-protection abort, not an unspecified network problem in general. The code maps registry pattern X.4.0 onto class 5. RFC 3463 seats X.4.0 in the base table as the generic network-and-routing catch-all for problems that do not fit any of the pattern's more specific detail codes, yet IANA's Associated Basic Status Code for X.4.0 is "Not given" for every class, and this catalog's registry mirror treats the pattern as fully unresolved: no class is mechanically confirmed at all, not even a class-4 reading.

Unlike siblings such as X.4.1 ("no answer from host", class 4 confirmed) or X.4.3 ("directory server failure", classes 4 and 5 confirmed), IANA records the Associated Basic Status Code for X.4.0 as "Not given" for every class, and this catalog's registry mirror carries the pattern as fully unresolved. RFC 3463 (Section 3.4) defines the X.4 subject class as network-and-routing status and lists X.4.0 in the base table as that class's generic catch-all detail: something went wrong with the networking, but it is not clear what the problem is, or the problem cannot be well expressed with any of the other provided detail codes. Neither 4.4.0 nor 5.4.0 rests on an IANA class confirmation. The concrete code 5.4.0 is published on exact corpus evidence: a Locaweb-hosted mail system's non-delivery report in which the digits 5.4.0 accompany a hop-count loop-protection abort at the end of the DATA phase, not a generic or unspecified network fault.

The leading digit 5 denotes a permanent failure for this message in its current context: resending it unchanged will not succeed, because the condition producing a hop-count abort — typically a routing or forwarding loop — reproduces identically on the same path. This does not by itself mean the recipient address is invalid; it means the path the message took looped, or grew too long, before reaching it.

Class

Permanent failure

Retry

Do not retry unchanged

Suppression

Check the full context

Do not resend the identical message on the same path. A resend only makes sense once the loop has actually been found and removed — a forwarding rule corrected, a relay or smart-host route fixed — not simply after time has passed. If the same 5.4.0 recurs on an unmodified path, that confirms the loop is still present rather than transient congestion.

Do not add the address to a suppression list based on a single 5.4.0. The condition describes the message's path, not necessarily the address itself; correlate repeated occurrences with an actual routing or forwarding diagnosis before treating the address as unreachable, and suppress only when list policy or an independent permanent signal justifies it.

• A mailbox-level forwarding loop: the recipient's account (or a mailing list it belongs to) auto-forwards mail back along a path that returns to the same message, adding Received: header hops until the destination's configured limit is exceeded.
• A misconfigured relay or routing chain between two or more mail systems — for example a smart host or gateway whose route points back at itself, or two systems relaying to each other — that keeps re-injecting the same message until the hop-count safety check trips.
• In the accepted example, Locaweb's mail relay (balancer_haproxy.email.locaweb.com.br) enforces this hop-count limit at the end of the DATA phase and returns 554 5.4.0 rather than accepting a message it judges caught in a loop — documented behavior of this specific hosting platform, not a universal definition of code 5.4.0.

1. Pull the full Received: header chain from the original message (or the copy attached to the bounce, if present) and count the hops; look for a repeating hostname or address, which indicates a cycle rather than an ordinary long relay chain.
2. Confirm the enhanced code is exactly 5.4.0 and the basic reply is 554, and note that the rejection is returned at the end of the DATA phase — after the full message body was already transmitted, not at RCPT TO.
3. Check the recipient's own forwarding configuration — webmail auto-forward rules, mailing-list membership, or alias chains — for a rule that resends the message back toward the sender or back through the same relay.
4. If a corporate relay, smart host, or gateway sits between sender and recipient, inspect its routing table for a self-referencing or circular route, and correct it before asking the sender to resend.