SMTP 421 4.7.0: try again later (temporary security or policy defer)
A 421 4.7.0 reply is a temporary refusal on security or policy grounds, so your server should retry later. RFC 3463 defines X.7.0 as "Other or undefined security status", a catch-all the receiver pairs with the 421 basic code to defer, not reject. Rate limiting, greylisting, and transient reputation checks are the common triggers.
The enhanced status code 4.7.0 is defined by RFC 3463 as "Other or undefined security status": a security or policy condition the server did not describe more precisely. Paired with the basic 421 code from RFC 5321, which closes the transmission channel, it is a temporary defer rather than a permanent block.
What usually triggers it
Rate limiting: you opened more connections or sent more messages than the receiver allows in a window.
Greylisting: a first-time sender is deferred on purpose and expected to retry.
Reputation throttling: the receiver is slowing an IP or domain it is unsure about.
What to do
A well-behaved sending server retries a 4.7.0 automatically after a delay, and greylisted mail usually goes through on the second attempt. If the defers keep coming, look at your sending rate and IP reputation rather than the recipient. A 4.x code means the message is still in the queue, not bounced.
Common questions
Is 421 4.7.0 a bounce?→
No. The 4 marks it transient, so the message stays queued and your server retries. It is a defer, not a permanent failure.
Why did I get 421 4.7.0 on the first send?→
Greylisting is the usual reason. Many receivers defer an unknown sender once and accept the retry a few minutes later.
How should my server handle 4.7.0?→
Retry after a delay with normal backoff. If defers persist, review your sending rate and IP reputation.
Does 421 4.7.0 mean I am blocklisted?→
Not necessarily. It is a temporary security or policy defer. Persistent 4.7.0 can point to throttling, so check reputation if it does not clear.