TL;DR
4.4.1 means the remote host did not answer an outbound connection attempt. Preserve the response and connection log, retry with bounded backoff, and stop for diagnosis when the limit is reached; do not suppress the address from this code alone.
What this code means
X.4.1 denotes no answer from the host. The standard allows that the remote system was busy or unable to accept a connection, but the code alone does not determine which case occurred or where the missing response originated.
Technical meaning
The outbound connection went unanswered because the remote system was busy or unable to accept it. This registry detail is useful only as a persistent transient failure; 4.4.1 is not a permanent rejection of the message.
Delivery status
The leading 4 marks the current outcome as transient. It does not prove a recipient-address defect, an outage at a particular operator, or that repeating indefinitely will succeed.
- Class
- Temporary failure
- Retry
- Controlled retry
- Suppression
- Check the full context
Retry decision
Route the message through a bounded, idempotent retry mechanism with backoff and jitter. Stop after success, a permanent result, or the configured attempt/time limit, then investigate repeated results instead of retrying forever.
Suppression decision
Do not add the address to suppression based on 4.4.1 alone. Consider suppression only when an independent permanent, address-specific signal or the applicable policy supports it.
Common causes
- The remote system was busy and did not answer the connection attempt.
- The remote system was temporarily unable to accept a connection.
Diagnostic steps
- Confirm the enhanced code is exactly 4.4.1 and the basic reply is 4xx.
- Retain the raw response, attempt time, targeted remote system, and connection log.
- Ask the recipient-system administrator or provider to inspect whether that remote system could accept connections at that time.
- Compare bounded retry outcomes and stop when the configured limit is reached.
Actions by owner
Sender administrator
- Queue the message for bounded retry with backoff and keep the raw response and connection log.
- Group recurring results by remote system and provide the evidence after the retry limit.
Recipient administrator
- Inspect the remote system's availability at the failed-attempt time.
- Clear a confirmed temporary connection-handling condition and verify a controlled retry.
Provider
- Inspect service and connection logs without assigning a cause from the code alone.
- Restore confirmed connection capacity and preserve the exact status code for sender retry control.
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.
- SMTP Enhanced Status Codes — IANA registry of enhanced mail system status codes.
- RFC 5248 — A Registry for SMTP Enhanced Mail System Status Codes — Creates and governs the IANA enhanced status code registry.
- RFC 2034 — SMTP Service Extension for Returning Enhanced Error Codes — Defines how SMTP returns enhanced status codes to clients.
- RFC 3463 — Enhanced Mail System Status Codes — Defines the class/subject/detail model for enhanced status codes.
Last verified:
