Enhanced Status Code 4.4.2: Bad Connection
Enhanced Status Code 4.4.2 means “Bad Connection.” The connection was established but the transaction could not be completed. Something dropped the session partway through, most often a timeout or an idle connection being reaped.
451 4.4.2 Timeout closing connectionWhat does 4.4.2 mean?
Enhanced status code 4.4.2 means a bad connection. RFC 3463 defines it as an outbound connection that was established but was unable to complete the message transaction. The distinction from 4.4.1 matters: there the connection was never answered, here it was answered and then failed midway.
Google returns it as 451 4.4.2 with text about a timeout closing the connection. The usual causes are a session that sat idle too long between commands, a very large message that exceeded the data transfer timeout, or an intermediate device that reaped a long-lived connection it considered stale. Firewalls and NAT devices are frequent culprits because they hold connection state with their own idle timers, shorter than either mail server's.
Isolated occurrences are normal on the internet and a retry usually succeeds. A persistent pattern to one destination points at something structural: a message size near the limit, a slow content scanner adding latency mid-transaction, or a network device between you and them dropping sessions. Correlating failures against message size is the fastest way to distinguish those.
How 4.4.2 plays out
4.4.2 replyWhere 4.4.2 sits: soft vs hard bounce
| Soft bounce (4xx) | Hard bounce (5xx) | |
|---|---|---|
| Nature | Temporary | Permanent |
| SMTP class | 4xx | 5xx |
| What to do | Let it retry | Suppress the address |
| Recoverable? | Often | No |
| 4.4.2 is | ✓ this code |
Common causes of 4.4.2
- The session sat idle long enough for one side to time out
- A large message exceeded the data transfer timeout while being sent
- A firewall or NAT device reaped the connection as stale
- Packet loss or a routing change interrupted the session
- A content scanner at the receiving end stalled mid-transaction
- The receiving server restarted or was reloaded while the session was open
How to fix 4.4.2
- Correlate failures against message size, since large messages fail differently from small ones
- Check firewall and NAT idle timeouts against your MTA connection timeouts
- Reduce the number of messages sent per connection so sessions are shorter
- Confirm your MTA retries, since an isolated 4.4.2 usually succeeds on the next attempt
- Test with a small message to the same destination to rule out size as the trigger
- Look for packet loss or MTU problems on the path if failures cluster by destination