SMTP Error 421

SMTP 421 is the reply code for "Service not available, closing transmission channel", defined in RFC 5321 §4.2.3. The receiving server accepted your TCP connection and then decided to end the SMTP session — it may send 421 in response to any command if it knows it must shut the connection down. Because it is a 4yz transient negative reply, the message has not been rejected permanently; the correct behavior is to queue and retry.

What does SMTP Error 421 mean?

421 is a temporary (transient) status. RFC 5321 §4.2.1 splits 4xx and 5xx: a 4yz reply means "the command was not accepted and the requested action did not occur," but "the error condition is temporary and the action may be requested again." So unlike a permanent 5xx bounce, a 421 should be retried later — not surfaced to a user as a hard failure.

You will often see an enhanced status code (RFC 3463) attached, which tells you why the session closed:

• 421 4.3.2 — system not accepting network messages (server overloaded / shutting down)
• 421 4.7.0 — RFC 3463 defines this generically as an undefined security/policy status; in practice Gmail reuses it to signal temporary rate-limiting or reputation throttling, a provider convention rather than the RFC's literal meaning
• 421 4.4.5 — system congestion

What causes SMTP Error 421?

The original page's three causes are essentially correct — 421 is overwhelmingly a server-side temporary condition. The most common triggers:

1. Too many concurrent connections from your host. Amazon SES returns exactly 421 Too many concurrent SMTP connections when there are currently too many open connections to the SMTP server (AWS SES SMTP response codes).
2. Stale or long-lived connections dropped mid-session. AWS recommends opening a new SMTP connection after a fixed number of messages or a set connection age, since the SES SMTP endpoint sits behind a load-balanced EC2 fleet that periodically recycles instances — a stale connection can be dropped mid-session (potentially surfacing as a 421 or a connection reset), though AWS does not publish a specific "421 message-count-exceeded" error string.
3. Rate / reputation throttling. Gmail and Google Workspace return 421 4.7.0 ... Try again later when they detect an unusual sending rate or low sender reputation and temporarily rate-limit your IP (Gmail sender guidelines).
4. Server overload or scheduled maintenance. The server is busy or shutting down and refuses to continue the conversation.

Note 421 is server-initiated session teardown, which is what distinguishes it from a per-recipient deferral like 450/451: 421 closes the whole channel, so every message in that session is affected.

How do I fix SMTP Error 421?

1. Retry with backoff — do not hard-bounce. Per RFC 5321 §4.5.4, an SMTP client SHOULD requeue and attempt the destination again later. AWS recommends progressively longer waits (e.g. 5s → 10s → 30s, then 20 minutes) (SES retry guidance). Most production senders (and Courier) already queue and retry transient 4xx automatically — confirm your client isn't treating 421 as permanent.

2. Cap concurrent connections. If the text says "too many connections," reduce parallel SMTP connections to stay within the provider's limit. Check your relay's documented connection ceiling.

3. Recycle long-lived sessions. Proactively close and reopen the connection after a set number of messages or a set connection age (SES advises this since their endpoints sit behind a load balancer and rotate instances, which can otherwise drop a stale connection mid-session).

4. For Gmail 421 4.7.0 rate-limiting: pause that lane ~10+ minutes, resume with a single connection, and add concurrency back gradually. Address the root cause — sending volume spikes and poor reputation — via authentication (SPF/DKIM/DMARC) and Google Postmaster Tools.

5. Check provider quotas. Log into your SMTP relay (SendGrid, SES, Mailgun, etc.) and verify you haven't exceeded a sending-rate or daily quota that's surfacing as a 421.

If you send through Courier, transient 421 responses are retried on your behalf and the final delivery state is reflected in the message logs — you don't need to build your own backoff loop.