SMTP Network, DNS and Routing Status Codes
X.4 status codes concern the path to the destination system, including reachability, directory-service, connection, routing, and congestion conditions. Retain the complete response before diagnosing DNS or scheduling another attempt.
Network and routing status does not prove a particular DNS cause from the subject alone. Most reviewed X.4 entries are temporary-class conditions, but the detailed code and provider text determine the appropriate repair, timing, or escalation.
Choose the next check
- Capture path and time evidenceKeep the SMTP reply, destination domain, connection details, and timestamp before attributing the failure to DNS or routing.
- Check the remote host and connectionSeparate a missing remote-host answer from a connection that does not complete the mail transaction.
- Check directory service and congestionDirectory-service and congestion results require the exact response; a directory error does not by itself prove an Internet DNS outage.
Common mistakes
- Calling every X.4 response a DNS failure.
- Retrying indefinitely without a bounded policy tied to the detailed condition.
- Treating a path failure as a recipient-address diagnosis.
Start with the exact X.4 response and delivery path, then investigate the host, connection, directory, route, or congestion condition it actually reports.
Codes in this category
This inventory contains only reviewed codes assigned to this subject. Open a code to see its evidence, diagnostic steps and owner-specific actions.
- 4.4.0Temporary failure for an unspecified network or routing reason (other/undefined network status)The receiving system reports a temporary failure using the generic "other or undefined network or routing status" code: some network-layer or routing/replication condition prevented delivery at this attempt, but the response does not identify one of the more specific network conditions this catalog also tracks (no answer from host, bad connection, directory server failure, mail system congestion, a routing loop, or delivery-time expiry). The code belongs to the temporary class: whatever condition triggered it may clear, so delivery may be retried in a controlled way.Delivery status4xx · Temporary failureRecommended actionControlled retry
- 4.4.1No answer from remote hostAn outbound connection attempt received no answer from the remote system. The standard indicates that the system may have been busy or unable to accept a connection. The code belongs to the temporary class, so delivery may be retried in a controlled way.Delivery status4xx · Temporary failureRecommended actionControlled retry
- 4.4.2Bad connectionAn outbound connection was established, but the message transaction could not be completed over it. The standard points to a timeout or inadequate connection quality. The code belongs to the temporary class, so delivery may be retried in a controlled way.Delivery status4xx · Temporary failureRecommended actionControlled retry
- 4.4.3Directory server failureThe network system could not forward the message because a directory server was unavailable. Inability to connect to an Internet DNS server is one standards example, but the code alone does not prove that the problem involved DNS. The code belongs to the temporary class, so delivery may be retried in a controlled way.Delivery status4xx · Temporary failureRecommended actionControlled retry
- 4.4.5Mail system congestionA mail system could not deliver the message because it was congested. The code does not identify which system or party is responsible for that condition. It belongs to the temporary class, so delivery may be retried in a controlled way.Delivery status4xx · Temporary failureRecommended actionControlled retry
- 4.4.6Routing loop detected between mail systemsThe sending or an intermediate mail system reports that this message was forwarded from system to system too many times without reaching its destination — a routing loop. The code belongs to the temporary class: once whichever forwarding rule or routing table is causing the loop gets fixed, delivery may succeed, so retrying in a controlled way is appropriate.Delivery status4xx · Temporary failureRecommended actionControlled retry
- 5.4.0Message rejected for exceeding the mail system's hop limit (routing-loop protection)The receiving system reports a permanent delivery failure using the enhanced code 5.4.0: in the accepted evidence, a mail system aborted delivery because the message had already passed through more hops than its configured safety limit allows — the mechanism mail systems use to abort suspected routing loops. The code itself is the registry's generic "other or undefined network or routing status" catch-all, not a status defined specifically for hop-count loop protection.Delivery status5xx · Permanent failureRecommended actionDo not retry unchanged
- 5.4.1Mail rejected by the destination domain (permanent)The receiving system reports a permanent, destination-side rejection of the message using the enhanced code 5.4.1: the destination domain's own mail filters, or a recipient-address access policy, refused the message or address in a way this catalog's collected evidence never ties to a literal, unanswered connection attempt. Class 5 makes this a permanent result for the current context.Delivery status5xx · Permanent failureRecommended actionDo not retry unchanged
- 5.4.3Directory server failureThe network system could not forward the message because a directory server was unavailable. Inability to connect to an Internet DNS server is one standards example, but the code alone does not prove that the problem involved DNS. Class 5 makes this a permanent result, so do not retry in the unchanged context.Delivery status5xx · Permanent failureRecommended actionDo not retry unchanged
- 5.4.6Recipient or domain quota exceeded on a hosted mailbox platform (Titan)The receiving system reports a permanent rejection at RCPT TO using the enhanced code 5.4.6 when either a specific recipient mailbox has exceeded its own storage/rate quota, or the receiving domain as a whole has hit its hosting plan's hourly or daily incoming-mail quota. This catalog's evidence for the pattern comes entirely from Titan Email and does not describe a routing loop, the meaning RFC 3463 assigns to this pattern.Delivery status5xx · Permanent failureRecommended actionDo not retry unchanged
- 5.4.7Recipient domain's inbound rate quota exceeded (Titan Email)The receiving system reports that the recipient's domain has exceeded an administrative rate quota for accepting mail (hourly or daily) and is temporarily rejecting further messages. The code belongs to the permanent class: treat this specific delivery attempt as failed, and treat a later send as a new attempt once the limiting window clears, not as an automatic retry.Delivery status5xx · Permanent failureRecommended actionDo not retry unchanged
Related resources
Guide
- Sending Reliability
Use SMTP 4xx=retry vs 5xx=permanent for mixed 4.4.x and 5.4.3 path failures.
Wojtek Blazalek
Email deliverability expert
Stuck on this error code? I help teams identify rejection causes and fix authentication and reputation, so email reaches the inbox.
Hands-on deliverability work for teams that send at scale.