SMTP "421 Too many connections" or rate limited: how to fix it

What it means

A 421 answer means "not now, try later". The receiving server closes the connection because you opened too many at the same time, or sent too fast. It is a temporary error: a normal mail server keeps the message and retries. On Postfix servers, the message usually looks like this:

421 4.7.0 mx.example.com Error: too many connections from 203.0.113.10

Other servers say it differently ("Too many concurrent SMTP connections", "Try again later, closing connection", "rate limited"). A related Postfix message is 450 4.7.1 Error: too much mail from 203.0.113.10 (message rate limit).

Some big providers have their own codes, with their own guides: Gmail 421 4.7.28 and Microsoft 451 4.7.500; Yahoo has its own TSS codes.

Why it happens

• Too many parallel connections. Your app or server opens many connections at once (a newsletter or a script that sends each email in its own connection).
• Too many messages per minute from one IP or one account.
• Low or new reputation. Receivers accept less from IPs they do not know, so a volume that is fine for an old IP triggers limits on a new one.
• Shared IP. Other customers on the same IP use part of the allowance.
• Your own server limits, if it is your server that answers 421 to your apps or to a partner.
• Sending account limits. Mailbox providers limit SMTP sessions and messages per account; a 421 or 4.7.0 during a big send from a normal mailbox is common.

How to check

1. Find who answers. The hostname in the 421 line tells you whether it is the recipient's server, your provider's relay, or your own server.
2. On your Postfix sender, look at deferrals:

   postqueue -p | grep -i "too many" | sort | uniq -c
   grep "421" /var/log/mail.log | tail

3. On your Postfix receiver, the anvil service logs the peaks:

   grep "anvil" /var/log/mail.log | tail
   postconf smtpd_client_connection_count_limit smtpd_client_connection_rate_limit smtpd_client_message_rate_limit anvil_rate_time_unit

4. Check reputation: look up your sending IP on blacklists and send a test to the unique address on the Delivmail home page. A clean report means the limit is about volume, not about a block.

How to fix it

If you are the sender: send more slowly

In an app with nodemailer, reuse a few connections instead of opening one per message:

const transporter = nodemailer.createTransport({
  host: 'smtp.example.com',
  port: 587,
  pool: true,          // reuse connections
  maxConnections: 2,   // parallel connections
  maxMessages: 100,    // messages per connection
  rateDelta: 1000,     // time window in ms
  rateLimit: 5,        // messages per window
  auth: { user: 'you@yourdomain.com', pass: process.env.SMTP_PASS }
});

With Postfix, slow down only the destination that complains, using a dedicated transport. In master.cf:

slow      unix  -       -       n       -       2       smtp

In main.cf:

transport_maps = hash:/etc/postfix/transport
slow_destination_concurrency_limit = 2
slow_destination_rate_delay = 1s

And in /etc/postfix/transport, then postmap /etc/postfix/transport and systemctl reload postfix:

example.com    slow:

Spread big campaigns over time, and if your IP or domain is new, increase volume step by step (see warming up a new domain or IP). Do not rotate IPs or accounts to get around limits: receivers see it and it hurts your reputation.

If your own server answers 421

Defaults (smtpd_client_connection_count_limit = 50 per client, rate limits disabled) suit most servers. If you set stricter limits, raise them, or exclude trusted senders such as your own apps:

smtpd_client_event_limit_exceptions = $mynetworks, 203.0.113.10

A better fix for apps is to send through the submission port with a pool of a few connections, as above.

Check that it is fixed

Watch the log during the next send: deferred messages should leave the queue with status=sent, and new 421 lines should stop. Send a new Delivmail test to confirm authentication and reputation are clean, then resend to the address that was deferred if it finally bounced.