TL;DR
4.4.2 is a connection failure after connection establishment: check the transaction trace for timeout or quality evidence, retry in a controlled way, and do not turn the temporary result into recipient suppression.
What this code means
X.4.2 covers a message transaction that could not complete on an established outbound connection. Timeout and inadequate connection quality are possible causes, but the enhanced code alone cannot choose between them or assign responsibility to one endpoint.
Provider examples
421 4.4.2 Connection dropped due to SocketError451 4.4.2 Timeout - closing connection. For more information, go to About SMTP error messages. - gsmtpTechnical meaning
The connection came up but the transaction failed before completion, due to a timeout or inadequate connection quality. The detail is useful only as a persistent transient failure.
Delivery status
The class-4 prefix makes this concrete result transient. It does not prove whether the fault was at the sender, recipient, or an intermediate path.
- Class
- Temporary failure
- Retry
- Controlled retry
- Suppression
- Check the full context
Retry decision
Check current suppression state, then use idempotent bounded retries with backoff and jitter. Stop after success, a permanent result, or the configured limit; diagnose recurring failures rather than adding unbounded queue pressure.
Suppression decision
Do not suppress from 4.4.2 alone. Use the complete response, provider context, retry history, and independent permanent signals before applying recipient policy.
Common causes
- The transaction timed out after the connection was established.
- The established connection had inadequate quality for completing the transaction.
- Microsoft's documented SocketError in a deprecated-TLS hybrid flow is provider-specific, not the universal definition.
Diagnostic steps
- Confirm exactly 4.4.2 with a 4xx basic reply.
- Keep the complete response, time, endpoints, and transaction trace.
- Compare both sides' logs for timeout or quality evidence without assigning either from the code alone.
- If the response exactly matches Microsoft's SocketError example, confirm the documented hybrid TLS context before a bounded retry.
Actions by owner
Sender administrator
- Retain the connection and transaction trace, then retry with bounded backoff and idempotency.
- Group recurrence by endpoint and time and pass the evidence on after the limit.
Recipient administrator
- Inspect recipient-system logs for the failed transaction time.
- Clear a confirmed temporary condition and verify completion on a controlled attempt.
Provider
- Inspect the managed connection path and, only for the exact example, the documented Microsoft hybrid-TLS context.
- Preserve exact code and subcode so senders can control retries.
Sources
These sources define what this enhanced status code means, mainly through the IANA registry and related RFCs. When provider examples appear on the page, they come from that provider's published documentation. Follow the links to read the original wording in context.
- SMTP Enhanced Status Codes — IANA registry of enhanced mail system status codes.
- RFC 5248 — A Registry for SMTP Enhanced Mail System Status Codes — Creates and governs the IANA enhanced status code registry.
- RFC 2034 — SMTP Service Extension for Returning Enhanced Error Codes — Defines how SMTP returns enhanced status codes to clients.
- RFC 3463 — Enhanced Mail System Status Codes — Defines the class/subject/detail model for enhanced status codes.
- SocketError when sending or receiving email — Microsoft Learn troubleshooting for Exchange SocketError mail flow.
- Gmail SMTP errors and codes — Official Gmail Help table of SMTP error messages and status codes.
Last verified:
