SMTP 421 4.3.2: system not accepting network messages (server busy)
A 421 4.3.2 reply means the receiving system is not accepting messages at the moment, so your mail is deferred for retry. RFC 3463 defines X.3.2 as "System not accepting network messages", with an imminent shutdown, heavy load, or maintenance as the listed causes. The 421 basic code closes the connection, but the 4.x class keeps the message queued.
The enhanced status code 4.3.2 is defined by RFC 3463 as "System not accepting network messages": the host holding the mailbox is not taking mail right now. The RFC names an imminent shutdown, excessive load, or system maintenance as typical reasons.
What it signals
The receiving server is restarting or being taken down for maintenance.
It is under heavy load and shedding new connections to protect itself.
A queue or resource limit on the far side is temporarily maxed out.
What to do
This is the receiver side, not yours, and a 4.x code keeps your message queued for automatic retry. Give it time and the server usually starts accepting again once load drops or maintenance ends. If a specific domain returns 4.3.2 for hours, the outage is longer than usual; keep retrying until the window closes, after which the message bounces as a permanent 5.x.
Common questions
Is 421 4.3.2 my fault?→
No. It is the receiving system declining mail during a shutdown, overload, or maintenance. Your message is deferred, not rejected.
Is 421 4.3.2 permanent?→
No. The 4 marks it transient, so your server keeps the message queued and retries until the host accepts again.
How is 4.3.2 different from 4.7.0?→
4.3.2 is the whole system refusing mail because it is busy or down. 4.7.0 is a security or policy defer such as rate limiting or greylisting.
What if 421 4.3.2 never clears?→
When the retry window expires, the message escalates to a permanent 5.x bounce. A long outage on one domain can cause that.