The short answer

SMTP 421 is a temporary "Service not available, closing transmission channel" reply. The server accepted your connection but is ending the session — usually too many concurrent connections, rate limits, or maintenance. It is a 4xx temporary failure, so queue and retry with backoff; do not treat it as a permanent bounce.

Quick fix

Back off and retry later; if it is constant, check you are not exceeding connection or sending limits.

4 - Temporary. Safe to retry. The message is not lost and most servers retry automatically.

What it means

421 is a transient reply the server can send to any command when it needs to shut the connection down. Because it is a 4xx code the message is not permanently rejected — RFC 5321 is explicit that a client should requeue and try again later. What sets 421 apart from a per-recipient deferral like 450/451 is that it tears down the whole channel, so every message in that session is affected. An enhanced code often tells you why: 4.3.2 (server overloaded / not accepting), 4.7.0 (Gmail reuses this for rate-limiting or reputation throttling), 4.4.5 (congestion).

Common causes

• Too many concurrent connections
  Amazon SES returns "421 Too many concurrent SMTP connections" when you exceed its open-connection limit — the commonest cause on bulk sending.

• Stale or long-lived connections dropped
  Load-balanced endpoints like SES recycle instances, so a connection held too long can be dropped mid-session.

• Rate or reputation throttling
  Gmail/Workspace return "421 4.7.0 ... Try again later" when they see an unusual rate or low sender reputation.

• Server overload or maintenance
  The server is busy or shutting down and refuses to continue the conversation.

How to fix it

1. Retry with backoff — do not hard-bounce
   Requeue and try again on a growing delay (for example 5s → 10s → 30s → 20 min). Confirm your client is not treating 421 as permanent.

2. Cap concurrent connections
   If the text says "too many connections", reduce parallel SMTP connections to stay under the provider's ceiling.

3. Recycle long-lived sessions
   Close and reopen the connection after a set number of messages or a set age, so a stale one is not dropped mid-send.

4. For Gmail 4.7.0 rate-limiting
   Pause that lane 10+ minutes, resume with a single connection, and add concurrency back slowly. Fix the root cause — volume spikes and reputation — with SPF/DKIM/DMARC and Postmaster Tools.

5. Check provider quotas
   Log into your relay (SES, SendGrid, Mailgun, etc.) and confirm you have not hit a rate or daily-sending limit surfacing as a 421.

Paired code

A real bounce often shows both a 3-digit code and an enhanced code together. This one commonly pairs with:

• X.7.0Other or undefined security status

Common questions

• Is 421 permanent, or should I retry?
  It is transient. The client should requeue and retry with a sensible backoff. Treating 421 as a hard bounce is a misconfiguration.

• What does "421 4.7.0 Try again later" from Gmail mean?
  Google is temporarily rate-limiting your IP, usually from a sending spike or weak reputation. Slow down, send on one connection, and work on authentication and reputation.

• Why does SES return 421 after many emails on one connection?
  Its endpoints sit behind a load balancer that recycles instances, so a long-held connection can be dropped. Recycle connections after a set count or age.

Related codes

• 450Mailbox unavailable (temporary).

• 451Requested action aborted — local error in processing.

• 452Insufficient system storage or too many recipients.

• 420TCP read/write timeout — non-standard, mostly GroupWise.

• X.7.0Other or undefined security status

• All SMTP error codes

Most rejections come back to sender reputation.

Blocklists, auth failures, and policy blocks are what warmup prevents. Warm up your domain so your mail is trusted before you hit send.