No answer from host — connection timeout
Production Risk
Medium — sustained timeouts indicate infrastructure problems that need investigation.
The sending MTA attempted to connect to the destination mail server but received no response within the allowed timeout period. This is typically a transient network condition.
- 1The destination mail server is temporarily unreachable due to network congestion or maintenance.
- 2A firewall is silently dropping connections on port 25.
- 3The destination server is overloaded and not accepting new connections.
The sending MTA's TCP connection attempt to the destination MX host times out.
# MTA log entry: connect to mail.example.com[192.0.2.1]:25: Connection timed out # Bounce DSN enhanced code: 450 4.4.1 No answer from host
expected output
450 4.4.1 or 550 5.4.1 ...
Fix 1
Retry with exponential back-off
WHEN Receiving a transient 4.4.1
# Standard MTA retry schedule (Postfix example in main.cf): maximal_queue_lifetime = 5d minimal_backoff_time = 300s maximal_backoff_time = 4000s
Why this works
Transient connection failures often resolve within hours. Exponential back-off avoids hammering the destination.
Fix 2
Check firewall rules on port 25
WHEN Consistently seeing timeouts to specific destinations
# Test connectivity manually: telnet mail.example.com 25 # Or using nc: nc -zv mail.example.com 25
Why this works
Diagnosing whether the issue is local (outbound port 25 blocked by ISP) or remote (destination server down).
✕ Immediately give up on a 4.4.1
This is a transient failure — the destination server may become available again shortly.
RFC 3463 — Enhanced Mail System Status Codes
Content generated with AI assistance and reviewed for accuracy. Found an error? hello@errcodes.dev