SMTP Error 442 - Connection dropped during transmission — a tool label, not a real code. | Warmup Inbox

The short answer

SMTP 442 is not a real RFC reply code. It is a label some mail tools and WordPress SMTP plugins show for "connection dropped during transmission." The standards-based equivalent is a 421 reply with enhanced status 4.4.2 ("Bad connection"). It is transient: the session died mid-send from a timeout, network blip, or throttling. Retry, raise SMTP timeouts, and stabilize the connection.

Quick fix

Retry, raise SMTP timeouts, and stabilize the network path.

4 - Temporary. Safe to retry. The message is not lost and most servers retry automatically.

What it means

RFC 5321 defines no 442 reply code. Its codes include 421, 450, 451, and 452. "442" is a label that some clients, hosting panels, and plugins (WP Mail SMTP, SendLayer) show when a connection drops mid-transmission. The closest standard equivalent is a 421 reply paired with the enhanced status 4.4.2 ("Bad connection"), which RFC 3463 describes as an outbound connection that opened but could not finish the transaction because of a timeout or poor connection quality. The leading 4 marks it transient: the same message can be retried.

Common causes

Network instability or packet loss
The most frequent cause of a mid-transmission drop between your sender and the receiving server.
Timeouts
Your client or the server closes the channel before the DATA phase completes. Large messages over a slow link make this worse.
Receiving-server throttling or overload
Busy servers drop connections under load and expect a retry.
MTU or packet fragmentation
On some networks oversized packets stall the data stream; reducing MTU on the sending host has resolved 421 4.4.2 cases.
Intermediary interference
A firewall, NAT device, antivirus proxy, or VPN that idles out or resets the connection mid-stream.

How to fix it

Wait and retry
A single drop is often a one-off. Resending after a short delay usually succeeds.
Stabilize the network
Confirm a steady connection from the sending host, and verify the outbound port (465 or 587) is not being reset by a firewall or ISP.
Increase SMTP timeouts
Raise connection, greeting, and socket timeouts so the session is not killed before DATA finishes. In Nodemailer set connectionTimeout, greetingTimeout, and socketTimeout; in Python pass a larger timeout to SMTP().
Check for throttling
If drops cluster during high-volume sends, you may be hitting rate limits. Slow down or spread the send out.
Test from a clean path
Reproduce the send with antivirus proxies, VPNs, or local firewalls out of the path to find the device cutting the connection.

Paired code

A real bounce often shows both a 3-digit code and an enhanced code together. This one commonly pairs with:

X.4.2 Bad connection

Common questions

Is 442 a permanent failure?
No. The leading 4 marks it transient. The connection dropped temporarily and the same message can be retried. It maps to 4.4.2 "Bad connection", a persistent transient error.
Is 442 an official SMTP reply code?
No. It is a tool and plugin label. The standard form is a 421 reply with enhanced status 4.4.2.
What is the difference between 442 and 421 4.4.2?
They describe the same condition. 442 is the friendly label; 421 4.4.2 is the standards-based reply and enhanced code.

All SMTP error codes

Most rejections come back to sender reputation.

Blocklists, auth failures, and policy blocks are what warmup prevents. Warm up your domain so your mail is trusted before you hit send.