SMTP error 421 4.7.26: email rate limit exceeded on receive

A 421 4.7.26 reply happens at the SMTP connection or envelope stage, before the message body is

even read. The 4 means temporary: the server is telling you to back off and try again later,

not refusing the recipient or the content. 4.7.26 is a vendor extension on top of the RFC 3463

enhanced-status-code scheme (the 4.7.x family covers security and policy conditions), used by

several large mailbox providers specifically for rate limiting.

A real transcript

Connected to mx.example.com.
220 mx.example.com ESMTP ready
EHLO yourdomain.com
250-mx.example.com
MAIL FROM:<you@yourdomain.com>
250 2.1.0 Sender OK
RCPT TO:<recipient@example.com>
250 2.1.5 Recipient OK
DATA
354 Start mail input
...
421 4.7.26 Too many connections from your IP, try again later

The connection may also be closed outright before EHLO completes, with no RCPT exchanged at all,

when the limit is per-IP rather than per-message.

How the big three phrase the same condition

The underlying trigger — too many connections or messages too fast — is universal, but the wording

and the code attached to it differ by provider, which matters if you are parsing logs

programmatically.

Do not assume the exact code your library logs is the one every provider sends — match on the

free text too, since the enhanced status code is not standardised across vendors for this

condition.

Who is at fault

This is a rate limit, not a content or authentication problem. It sits on the sending side's

behaviour: too many connections, too many messages, or too many recipients in too short a window

from one IP or domain. It is not evidence of a blacklist listing or a spam verdict by itself,

though ignoring it repeatedly can turn into one.

Diagnose it yourself

1. Count concurrent connections your own sending stack opens to the destination's MX. If you

run Postfix, postqueue -p | grep recipientdomain.com | wc -l tells you how many messages are

queued toward that domain right now; a large number sent in parallel is the first thing to fix.

1. Pull the destination's MX and check it resolves to the host that actually rate-limited you:

dig MX recipientdomain.com +short. If multiple MX hosts exist, you may be hitting a limit on

one specific host in their cluster, not the domain as a whole.

1. Grep your mail log for the pattern over time: grep "421" /var/log/mail.log | tail -50 and

look at the timestamps — bursts clustered in a short window confirm a pacing problem rather than

a sustained one.

1. Test a single, slow connection manually with `openssl s_client -starttls smtp -connect

mx.example.com:25 and step through EHLO/MAIL FROM/RCPT TO` by hand — if a lone connection

succeeds while your bulk job fails, the limit is concurrency, not content.

The fix, in order

1. Stop retrying immediately. Hammering the same server right after a 421 makes the limit

reset and signals exactly the bursty behaviour the limit exists to catch.

1. Reduce concurrent connections. Most receivers cap simultaneous SMTP connections per sending

IP in the single digits. If your sending software opens many connections in parallel, drop that

number first.

1. Throttle messages per minute/hour, not just per day. A daily cap spent in the first ten

minutes triggers rate limiting even if the daily total is reasonable.

1. Respect the provider's documented limits where published (large providers publish per-IP

and per-connection limits for high-volume senders); undocumented ones require inferring from

how often you see 421s.

1. Spread sends across the day instead of sending in one batch. A steady trickle looks like

normal mail traffic; a burst looks like an attack.

1. Let your MTA's retry/backoff queue handle it. A properly configured outbound queue retries

a 421 later automatically — do not build a tighter retry loop on top of it.

What not to do

• Do not treat 421 4.7.26 as a bounce and remove the recipient from your list. The address was

never evaluated — suppressing it throws away a reachable contact for a problem that was entirely

about your connection pacing.

• Do not open more connections to "push through" the limit. Doubling parallel connections after a

421 is the single most common mistake here, and it reliably extends the block instead of

clearing it, because the receiver's counter resets on each new burst it sees.

• Do not switch to a new sending IP to dodge the limit without warming it up — a cold IP sending

the same volume will hit the same wall, or a stricter one, since a brand-new IP with no history

gets tighter default limits than an established one.

• Do not disable retries. A dropped 421 with no retry is a lost message for no reason, and most

MTAs already implement correct exponential backoff — removing it to "simplify" the pipeline

usually just removes the safety net.

MailPilot's warm-up schedules ramp volume and spread sends across realistic time windows per

mailbox rather than firing in bursts, which is the direct cause this error is built to catch.

Combined with per-mailbox reputation tracking, it shows whether a given provider is throttling you

specifically before the volume increase, not after.