SMTP error 421 4.3.0: generic temporary server error at connection

SMTP error 421 4.3.0 closes the connection immediately after reporting a generic, temporary

mail-system failure. A 421 is always a connection-level reply: the server is refusing to

continue the session at all, rather than rejecting one specific command within it. The enhanced

code 4.3.0 is RFC 3463's "other or undefined mail system status" - the server has a problem but

has not classified it further.

Fault: the receiving system, transiently. This tells you almost nothing about cause beyond

"something is currently wrong there." Retry later with no changes.

Why it happens

• The receiving MTA process is restarting or redeploying at the exact moment your connection

arrived.

• **A dependency the server needs during the connection phase (DNSBL lookup, reverse-DNS check,

greeting banner generation) is failing or timing out**, and the server's safe response to its

own internal failure is to refuse the whole session rather than continue in an unknown state.

• Resource exhaustion at the process or connection-pool level on the receiving host -

distinct from the queue/disk exhaustion that produces 454 4.3.0 mid-transaction, this happens

before any transaction detail is even exchanged.

• A load balancer or front-end proxy for the mail cluster is unhealthy, closing connections

before they reach a working backend node.

Because this failure happens before any command is exchanged, there is no further detail to

extract from your own side of the connection - the server has told you everything it is going to

tell you in that one line. Confirming the cause, if you need to, means either waiting for the

condition to clear or checking the receiving system's own status reporting, not inspecting your

own request further.

The transcript

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

No EHLO was even exchanged - the server closed the channel in its very first line, which is

the signature of a 421: whatever is wrong, it was known before your session's first command.

How the big three word it

Diagnose it

Since this happens before any transaction detail, your only sender-side diagnostic is

repetition and timing:

$ for i in 1 2 3 4; do
    date; swaks --to test@mailpilots.in --server mx.example.net 2>&1 | tail -2
    sleep 300
  done
Mon Oct 14 09:00:01 UTC 2026
<- 421 4.3.0 mx.example.net Service not available
Mon Oct 14 09:05:02 UTC 2026
<- 250 2.1.5 Recipient OK

A failure that clears within a few retries at five-minute spacing confirms a brief, self-resolving

outage rather than a sustained block - a sustained block typically escalates to a more specific

code, not a repeating generic 421.

The fix, in order

1. Do nothing to your own configuration on the first occurrence. This is the server's

problem, declared before it even read anything you sent.

1. Let your MTA's queue retry on its normal schedule.
2. If the same destination domain returns `421 4.3.0` for more than a few hours, check that

domain's public status page or MX history for a known outage.

1. If you administer the receiving side, check your mail cluster's load balancer health and

the MTA process's own resource usage immediately - this is the most common generic symptom of

both.

1. Escalate to the recipient via another channel only if the pattern persists for days, since

at that point it may indicate a longer outage worth flagging to them directly.

What not to do

• Do not change SPF, DKIM, or any sending configuration. None of that is evaluated before the

connection-level failure occurs.

• Do not retry aggressively in a tight loop. It adds load to a system that is already

reporting trouble, and some receivers will escalate a repeated-connection pattern into an

explicit rate limit.

• Do not interpret this as a block on your domain or IP. A targeted block almost always

carries more specific text (a reputation message, a reference number); a bare generic 4.3.0

is evidence of a broad, undirected problem.

• Do not suppress the recipient. No recipient-specific information was ever exchanged.

MailPilot logs the exact reply and timestamp for every connection attempt, so a cluster of

generic 421 4.3.0 events against one destination domain is visible as a provider-side outage

pattern rather than something that gets misread as a problem with your own sending reputation.