SMTP 421 4.7.27: connection rate limited, not blocked

A 421 reply means the receiving server is closing the connection and wants you to come back

later. It is a 4xx, so it is a deferral, not a bounce: the message stays in your queue, the

recipient is untouched, and the right response is to retry more slowly. When the accompanying text

mentions connection rate limiting, the server is telling you something specific - the problem is

how fast you are opening sessions, not how many messages you are sending.

One honesty note first. 4.7.27 is not an enhanced status code in the RFC 5248 registry, and it

is not a string the large providers emit. It circulates in error-code lists. If you have a real

connection rate limit, the reply you actually received is one of the ones below, and that is the

string to search for and to quote in a ticket.

What the providers actually send

Those are five different conditions wearing the same 421. The bracketed and numeric details are

the diagnosis; the 421 only tells you to wait.

Connection limiting is not message limiting

Receivers enforce at least three separate controls, and confusing them is why "we reduced volume

and nothing changed" is such a common complaint.

A sender that opens a fresh TCP connection for every single message will hit the second limit

while sending a trivial number of messages. Halving the volume does nothing, because the

connection count per message is unchanged. The fix is connection reuse, not a smaller list.

The transcript

$ openssl s_client -connect gmail-smtp-in.l.google.com:25 -crlf
CONNECTED(00000003)
421 4.7.0 Try again later, closing connection. ij7-20020a17090a3dc7b0296c.56 - gsmtp
closed

Note where the rejection appears: in the greeting, before EHLO. Nothing about your message, your

authentication or your recipient has been evaluated, because none of it was sent. That is how you

tell a connection-level limit from everything else.

The ordered fix

1. Confirm it is a `4xx` and let the queue do its job. No message has been lost. Do not

re-inject anything by hand.

1. Count your concurrent connections to the affected destination. Two to four simultaneous

connections per receiving domain is a normal, polite figure. Twenty is not.

1. Reuse connections. Send several messages per session rather than reconnecting each time.

This single change resolves most connection-rate deferrals and costs nothing in volume.

1. Add jitter between sends. A scheduler that fires on a fixed tick dispatches its whole batch

in the same second, which looks nothing like human sending. Spread the batch across the

interval.

1. Honour the retry interval the server implies. Back off geometrically. Retrying in ten

seconds after a 421 reliably earns another 421.

1. Read the detail string before changing anything else. [TSS04] and 4.7.28 are

reputation-driven and will not be fixed by concurrency changes - those need complaint rates and

list quality addressed. 4.7.500 and 4.3.2 genuinely are capacity and concurrency.

1. Check authentication. SPF, DKIM and DMARC alignment failures make a receiver far more

willing to throttle you, so an unaligned domain gets limited at a volume a clean one would pass.

What not to do

• Do not treat a `421` as a bounce. The recipient address was never named. A classifier that

records this against a contact is corrupting your list with network data.

• Do not stop the sending mailbox. It is healthy; the receiver is asking it to slow down.

Auto-stopping on a throttle takes a good mailbox out of its ramp for no reason and costs you the

reputation it had built.

• Do not catch up after the throttle clears. Sending the backlog at double rate guarantees

hitting the limit again, harder, and on a reputation-driven throttle it confirms the receiver's

suspicion.

• Do not rotate IPs or domains to escape it. A new IP has no reputation at all, which at most

receivers is worse than a slightly throttled one.

• Do not raise concurrency to push the backlog through. Concurrency is usually the thing being

limited.

• Do not open a support ticket quoting `4.7.27`. Quote the full reply line including the

bracketed code and the server's message ID; that is what a postmaster team can actually look up.

MailPilot's warm-up ramps volume gradually rather than starting at a target, spaces sends instead

of dispatching a batch in one tick, and tracks per-mailbox reputation daily so you can see whether

a throttle is capacity or reputation. Its SPF, DKIM and DMARC checks cover the authentication half

of the problem, which is the cheapest part to fix and the part that most often tips a receiver

into throttling in the first place.