SMTP error 421 4.4.5: server congestion, connection refused

SMTP error 421 4.4.5 means the receiving server is refusing the connection itself because it

has reached a capacity limit - total throughput, connection count, or per-source concurrency. The

enhanced code 4.4.5 maps to "insufficient channel resources" in RFC 3463's network/routing

family: this is a resource ceiling, not a content or policy judgement.

Fault: split, depending on whose capacity. Sometimes the receiving server's overall

infrastructure is genuinely overloaded (not about you at all); sometimes it is your own sending

pattern exceeding a per-source connection limit the receiver enforces (entirely about you).

Why it happens

• The receiver's mail cluster is at its global connection ceiling, often during a traffic

spike unrelated to any single sender - a major news event driving mail volume, or a scheduled

maintenance window running with reduced capacity.

• **You are opening more simultaneous connections to one receiving domain than its per-source

limit allows.** Most large receivers cap concurrent connections per sending IP specifically to

prevent exactly this kind of self-inflicted congestion.

• A burst-sending pattern - sending a large batch all at once rather than spreading it over

time - can trip a per-source throughput ceiling even when your daily volume is well within any

published limit.

• Shared infrastructure: if you share an IP or sending platform with other senders, their

concurrent connections count against the same per-source ceiling the receiver sees.

Unlike a rate limit measured in messages per hour, a connection-concurrency ceiling is measured

in simultaneous open sockets at any given instant, which means a sending pattern that looks

perfectly reasonable on a daily-volume chart can still trip this error if too much of that volume

is compressed into the same few seconds.

The transcript

$ for i in $(seq 1 20); do
    swaks --to "test$i@mailpilots.in" --server mx.example.net &
  done; wait
...
<- 421 4.4.5 mx.example.net Insufficient system resources, try again later
<- 421 4.4.5 mx.example.net Insufficient system resources, try again later
...

Twenty simultaneous connections from one source are exactly the pattern most receivers' per-IP

concurrency limits are designed to refuse.

How the big three word it

Diagnose it

$ netstat -an | grep ':25\|:587' | grep ESTABLISHED | wc -l
24

If your own sending infrastructure shows a high count of simultaneously open connections to one

destination domain, that is your actionable lever - lowering it is entirely within your control,

unlike a receiver-side capacity event.

$ ss -tn dst mx.example.net:25 | wc -l
24

The fix, in order

1. Reduce per-destination concurrency. Cap simultaneous connections to any single receiving

domain to a conservative number (commonly in the single digits for most sending platforms)

rather than opening as many as your sending volume would otherwise permit.

1. Spread large batches over time instead of firing them all at once - a slower, steady send

rate is less likely to trip either side's concurrency or throughput ceiling.

1. Implement exponential backoff on `421` specifically, distinct from your backoff on

content-related 5xx errors, since this condition clears with time and lower concurrency, not

with any change to the message.

1. If you share sending infrastructure with others, check whether their concurrent connection

usage is contributing to the same per-source ceiling you are hitting.

1. If the pattern persists even at low concurrency, the receiver's own infrastructure may be

the constrained side - check their public status page before assuming your configuration is at

fault.

What not to do

• Do not open more connections to compensate for slower per-connection throughput. That is

the exact behaviour this error exists to prevent, and it will make the condition worse, not

better.

• Do not treat this as a reputation signal. A capacity refusal happens before any

content or authentication evaluation.

• Do not retry immediately and repeatedly. Hammering a server that just told you it is at

capacity adds load to the exact resource that is already constrained.

• Do not confuse this with a per-recipient rate limit like 450 4.2.1. This is a

connection-level ceiling, refused before any recipient is even named.

MailPilot paces outbound connections per mailbox and per provider specifically to stay under the

concurrency ceilings large receivers enforce, which is why a well-managed warm-up schedule rarely

produces this error even as daily volume increases.