Is a 4.4.2 a block on my server?

Not necessarily. Most are load or network problems, but a silent drop right after connect can be a reputation block in disguise.

Will my message be delivered twice after a dropped connection?

It can happen if the connection broke after the server accepted the data but before it confirmed. RFC 1047 describes this duplicate risk.

4.4.2 deferral: bad connection

4.4.2Bad connectionTemporary: the sender retries

Example

dsn=4.4.2, status=deferred (lost connection with mx.example.com[203.0.113.10] while receiving the initial server greeting)

What it means

X.4.2 is "Bad connection" in RFC 3463. The TCP connection to the recipient’s mail server opened, but it broke before the transaction finished: the other side closed it, it timed out, or TLS negotiation fell apart. The example is Postfix’s log line when the server accepted the TCP connection and then never sent a greeting.

Your own server usually generates this code, because a dropped connection leaves nothing to report from the remote end. Some receivers also send 421 4.4.2 deliberately before closing, for instance when a connection idles too long. The difference from 4.4.1 is that a connection did exist, and from 4.7.x deferrals that no policy reason was stated.

Connection drops are treated as temporary, so 4.4.2 is the normal form and your queue retries. A 5.4.2 is unusual and normally appears only when the sending MTA records the last error as permanent at queue expiry.

Likely causes

The receiving server is overloaded and drops connections, or applies tarpitting and closes slow clients.
A firewall, load balancer, or SMTP proxy in the path resets idle or large transfers.
TLS negotiation failed (an old protocol version, a cipher mismatch, or a broken certificate chain) and the peer closed the connection.
The receiver silently drops connections from IPs it considers suspicious instead of sending a clear rejection.
MTU or packet loss problems that kill the session during the DATA transfer of larger messages.

How to fix it

Check where the session broke. Postfix and Exim log the stage (greeting, EHLO, STARTTLS, DATA), which points at the cause.
If it breaks at STARTTLS, test the recipient’s TLS setup and make sure your server supports TLS 1.2 or later with modern ciphers.
If it breaks during DATA on large messages only, look for MTU or firewall issues between the hosts.
If it breaks right after connect, check whether your sending IP is listed on a blocklist the receiver uses to drop connections.
Leave the message queued; retries often succeed once load on the remote side falls.

Checks that apply

Your domain or sending IP (fills in the checks below)

SMTP Diagnostics Runs the greeting, EHLO, and STARTTLS steps against the recipient server and shows exactly where it stalls.
Blacklist Check Checks your sending IP on major blocklists, since some receivers drop listed IPs without a reply.
TCP Port Test Confirms port 25 opens at all, separating a bad connection from no connection.

FAQ

Is a 4.4.2 a block on my server?: Not necessarily. Most are load or network problems, but a silent drop right after connect can be a reputation block in disguise.
Will my message be delivered twice after a dropped connection?: It can happen if the connection broke after the server accepted the data but before it confirmed. RFC 1047 describes this duplicate risk.

All 191 bounce codes