SMTP 421: service not available, closing channel
421Service not available, closing transmission channelTemporary: the sender retries
421 4.7.0 mx.example.com Error: too many errors
What it means
RFC 5321 defines 421 as "Service not available, closing transmission channel". It is the only reply that lets a server hang up at any point in the session: right after you connect, after EHLO, or in the middle of a transaction. The server sends 421 and then drops the TCP connection, so nothing after it is processed.
Because it starts with 4, the failure is transient. Your outbound MTA keeps the message in its queue and tries again later, usually with growing intervals, until its queue lifetime runs out (often 4 to 5 days). Only then does the sender get a final bounce, which commonly carries 4.4.7 (delivery time expired).
The bare 421 says little on its own. The enhanced code after it is the real clue: 4.7.0 and 4.7.28 usually mean rate limiting or reputation throttling, 4.3.2 means the system is shutting down or not accepting messages, and 4.4.2 points at a dropped or timed out connection. Compare it with 450 and 451, which refuse a single command but leave the session open.
Likely causes
- The receiver is throttling your sending IP because you sent too many messages or connections in a short window (Gmail’s 421 4.7.28 is the best known case).
- Your IP or domain has a weak or new reputation, so the receiver slows you down instead of rejecting outright.
- The receiving server is overloaded, restarting, or in maintenance and refuses new sessions for a while.
- Your client made too many protocol errors or opened too many parallel connections, and the server cut the session (Postfix says "too many errors").
- A greeting delay or pregreet check caught your server talking before the banner, a sign of a broken or impatient client.
How to fix it
- Read the full line, including the enhanced code and any text after it, and note which host sent it. The MX that answered tells you whose policy you hit.
- Let the queue retry. A short spike of 421 replies often clears by itself within an hour, so do not resend by hand or flush the queue repeatedly.
- If it persists, lower concurrency and per-domain rate on your MTA (for example Postfix `smtp_destination_concurrency_limit` and `smtp_destination_rate_delay` in a transport for that domain).
- Check your reputation: confirm your sending IP is not on a blocklist, has a matching PTR record, and that SPF, DKIM, and DMARC pass, since receivers throttle unauthenticated senders first.
- For bulk mail to Gmail or Yahoo, review Google Postmaster Tools or Yahoo Sender Hub and warm up new IPs gradually.
Checks that apply
- Blacklist Check Shows whether your sending IP sits on any of 40 DNSBLs, a common reason receivers start throttling with 421.
- Reverse DNS (PTR) Confirms your sending IP has reverse DNS that matches its HELO name, which many receivers require before they stop deferring.
- SMTP Diagnostics Connects to the receiving MX so you can see whether it answers with 421 at the banner, which points at a server side outage rather than your mail.
- Email Deliverability Rolls SPF, DKIM, DMARC, and reputation into one view so you can tell an authentication gap from plain rate limiting.
FAQ
- Will my server retry after a 421?
- Yes. 421 is a temporary failure, so a standard MTA keeps the message queued and retries for several days before it gives up and bounces with 4.4.7.
- Is a 421 my problem or the receiver’s?
- Either. A 421 at the banner for every sender points at the receiver, while 421 with 4.7.0 or 4.7.28 aimed at your IP means your volume or reputation triggered their limits.