SMTP error 421: service not available, decoded by sub-code

SMTP error 421 always means the same structural thing - the server is refusing to continue

the current connection and closing it immediately, before completing whatever command was in

progress. It is always a 4xx, so it is always transient by definition. What it does not tell

you on its own is *why*, and that is entirely carried by the enhanced status code that follows it.

This is the decoder across the variants you are most likely to encounter.

Fault: varies by sub-code. Some 421 variants are entirely about the receiving server's own

health; others are a direct signal about your sending behaviour. Reading past the base code is

not optional here.

The sub-codes, compared

Why a bare, undifferentiated 421 still happens

Not every receiving system attaches a specific enhanced code. A number of smaller or

self-hosted mail systems close the connection with a generic 421 Service not available and no

enhanced status at all, particularly on older MTA versions or minimal configurations. When that

happens, the free text after the code - "too many connections," "service shutting down,"

"temporary problem" - is the only remaining signal, and it is worth reading carefully rather than

assuming the worst-case meaning.

The transcript

$ swaks --to test@mailpilots.in --server mx.example.net
-> (connects)
<- 421 mx.example.net Service not available, closing transmission channel
<<< CONNECTION CLOSED BY SERVER

No enhanced code at all here - this is a legacy-style bare 421, and without more text to go on,

the only productive response is treating it as a generic transient failure and retrying later.

How the big three word it

Diagnose it

$ for i in 1 2 3; do
    date; swaks --to test@mailpilots.in --server mx.example.net 2>&1 | tail -3
    sleep 600
  done

Running this a few times, ten minutes apart, is the fastest way to tell these variants apart in

practice: a congestion-related 421 typically clears within an hour; a rate-limit or

authentication-policy 421 typically recurs at the same volume threshold regardless of how long

you wait, until the underlying sending pattern or authentication record changes.

The fix, in order

1. Read the enhanced code first. It is the single most important piece of information in the

reply, and it determines everything that follows.

1. If the enhanced code or text points at congestion (`4.3.0`, `4.4.5`), reduce concurrency

and retry later with no other changes.

1. If it points at a rate or reputation policy (`4.7.x`), address the sending pattern or

authentication record the specific code indicates, rather than simply waiting it out.

1. If it points at a scheduled shutdown (`4.3.2`), wait for the maintenance window to pass

and retry - no configuration change is needed on your end.

1. If no enhanced code is present at all, treat it as a generic transient failure: retry on a

normal schedule and watch whether the pattern changes over time.

What not to do

• **Do not apply the fix for one 421 variant to a different one just because the base code

matches.** The base 421 is structural (connection refused, try later); the fix lives entirely

in the enhanced code and text.

• **Do not assume a bare 421 with no enhanced code is more serious than one with a specific

code.** It usually just means an older or simpler mail system, not a bigger problem.

• Do not retry aggressively regardless of which variant you have. Congestion-related variants

get worse with aggressive retrying; policy-related variants will not clear through retrying at

all.

• Do not treat every `421` as a block. The vast majority are genuinely transient and resolve

without any action beyond normal queue retry behaviour.

MailPilot logs the full reply - base code, enhanced code, and text - for every connection event,

so a run of 421s against one provider is diagnosed by which specific variant it actually was,

not lumped together as one undifferentiated category of failure.