Rate Limiting
Caps servers place on connections or messages in a given window.
Exceeding them triggers 421/450 throttling responses.
Definition
Rate limiting is a mail server restricting how many connections, commands, or messages a given sender may issue within a set time window. It protects the receiving server against abuse and directly shapes how fast bulk verification or bulk sending can safely run before triggering a throttle.
We open a very large number of live SMTP conversations every day to verify email addresses, and rate limiting is the constraint that governs almost every one of them. It is not a bug in a mail server and not a sign of anything wrong with an address. It is the receiving server protecting itself, and it directly decides how fast bulk verification or bulk sending can safely run before a provider starts pushing back.
The three layers of rate limiting
Mail servers rarely enforce a single limit. They typically stack three, and hitting any one of them triggers a throttle. Connection limits cap how many simultaneous SMTP sessions a single IP is allowed to hold open against the server at once. Command limits cap how many RCPT TO or MAIL FROM commands can run inside a connection, or per minute overall. Recipient and message limits cap the total number of messages a sender is allowed to push through in an hour or a day.
A server can enforce any combination of the three simultaneously, which is why two senders hitting the same provider can experience very different behavior: one might be capped on connection count while another sails past that but trips the daily message ceiling instead.
What throttling looks like: 421 and 450
When a sender crosses a threshold, the server almost always answers with a temporary 4xx code rather than an outright rejection. The two most common are 421, “service not available, closing transmission channel,” and 450, “mailbox unavailable, try again later.” Both are instructions to slow down and retry, not a verdict on the message or the recipient address.
That distinction matters because a throttling response is the same broad class of temporary failure as a soft bounce. Logged without context, a rate-limit deferral and a full mailbox look identical, even though one clears itself the moment you slow down and the other does not.
How Gmail, Outlook, and Yahoo throttle differently
None of the major mailbox providers publish exact numbers, because their limits adapt to sender reputation rather than staying fixed. Gmail is known to cap new or low-reputation sending IPs hard on connections per second and total messages per day, and to loosen those caps as an IP accumulates a clean history. Outlook, running Exchange Online Protection, tends to throttle aggressively on rapid bursts of connections from a single IP in a short window, independent of total daily volume. Yahoo and AOL are known for tight per-connection recipient caps, limiting how many addresses can be checked in a single session regardless of how the connections are paced.
Across all three, the pattern is the same: senders with consistent, clean, authenticated volume earn higher limits over time, while spiky or unauthenticated traffic gets throttled fast and stays throttled longer.
Why verification APIs pace their SMTP probes
A verification probe opens a real SMTP conversation exactly the way a sender does, and from the receiving server’s point of view there is no built-in way to distinguish a legitimate check from a script hammering the server. The only signal a provider has is behavior, so firing probes as fast as possible looks identical to abuse and earns the same rate limit.
Once a checking IP is throttled by a given provider, every subsequent check against that provider degrades: real, valid addresses start returning ambiguous 421 or 450 responses instead of a clean accept or reject. Pacing is not caution for its own sake. It is what keeps the next check, and the one after that, accurate.
How we handle it
Our engine maintains a pool of sending IPs and paces requests per destination provider, so no single IP looks like it is hammering Gmail, Outlook, or Yahoo at once. When a provider starts signaling a slowdown, we back off automatically with an exponential delay rather than pushing through and forcing a harder throttle. That backoff is what keeps a 421 or 450 from being misread as a bad address, so the result you see reflects the mailbox, not a limit we tripped.
- Rate-limit-aware pacing is part of the same engine behind the free email checker and the verification API, so bulk jobs do not degrade mid-run.
- To watch a throttle happen live, open a handshake with the SMTP test and read the exact response code the server returns.
- For your own outbound sends, the same backoff logic — spread load across IPs, exponential delay with jitter, respect provider hints — keeps a legitimate campaign from tripping the same limits.
Handled properly, rate limiting is a pacing problem, not a data quality problem. For teams verifying at scale, where every throttle avoided is one fewer address wrongly marked “unknown,” the volume tiers are on the pricing page.
Explore more from Verifox
Rate limiting sits inside a wider set of deliverability concepts. These are the terms most worth understanding next.
Common questions
Rate limiting, answered
Send too fast and a provider will start throttling you, reputation or not. Here’s how sending limits actually work, and how to stay under the radar.
What is rate limiting in simple terms?
It is a speed limit a mail server sets for anyone talking to it. Once a sender crosses a threshold, whether that is too many connections, too many commands, or too many messages in too short a window, the server slows things down or refuses the next request outright.
The limit resets after the window passes, so it is not a permanent block. It is a pacing rule, and every major mailbox provider enforces some version of it.
What exactly gets rate limited?
Three layers, usually stacked together. Connection limits cap how many simultaneous SMTP sessions one IP can hold open. Command limits cap how many RCPT TO or MAIL FROM commands can run per connection or per minute.
Recipient and message limits cap total messages accepted from a sender per hour or per day. A server can enforce any combination of the three, and hitting any one of them triggers a throttle.
What does a rate-limited response look like?
Almost always a temporary 4xx code, most commonly 421 (“service not available, closing transmission channel”) or 450 (“mailbox unavailable, try again later”). Both tell the sender to back off and retry, not that the address or message was rejected.
The exact text varies by provider, but phrases like “too many connections,” “rate limit exceeded,” or “try again later” in the response are the tell. It is the same class of temporary failure as a soft bounce.
Do Gmail, Outlook, and Yahoo rate limit differently?
Yes, and none of them publish exact numbers because the limits adapt to sender reputation. Gmail is known to cap new or low-reputation IPs hard on connections per second and messages per day, loosening as a sending IP builds history.
Outlook (Microsoft 365 / Exchange Online Protection) tends to throttle aggressively on rapid-fire connections from a single IP, while Yahoo/AOL is known for tight per-connection recipient caps. All three raise limits for senders with clean, consistent volume and drop them fast for spiky or unauthenticated traffic.
Why do email verification APIs pace their SMTP probes?
Because a verification probe opens a real SMTP connection just like a sender does, and a provider cannot tell a legitimate check from a hammering script except by behavior. Firing probes as fast as possible looks identical to abuse, and gets a rate limit slapped on the checking IP.
Once an IP is throttled, every subsequent check against that provider degrades: valid addresses start returning ambiguous 4xx responses instead of clean answers. Pacing protects the accuracy of every check behind the one that comes next.
How does rate limiting affect bulk email verification?
At scale, it is the single biggest constraint on throughput. Verifying a million addresses means repeatedly talking to the same handful of large providers, and each one is watching connection rate, command rate, and recipient rate from every IP that contacts it.
A validator that ignores this gets throttled mid-run and starts reporting real addresses as unknown or undeliverable, not because the address is bad but because the checking infrastructure got rate limited.
How does Verifox handle rate limiting during verification?
Our engine maintains a pool of IPs and paces requests per destination provider, spreading connections so no single IP ever looks like it is hammering Gmail, Outlook, or Yahoo. When a provider does start signaling a slowdown, we back off automatically rather than pushing through it.
That backoff keeps a 421 or 450 from being misread as a bad address, so the result reflects the mailbox, not a throttle we triggered. The full pipeline is documented on the email verification page.
What backoff strategy should I use when I get rate limited?
Exponential backoff with jitter is the standard: wait, then retry after a growing delay (1s, 2s, 4s, 8s...) with a small random offset so a whole batch of retries does not land on the server at the exact same instant and re-trigger the limit.
Alongside that, spread load across multiple sending or checking IPs, respect any Retry-After-style hint in the response, and cap concurrent connections per destination provider rather than per overall job.
Is rate limiting the same as greylisting?
They are related but distinct. Rate limiting caps how much traffic a sender can push in a time window, regardless of whether the server has seen that sender before. Greylisting is a one-time trust test on unknown senders: defer the first attempt and accept the retry.
A sender can be greylisted on its very first message and rate limited on its thousandth. They are two independent gates a message can hit on the way to acceptance.
Can I test how a server rate limits before I send at scale?
You can watch for the signature directly: open several connections in quick succession and see whether the responses shift from 250 acceptances to 421/450 deferrals as volume climbs.
Our SMTP test opens a live handshake against a server so you can read the exact response code it returns, which is the fastest way to see a throttle kick in.