What does 421 mean in SMTP?

Service not available, closing transmission channel. The server is ending the session rather than refusing one command — usually because it is too busy, is throttling the sender, or has made a temporary security decision. It is transient and should be retried after a delay.

How do I handle a 429 from an email verification API?

Honour the Retry-After header and back off; the limits come back in standard draft-7 rate limit headers. A 503 with the code ENGINE_CAPACITY means no sending capacity was available and the work was not done — also a retry, and also not charged.

Why do some addresses come back as unknown?

Because nothing was established. A 421 ends the conversation before the mailbox is ever named, so the result is unknown and retryable rather than a verdict. Recording that as undeliverable would delete a live mailbox because the receiving server was busy.

SMTP reply code

421 4.7.0 — service not available, closing connection

A 421 reply means the server is closing the connection rather than continuing — it is too busy, throttling you, or applying a temporary security decision. It is transient. Slow down and retry; nothing was established about the address.

The facts

Reference facts for SMTP 421 4.7.0
Field	Value
Reply code	`421`
Enhanced status code	`4.7.0`
Class	4 — transient failure
Subject	7 — security or policy status
Detail	0 — other or undefined security status
Bounce type	Soft
Should the sender retry?	Yes
Representative wording	`421 4.7.0 Too many concurrent SMTP connections; please try again later`

The representative wording is one real form of this reply. The exact string is set by the receiving server and varies between mail platforms — read the one in your own logs rather than matching on a string.

What VerifyInbox returns

What VerifyInbox returns for SMTP 421 4.7.0
Field	Value
`emailStatus`	`unknown`
`reason`	`server_busy`, or `rate_limited` when the reply text names a connection limit, throttling or "too many"
`smtpCheck`	`deferred`
`retryable`	`true` — and the provider is backed off, not just the address
Charged	No. A retryable result is never charged.

The code that ends the conversation

421 is unusual: RFC 5321 defines it as "Service not available, closing transmission channel", and it is the one reply a server may send at any point — including as its opening greeting — to say it will not continue this session. Everything else refuses a command; this refuses the conversation.

The three-digit reply code comes from RFC 5321: a 2yz is a success, a 4yz is a transient failure the sender should retry, and a 5yz is a permanent failure the sender should not repeat in the same form. The dotted code beside it comes from RFC 3463 and has three parts — class.subject.detail — where the class repeats 2, 4 or 5, the subject says which part of the system had the problem, and the detail says what it was. The full list is an IANA registry established by RFC 5248, which is the authoritative source and the one nothing else ranking for these queries cites.

The enhanced code varies more than most. 4.7.0 is "other or undefined security status", which is what a server uses when it is declining for its own reasons. Gmail also publishes a specific one for rate limiting, 4.7.28, and its text names the cause outright.

Why it matters more to a verifier than to a sender

For a sender, a 421 is an inconvenience: queue, wait, retry. For anything opening many short SMTP sessions, it is the receiving provider’s first warning, and ignoring it is how a sending IP earns a block that turns every later result into a false negative.

This is the specific failure mode that makes verification at volume an infrastructure problem rather than a code problem. A brand-new IP opening thousands of sessions is indistinguishable, at the protocol level, from a dictionary attack — so it is throttled, then blocked, and after that it reports unknown for everything. Probes here are paced per receiving provider with per-provider sub-caps and a circuit breaker precisely so a 421 leads to backing off rather than to a wall of wrong answers.

What each provider actually says

Quoted from each provider's own published documentation, with the date it was read. Not paraphrased into a claim about what a provider "always" returns.

“IP not in whitelist for RCPT domain, closing connection.”

Gmail, read 11 September 2026

“Gmail has detected an unusual rate of email. To protect our users from spam, email has been temporarily rate limited.”

Gmail, read 11 September 2026

What to do

If you sent the message

Retry later. One 421 is routine.
If it is persistent against one provider, reduce your sending rate to that provider rather than retrying harder.

If you own the receiving domain

Check concurrent-connection limits if legitimate senders are being cut off.
Name the cause in the reply text. A sender who cannot tell throttling from a block cannot respond correctly to either.

If you are a developer

Back off the whole receiving provider, not just the one address — the limit is per connection source, not per recipient.
Use exponential backoff with jitter, and cap concurrency per destination.
Never suppress an address on a 421. Nothing was learned about it.
A 503 with the error code ENGINE_CAPACITY from our API means the same class of thing at our end: no sending capacity was available, the work was not done, and you were not charged.

To find out whether an address will return this before you send to it, run it through the free email verifier

Related codes

Related terms

Sources

Primary sources checked 11 September 2026. If something here is out of date, tell us and we will correct it.