SMTP error 4.4.2 Bad connection

What SMTP error 4.4.2 means

The conversation began and then broke. The connection was open, both servers had exchanged commands, and it fell over before the message was accepted, normally reported as 421 4.4.2. Where 4.4.1 is silence before the greeting, this is a session that dies in the middle. Large messages, idle timeouts and firewalls that inspect SMTP are the usual reasons, and the registry allows it only as transient, so the sender keeps trying.

Network and routing status
Sent by Either end of a session that started successfully and then collapsed
Common

What SMTP error 4.4.2 Bad connection actually means

The definition names two mechanisms, a time-out and inadequate connection quality, and both show up in practice. The 421 reply it travels with is the SMTP way of saying the service is closing the channel, so the message is frequently that the far end has decided to end the session rather than that the wire failed. What makes this code awkward is that it fails partway through work already done: the greeting succeeded, the recipients may have been accepted, and the failure lands during or after the message body. That pattern is what points you at size, timing and middleboxes rather than at addressing or policy.

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.
— RFC 3463

How 4.4.2 appears in a bounce

A server reporting this condition sends it alongside a three-digit reply code, and a bounce prints the two together. The registry lists 421 4.4.2 as the pairing for this status.

The leading 4 is the server's verdict rather than part of the code's identity: it marks this as a temporary failure, which means the sending server is still retrying.

What causes SMTP error 4.4.2 on a business phone system

An SMTP-inspecting firewall interfering with the sessionFeatures variously called SMTP fixup, ESMTP inspection or mail protection on ASA, SonicWall and FortiGate hardware rewrite the conversation as it passes. They mangle capability lists and break STARTTLS, and the session dies once something no longer parses.
An idle timeout part way through the transactionReceivers allow a limited pause between commands. A sending application that stalls while it fetches the next chunk of a message, or a slow scan of a large attachment, can exceed that and have the channel closed underneath it.
MTU or fragmentation problems on the pathOver a VPN tunnel or a PPPoE broadband service the usable packet size is smaller than standard. Small command packets pass, the large data transfer does not, and if ICMP is blocked the two ends never discover why. Sessions consistently die during DATA.
A very large message timing out mid-transferA 30 MB attachment over a thin uplink can take longer than the receiver is prepared to hold the connection open for. The transfer restarts from the beginning on every retry, so it fails at the same point each time.
The receiving server restarting or shedding sessionsA service restart, a failover between nodes or a deliberate limit on concurrent connections closes sessions already in progress. This one genuinely is temporary and clears without anyone doing anything.

How to fix SMTP error 4.4.2

Check whether failures track message sizeSend a plain text message, then one with a 20 MB attachment, to the same recipient. If small messages sail through and large ones die every time, you are looking at MTU or a transfer timeout rather than anything to do with mail.
Turn off SMTP inspection on the firewallThis single change resolves a large share of mid-session failures, particularly where TLS is involved. Modern mail is encrypted in transit and the firewall gains nothing by trying to read it.
Clamp MSS on VPN and PPPoE interfacesWhere the path includes a tunnel, setting the maximum segment size on the interface prevents oversized packets being formed at all. Test first by sending progressively larger packets with fragmentation disabled to find the real limit.
Walk an SMTP session by hand and watch where it diesIssuing the commands manually shows you the exact point of failure: at the greeting, after STARTTLS, or during the data transfer. Each of those points to a different cause and saves guessing.
Review connection limits if the failing server is yoursReceive connectors carry limits on concurrent connections, connections per source and session duration. A busy sender hitting a low limit gets its sessions closed with a 421, which looks like a network fault and is not.

Fixing the underlying problem

This page explains the code. These guides walk through the fix in detail.

Questions about SMTP error 4.4.2

Does 421 4.4.2 mean we are being blocked?

No. A block is stated plainly and permanently with a 5xx reply and a reason, often naming a blocklist. A 421 is the far end closing the channel, which is a capacity, timing or path problem. If you were genuinely blocked you would be told so consistently rather than getting through some of the time.

Only emails with big attachments fail. Why would size matter?

Because size changes how long the connection has to stay healthy. A short message finishes in a moment, while a large one exposes any packet-size or timeout problem on the path. Test the same recipient with a small message to confirm, then look at MTU on any VPN or broadband link in the way.

Our accounts system sends invoices and they all fail this way.

Applications that hold a connection open while they generate each message are the classic trigger, because the pause between commands exceeds the receiver's patience. Have the application connect, send, and disconnect per message, or relay it through a mail server that will queue on its behalf.

Related SMTP status codes

Source. SMTP error 4.4.2 Bad connection is defined in RFC 3463 and registered in the IANA SMTP Enhanced Status Codes registry. The causes and fixes above are drawn from our own experience supporting UK business email systems.

All Email delivery & SMTP codes