SMTP 442 "connection dropped": not a code any server actually sends

There is no SMTP reply code 442 in RFC 5321, and no major mail provider documents it as a response they send. When "442" appears in a bounce report or a deliverability dashboard, it almost always represents a connection that dropped or timed out with no SMTP reply received at all — the sending MTA or the reporting tool is assigning a local placeholder number to a "connection failed" event, not relaying a code the recipient server actually sent.

Who is at fault

Usually a network-layer condition: the connection closed before either party exchanged a meaningful SMTP reply. This can originate on either side — the receiving server closing early, a firewall or load balancer terminating the session, or a problem on your own outbound network path.

What the real event looks like

220 mx.example.com ESMTP ready
EHLO mail.yourdomain.com
250 mx.example.com
MAIL FROM:<sender@yourdomain.com>
250 2.1.0 OK
RCPT TO:<recipient@example.com>
[connection reset by peer — no SMTP reply received]

Note there is no final numeric line from the server in this transcript — that's the actual event. Some MTAs and bounce-processing tools label a raw connection failure like this with an internal code (442 among them) for logging convenience, which is where the confusion originates.

How the big three actually report connection failures

Diagnose it

$ tcpdump -i any host mx.example.com and port 25
$ openssl s_client -starttls smtp -connect mx.example.com:25

Check whether the connection is failing at the TCP handshake (never connects), during STARTTLS negotiation, or mid-SMTP-dialogue — each points to a different layer of the problem.

Fix it, in order

1. Find the raw log entry from your own MTA, not a summarised dashboard code — look for the actual reason (timeout, reset, refused).
2. Let the automatic retry queue work. A genuine connection failure is almost always transient and resolves on the next attempt.
3. If it's isolated to one recipient domain, their infrastructure may have an intermittent problem — there's limited action available beyond retrying.
4. If it's happening broadly across many domains, check your own outbound network path, firewall rules, and whether your hosting provider is blocking or throttling port 25 traffic.

A cause worth naming: which MTA actually invents this number

It's worth being specific about where a fabricated "442" tends to come from, since it changes who you should be asking for the real log. Some older Sendmail and Postfix configurations, and a number of third-party bounce-processing and deliverability-monitoring tools, use locally-assigned placeholder codes in the 4xx-shaped range for connection events that never produced a real SMTP reply, precisely because their internal data model expects every delivery attempt to have a numeric code and a bare connection failure doesn't naturally have one. If "442" is coming from your own mail server's logs, check that server's documentation for its specific placeholder-code convention. If it's coming from a third-party tool summarising bounces on your behalf, ask that vendor directly what underlying event the label represents — don't assume it's standardized across tools, because it isn't.

An additional diagnostic step

$ ss -o state syn-sent '( dport = :25 )'

Checking for connections stuck in SYN-SENT state toward port 25 on your own sending host, while a failure is actively happening, can confirm whether the problem is a connection that's simply never completing the TCP handshake at all — one specific flavor of "no reply received" that this placeholder code often represents.

What this means for your retry behavior

Because no real server ever issued a 4xx or 5xx reply, there's no RFC-defined expectation about how long to wait before retrying — your own MTA's default backoff for connection failures applies, which for most modern MTAs starts at a few minutes and extends toward several hours. Treat it exactly as you would treat a genuine 421: worth automatic retry, not worth manual intervention on a single occurrence, and worth investigating only if it clusters against one specific destination or recurs across many destinations at once.

What not to do

• Don't search for "SMTP 442 fix" and expect provider-specific guidance. No provider documents a 442 response because none of them send one.
• Don't report "error 442" to a recipient's postmaster as if it's their server's reply. Give them your actual connection log; the number itself isn't meaningful to them.
• Don't assume a connection failure is a reputation signal. It's a network event until proven otherwise by a pattern specific to one provider or domain.

MailPilot surfaces the real underlying delivery event — not a normalised placeholder code — so a genuine network failure isn't mistaken for a reputation or content problem.