SMTP 421: The Message Is Delayed, Not Rejected

421 is a temporary failure. The receiving server is telling you it cannot continue right now, and that it is closing the connection. The recipient address is not the problem. Keep the message queued and retry it. The 421 is the three-digit reply code; anything after it, like 4.7.28, is the enhanced status code naming the cause.

The spec is unambiguous on both halves. RFC 5321 defines 421 as "<domain> Service not available, closing transmission channel", adding that "this may be a reply to any command if the service knows it must shut down". RFC 3463 defines the leading 4 as a persistent transient failure: "the message as sent is valid", and "sending in the future may be successful".

Why did the server close the connection?

Because closing was the point. RFC 5321 says a server must not intentionally close a connection under normal operation except in three cases: after a QUIT and a 221, after a timeout waiting on the client, or after deciding it must shut down and answering 421. It is one of exactly three legitimate server-side session kills, and it is not tied to any command. The RFC lists it with 500 and 501 as a code any command can return, and lets a server send it asynchronously, "on the assumption that the client will receive it after the next command is issued". So it can arrive at connection open, after RCPT TO, or mid-DATA, meaning the same thing each time.

One detail matters in practice. RFC 5321 names 220, 221, 251, 421 and 551 as the five codes whose message text, not just the number, is meant to be parsed by machines. With 421, the number tells you almost nothing. The text tells you everything.

What triggers a 421 at Gmail?

Google's own error table lists more 421 rows than any other provider documents, in three groups.

Capacity: 421 4.3.0 Temporary System Problem. Try again later. and 421 4.4.5 Server busy, try again later.

Policy and connection state, mostly under the catch-all 4.7.0: connection expired, IP not in the whitelist for the recipient domain, TLS required for the recipient domain, low reputation on the sending IP, low reputation on the sending domain, suspicious content or links, and the DNS case Google words as "the IP address sending this message does not have a PTR record, or the corresponding forward DNS entry does not point to the sending IP". Authentication checks get their own codes: 4.7.26 for mail with neither SPF nor DKIM, 4.7.27 for SPF, 4.7.29 for no TLS, 4.7.30 for DKIM, 4.7.40 for a missing DMARC record or policy.

Rate limiting, under 4.7.28: "Gmail has detected an unusual rate of email", with variants keyed to the sending IP, the IP netblock, the DKIM domain, the SPF domain, the URL domain, and messages sharing one Message-ID:. Gmail appends gsmtp to every error, and gcdp when a Workspace administrator's own rule fired.

One documented exception to the temporary reading is worth knowing. Google's table carries a 421 5.7.32 row for a From: header not aligned with the authenticated SPF or DKIM organizational domain, described as blocked, directly above a 421 4.7.32 row treating the same problem as a rate limit. A class 5 enhanced code inside a 421 means retrying will not clear it. Google documents this alone, for that one failure type. It is not a general pattern.

What triggers a 421 at Microsoft 365 or Yahoo?

Microsoft is narrower than its reputation suggests. Its Exchange Online NDR and SMTP error reference documents exactly one 421 string: 421 4.3.240, "the maximum number of concurrent server connections has exceeded a per authenticated source limit, closing transmission channel", raised above 250 simultaneous authenticated connections and scoped to the High Volume Email service. Exchange Online's ordinary connection throttling is a different code. Microsoft documents up to three concurrent submission connections, and a fourth gets 432 4.3.2 Concurrent connections limit exceeded. Debugging a general Exchange Online throttle means searching your logs for 432, not 421.

Yahoo does not separate the two codes at all. Its Sender Hub files 421 and 451 under one "4XX temporary errors" heading and lists the causes together: unusual traffic patterns from your sending IP, spam-like characteristics, complaints from Yahoo users, busy Yahoo servers, a dynamic deprioritization on your server, a temporarily unavailable name server, and authentication results that could not be determined because of a temporary error. Its instruction is one line: "If you encounter 4XX errors when trying to send an email to Yahoo, you may retry sending at a later time."

Which Postfix settings emit a 421?

Postfix's smtpd(8) manual documents the directives and their defaults but does not print reply strings, so it will not tell you which of them answers 421. The literal text below comes from Postfix's own source.

The directives are the part an admin needs. smtpd_timeout is 300 seconds normally and 10 under overload. smtpd_hard_error_limit is 20 normally and 1 under overload, the session error count at which Postfix gives up on a client. smtpd_client_connection_count_limit (50) and smtpd_client_connection_rate_limit (0, meaning off) are enforced with the anvil(8) service. Under load, then, Postfix tightens to a 10 second timeout and a hard error limit of one, so a sudden run of 421s from your own server may just be your overload mode working.

In the source those map to 421 4.4.2 ... Error: timeout exceeded, 421 4.7.0 ... Error: too many errors, and 421 4.7.0 ... Error: too many connections from the client address, with the count limit and the rate limit producing that same last string. Postfix also emits 421 for the new-TLS-session rate (4.7.0), a missing or untrusted mandatory client certificate (4.7.1), and internal faults such as losing contact with cleanup(8) (4.3.0).

The exception is a 421 raised at connect time, before EHLO, by a milter. It goes out bare, as 421 <hostname> Service unavailable - try again later, with no enhanced status code, consistent with the RFC 3463 convention Postfix quotes in its own source comments.

What should a sender do?

Requeue, retry, and leave the address alone.

On timing, only the RFC has numbers. RFC 5321 says the retry interval should be at least 30 minutes, that "the give-up time generally needs to be at least 4-5 days", and that experience favours two connection attempts in the first hour then one every two or three hours after that. That is general 4xx guidance rather than anything written for 421, and no major provider publishes a retry cadence for this code.

Then read the string. A 4.7.28 rate limit, a 4.7.26 missing SPF and DKIM, and a 4.7.0 PTR mismatch are three unrelated fixes behind one number. If the connection died with no reply at all, RFC 5321 tells clients to treat the transaction as if a 451 had been received.

What should a receiving admin check?

Which of your own limits fired, because several of them share one string. Concurrency and connection rate both produce "too many connections", so check that anvil(8)-backed pair together. Then the hard error limit, for clients erroring rather than delivering, then smtpd_timeout for stalled ones, then the TLS session rate and any mandatory client certificate policy. A 421 carrying no enhanced status code points at a milter at connect stage. A 421 4.3.0 is Postfix reporting its own local fault, so check the queue and cleanup(8).

Which codes get confused with 421?

• 450. RFC 5321 words it as "requested mail action not taken: mailbox unavailable (e.g., mailbox busy or temporarily blocked for policy reasons)". Temporary like 421, but about one mailbox rather than the service, and the session stays open.
• 451. "Requested action aborted: local error in processing". Also temporary, also session-scoped rather than connection-closing. Yahoo treats it and 421 as one category, and RFC 5321 makes it the code a client should assume when a connection dies unexplained.
• The 4.5.3 family. "Too many recipients" in RFC 3463, whose remedy is splitting the message and delivering the rest on a later attempt. A command-sequencing problem, not an availability problem.
• The 5xx class. Permanent. RFC 3463 defines class 5 as not likely to be resolved by resending in the current form, and Yahoo tells senders outright not to retry a 5xx. The permanent counterpart to 421 at connection open is 554, glossed in RFC 5321 as "No SMTP service here". A policy block and a nonexistent mailbox both live in that class, and both mean stop, which is exactly what 421 does not mean.

The full SMTP reply code list covers the rest.