SMTP 421 4.4.2: bad connection, timeout mid-transmission

421 4.4.2 is a 4xx temporary deferral indicating the connection to the receiving server was lost during the SMTP session — mid-handshake, mid-DATA, or waiting on a response that never came. The enhanced code 4.4.2 specifically means "connection dropped," distinct from 4.4.1 ("no answer from host," covered separately) and from reputation-based 421s like 4.7.28.

Who is at fault

Usually neither party in the sense of wrongdoing — this is typically a network-layer or server-load issue: a receiving server dropping connections under load, a firewall or load balancer timing out an idle session, or a network path problem between sender and receiver. It's rarely caused by message content or sender reputation.

The exchange

220 mx.example.com ESMTP ready
EHLO mail.yourdomain.com
250-mx.example.com
250 SIZE 35882577
MAIL FROM:<sender@yourdomain.com>
250 2.1.0 OK
RCPT TO:<recipient@example.com>
250 2.1.5 OK
DATA
354 Start mail input; end with <CRLF>.<CRLF>
[connection closed unexpectedly]
421 4.4.2 Connection dropped

How the big three word it

Diagnose it

$ telnet mx.example.com 25
$ mtr -rw mx.example.com
$ dig MX example.com +short

Run a manual telnet session to the recipient's MX host and watch where the connection stalls or drops. Check your own outbound network path with mtr or traceroute for packet loss or latency spikes at any hop.

Fix it, in order

1. Let the automatic retry happen. Your MTA's queue will retry a 421 on its normal backoff schedule — most deliver successfully on the next attempt within minutes to hours.
2. Check your own server's timeout and keep-alive settings if this recurs specifically with one provider — an aggressive local idle-timeout can itself cause premature disconnection.
3. Test the connection path manually with telnet or an SMTP test tool to see whether the drop happens at a consistent point (handshake, DATA, or after).
4. If it's consistent across many recipients, check whether your own outbound firewall, proxy, or load balancer is the one terminating idle connections too aggressively.

A cause worth checking directly: STARTTLS handshake drops

One specific trigger that shows up often enough to call out separately: the connection dropping mid-STARTTLS negotiation rather than mid-DATA. A receiving server under load can accept the initial TCP connection and EHLO cleanly, then fail or time out during the TLS handshake itself if its TLS termination layer is saturated — producing the same 421 4.4.2 reply but pointing to a different bottleneck. If your logs show the drop consistently occurring right after STARTTLS rather than after DATA, the receiving server's TLS infrastructure specifically is the constraint, not its general connection handling.

An additional diagnostic command

$ openssl s_client -starttls smtp -connect mx.example.com:25 -brief

This isolates whether the TLS handshake itself completes cleanly against that specific host, separate from the general connectivity check telnet gives you — useful for confirming a TLS-layer bottleneck versus a general connection-layer one.

Retry timing to expect

Most MTAs apply the same backoff schedule regardless of exactly where the connection dropped: an initial retry within 15 minutes to an hour, then progressively longer intervals if it recurs, typically giving up only after several days per the queue's configured maximum retry window. A single 421 4.4.2 that clears on the very next attempt is normal and not worth investigating further. A pattern recurring against the same host across many attempts over several hours is the point at which checking your own network path or the receiving host's TLS layer becomes worthwhile. Either way, 4.4.2 says nothing about message content or authentication — a connection-layer drop happens before either is ever evaluated. Many cloud load balancers and some firewalls default to a 60–90 second idle timeout on port 25 connections, which is often shorter than the time a loaded receiving server needs to complete TLS negotiation and the DATA phase together — worth checking explicitly if you control the sending infrastructure and this error clusters against multiple providers rather than one.

What not to do

• Don't treat a single 421 4.4.2 as a sign of a reputation problem. It's a connection-layer event, and conflating it with spam filtering leads you to the wrong fix.
• Don't manually force an immediate resend. Let the queue's backoff handle it — resending immediately into the same network condition often repeats the failure.
• Don't confuse this with 421 4.4.1 ("no answer from host" — the connection never established at all) — they describe different points of failure and call for different diagnostics.

MailPilot's inbox placement testing distinguishes a genuine content or authentication rejection from a connection-layer deferral like this one, so a transient network event doesn't get investigated as a deliverability problem it isn't.