What is “too many connections” or “rate limit” bounce?

When you send email at scale, you're connecting to receiving mail servers over and over again. Those servers have limits on how many simultaneous connections they'll accept from a single IP, how many messages per connection, and how fast you can send overall. Hit those limits and they push back with a temporary rejection.

This shows up as a 4xx response code in your bounce log, typically 421 or 452, with messages like:

• 421 4.7.0 Too many concurrent SMTP connections
• 452 Too many messages sent this hour
• 421 Service temporarily unavailable, try again later

These are soft bounces. They're temporary. Your sending infrastructure should retry after the appropriate wait period, and delivery will usually succeed.

The reasons this happens:

• Sending too fast: You're pushing messages to the same mailbox provider faster than they're willing to accept them. Gmail, for example, has limits on how quickly any single IP can send to addresses at Gmail. Burst sending to large lists hits this regularly.
• Shared IP congestion: If you're on a shared sending IP (common with entry-level ESP plans), other senders on the same IP can trigger rate limits that affect you too.
• New IP or domain warming: Newly provisioned IPs have low trust and low connection allowances. Sending too fast on a cold IP is a common cause of rate limit bounces early in the warming process.

The fix is almost always to slow down and spread your sends. Most ESPs handle this automatically with throttling and retry logic built in. If you're managing your own infrastructure, configure your MTA to limit connections per destination domain and to respect the retry delays specified in the 4xx response.

If rate-limit bounces are persisting across multiple retry attempts rather than resolving, that escalates from a temporary throttle into a potential persistent deferral worth investigating. Check whether your IP reputation is contributing to tighter rate limits than usual.