TL;DR
The documented response ended delivery after too many hops. Repair routing before a new send; it does not establish recipient invalidity.
What this code means
X.4.0 is the generic other-or-undefined network-and-routing pattern. The IANA mirror confirms no class for it; this concrete class-5 page rests on exact Locaweb corpus evidence of too many hops.
Provider examples
554 5.4.0 Error: too many hopsTechnical meaning
The accepted response is “554 5.4.0 Error: too many hops,” returned in an asynchronous DSN after DATA. It documents a hop-limit loop-protection abort for that system, not a registry-confirmed universal definition of 5.4.0.
Delivery status
The 5xx response permanently ended the recorded delivery attempt. It does not prove the address is invalid, identify every routing component, or mean a corrected route cannot accept a new attempt.
- Class
- Permanent failure
- Retry
- Do not retry unchanged
- Suppression
- Check the full context
Retry decision
Stop retries of the unchanged route. Consider a new submission only after a responsible administrator has confirmed that the loop or routing configuration changed.
Suppression decision
Do not suppress the recipient based on 5.4.0 alone. A routing-loop signal concerns message path handling, not recipient validity.
Common causes
- A forwarding or routing loop exhausted the permitted hop count.
- Configuration of a route or forwarding rule sent the message repeatedly through a path.
Diagnostic steps
- Retain the complete DSN, raw response, time, and message identifier.
- Trace Received headers and routing or forwarding logs to find the repeated path.
- Confirm the loop is corrected before a new submission.
Actions by owner
Sender administrator
- Stop unchanged attempts and provide the DSN and headers to the party managing the route.
- Submit again only after confirmation of a route change.
Recipient administrator
- Inspect forwarding and routing rules for a loop involving the destination.
- Correct the rule and verify a fresh path.
Provider
- Inspect relay logs and loop detection for the recorded message.
- Correct or report the confirmed routing condition without suppressing the recipient from 5.4.0 alone.
Sources
These sources define what this enhanced status code means, mainly through the IANA registry and related RFCs. When provider examples appear on the page, they come from that provider's published documentation. Follow the links to read the original wording in context.
- RFC 3463 — Enhanced Mail System Status Codes — Defines the class/subject/detail model for enhanced status codes.
- RFC 5248 — A Registry for SMTP Enhanced Mail System Status Codes — Creates and governs the IANA enhanced status code registry.
- email-bounce-parser (test fixture corpus) — Open-source bounce-parsing library whose test fixtures are pinned locally as evidence.
Last verified:
