SMTP Error 442

"SMTP Error 442" usually appears with the text "The connection dropped during the transmission." Before you change any settings, it helps to know what this code actually is — because it isn't a real SMTP reply code.

Is SMTP Error 442 a real RFC code?

No. The Simple Mail Transfer Protocol (RFC 5321 §4.2) defines three-digit reply codes such as 421, 450, 451, and 452 — there is no 442 in the standard. "442" is a label that some mail clients, hosting panels, and WordPress SMTP plugins (for example WP Mail SMTP and SendLayer) display when a connection drops mid-transmission.

The closest standards-based equivalent is a 421 reply paired with the enhanced status code 4.4.2. RFC 3463 defines X.4.2 as "Bad connection":

"The outbound connection was established, but was unable to complete the message transaction, either because of time-out, or inadequate connection quality. This is useful only as a persistent transient error."

The leading 4 (in both 442 and the real 421/4.4.2) marks it as a transient negative completion per RFC 5321 §4.2.1 — the command failed this time, the condition is temporary, and the same message can be retried later. So treat "442" as "the session died mid-send; try again," not as a permanent rejection of your mail.

What causes SMTP Error 442?

The connection was opened but didn't survive long enough to finish handing off the message. Common triggers:

• Network instability or packet loss between your sender and the receiving server — the most frequent cause of a mid-transmission drop.
• Timeouts. Your SMTP client gives up (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 you to retry — exactly the "persistent transient error" RFC 3463 describes.
• MTU / packet-fragmentation issues. On some networks oversized packets stall the TLS/data stream; reducing MTU on the sending host has resolved 421 4.4.2 Connection dropped cases (documented by Broadcom/Symantec for gateway scanning delays).
• Intermediary interference — a firewall, NAT device, antivirus/antispam proxy, or VPN that idles out or resets the TCP/TLS connection mid-stream.

How do I fix SMTP Error 442?

Because the error is transient, start simple and escalate:

1. Wait and retry. A single drop is often a one-off. A well-behaved sender (or your plugin's retry queue) resending after a short delay usually succeeds.
2. Stabilize the network. Confirm a steady connection from the sending host: avoid flaky Wi-Fi/VPN, and verify the outbound SMTP port (465 for implicit TLS — RFC 8314's preferred default — or 587 for STARTTLS, still valid during the transition) isn't being reset by a firewall or ISP.
3. Increase SMTP timeouts. Raise connection/greeting/socket timeouts in your mail library or plugin so the session isn't killed before DATA finishes. In Nodemailer, for example, set connectionTimeout, greetingTimeout, and socketTimeout. In Python's smtplib, pass a larger timeout to SMTP().
4. Check for throttling. If drops cluster during high-volume sends, you may be hitting the receiver's rate limits — slow your send rate or spread it out.
5. Lower the MTU on the sending server if the drop happens specifically during the DATA transfer of larger messages and other causes are ruled out.
6. Test from a clean path. Reproduce the send with antivirus/antispam proxies, VPNs, or local firewalls temporarily out of the path to isolate the device that's cutting the connection.

If you're sending through Courier, this class of transient connection drop is handled for you: Courier retries transient SMTP failures against your configured email provider, so a momentary dropped connection doesn't silently lose the message. Check the message logs in Courier to see the provider's actual response if a send doesn't go through.

Note: older guidance ties "442" to "unverified account" with specific providers like AuthSMTP. An unverified or suspended account produces an authentication/authorization rejection, not a dropped-connection condition — so don't troubleshoot account status here. Verify your credentials and account standing only if the error you actually see is an auth failure (e.g., a 535 reply), not a connection drop.