SMTP error 421 4.3.2: service shutting down at connection time

SMTP error 421 4.3.2 means the server is shutting down and is closing the transmission

channel, refusing the connection before any mail transaction can begin. The enhanced code 4.3.2

is RFC 3463's "system not accepting network messages" - commonly used, as here, specifically for a

deliberate, graceful service shutdown rather than an unexpected failure. This is distinct from

451 4.3.2 (covered separately), which is the mid-transaction version of the same underlying

condition.

Fault: the receiving system, entirely, and entirely intentional on its part - a scheduled

event, not a malfunction.

Why it happens

• A scheduled restart or deployment of the receiving MTA process. Mail servers are commonly

restarted during low-traffic maintenance windows, and a well-behaved MTA refuses new

connections gracefully during the brief restart rather than accepting them and then failing

mid-transaction.

• A graceful shutdown triggered by an orchestration system (a container being drained before

termination, a load balancer removing a node from rotation) specifically designed to refuse new

work cleanly rather than abruptly dropping active connections.

• Per-source connection limits being enforced via a shutdown-style refusal on some

configurations, where exceeding a limit triggers the same reply text as a genuine shutdown even

though the service itself is healthy.

• A planned decommissioning of a specific mail relay, where the refusal is permanent in

practice (the server will not come back) even though the reply class is technically transient.

The transcript

$ swaks --to test@mailpilots.in --server mx.example.net
-> (connects)
<- 421 4.3.2 mx.example.net Service shutting down, closing connection
<<< CONNECTION CLOSED BY SERVER

Exactly like a generic 421 4.3.0, the connection closes before any EHLO exchange - but the

more specific enhanced code and the literal "shutting down" text here confirm this is a

deliberate, scheduled event rather than an unexplained failure.

How the big three word it

Diagnose it

$ for i in 1 2 3; do
    swaks --to test@mailpilots.in --server mx.example.net 2>&1 | tail -2
    sleep 120
  done
<- 421 4.3.2 mx.example.net Service shutting down, closing connection
<- 250 2.1.5 Recipient OK

A failure that clears within a couple of minutes is the expected signature of a genuine,

scheduled restart - most maintenance windows of this kind are measured in seconds to a few

minutes, not hours.

The fix, in order

1. Retry after a short wait - a few minutes is typically sufficient for a scheduled restart

to complete.

1. Do not change any configuration on your side. This condition has nothing to do with your

sending setup; it is purely about the receiving system's own maintenance timing.

1. If the condition persists beyond fifteen minutes or so, check whether the destination

domain's mail service has a known, longer maintenance window published, or escalate to

checking its MX records in case of an actual decommissioning.

1. If this is happening against a relay you administer, confirm your own deployment process

is correctly draining connections rather than dropping active transactions mid-flight -

refusing cleanly at connection time, as this code does, is the better-behaved pattern to aim

for.

1. Log the recurrence pattern if a specific destination shows this repeatedly at predictable

intervals, which can indicate a recurring maintenance schedule worth planning sends around.

What not to do

• Do not treat this as a block or a reputation signal. It is purely about timing; your

sending history and configuration play no role.

• Do not retry in a tight loop during the shutdown window. It adds no value while the service

is actively down and simply produces more identical replies.

• Do not confuse this with the mid-transaction `451 4.3.2` variant. That one happens after a

transaction is already underway and has a slightly different practical implication - this one

happens before anything is exchanged at all.

• **Do not escalate immediately to assuming the destination domain's mail service is permanently

gone.** A brief shutdown-and-restart is overwhelmingly more common than a genuine

decommissioning.

MailPilot's queue retry logic treats connection-level 421 refusals as exactly what they are -

a signal to wait and retry shortly - rather than letting a brief, scheduled maintenance window on

the receiving side register as a delivery problem on the sending mailbox's reputation.