Email Throttling: Mailbox Provider Rate Limits and How to Pace Sends

Email throttling is the deliberate pacing of your outbound mail — limiting messages per connection, connections per server, and volume per hour per destination — because mailbox providers defer or reject senders who push volume faster than their reputation supports. Get it right and deferrals (421, 452) are rare and self-healing; get it wrong and a single burst can suppress your deliverability for days. The core practice: ramp volume gradually, reuse connections, and back off exponentially when providers tell you to slow down.

Throttling isn't a bug in your pipeline. It's a deliverability feature — and this post covers how to configure it properly.

Why do mailbox providers throttle incoming mail?

Every inbound MX has finite capacity and an abuse problem. Rate limiting solves both: by capping how fast any one IP, domain, or connection can deliver, providers protect their infrastructure and force senders to reveal themselves over time. A spammer's economics depend on blasting maximum volume before getting blocked; a throttle makes that strategy unprofitable.

The signals providers watch, roughly in order of importance:

• IP reputation and history — has this IP sent here before, in what volumes, with what complaint rates?
• Domain reputation — increasingly the primary signal since Yahoo moved to domain-reputation-first scoring in April 2025.
• Volume trajectory — a sender doing 200 messages/hour to Gmail for months who suddenly opens 50 connections and pushes 50,000 looks like a compromised account, because that's exactly what compromised accounts do.
• Per-recipient engagement — even a well-paced send gets deferred if nobody opens, replies, or rescues your mail from spam.

When you exceed whatever allowance your current reputation earns, the provider doesn't bounce you — it defers you with a 4xx code, saying "slow down, come back later." That's the provider throttling you. The rest of this post is about you throttling yourself first, on your own terms, so it rarely comes to that.

What do 421 and 452 deferrals actually mean?

Both are temporary failures, but they come from different layers:

`421` — service-level throttle. The server is limiting you at the connection or IP level: too many concurrent connections, too much volume per hour, or a general "back off":

421 4.7.0 [203.0.113.44] Our system has detected an unusual rate of
unsolicited mail originating from your IP address. To protect our users
from spam, mail sent from your IP address has been temporarily rate
limited. Please visit https://support.google.com/mail/answer/81126

That's Gmail's classic reputation throttle — the word "unsolicited" is doing a lot of work in that sentence. It's not just capacity; it's an accusation. Microsoft's variants read like 421 4.7.66 or throttling notices from outlook.com protection hosts.

`452` — resource-level throttle. Usually per-recipient or per-connection limits: too many recipients in one transaction, too many messages on one connection, mailbox full, or a daily quota:

452 4.5.3 Your message has too many recipients (policy: max 100 per envelope)

Operational rule: treat every 4xx as a signal to reduce concurrency and retry later, never to retry immediately or open more connections. Hammering a throttling server is how a 15-minute deferral becomes a 24-hour reputation penalty. For the full 4xx/5xx taxonomy — including the ones that are not throttles — see our SMTP error codes explainer. And don't confuse throttling with greylisting: greylisting is identity-based and clears after one retry; throttling is behavior-based and clears when your pacing improves.

How are limits applied: per-IP, per-domain, or per-connection?

All three at once, which is what makes tuning non-trivial:

• Per-connection limits: max recipients per envelope, max messages per SMTP session, commands per minute. These are hard, published-ish, and consistent.
• Per-IP limits: connections per IP and messages per IP per time window. Reputation-scaled — a trusted IP gets a generous allowance; a new or lukewarm IP gets a tiny one.
• Per-domain limits: the modern frontier. Gmail and Yahoo both weight the From domain's reputation heavily now, so ten "fresh" IPs won't rescue a domain with bad complaint metrics. Limits follow the domain across IPs.

Typical provider behaviors — deliberately hedged, because these are unpublished, reputation-scaled, and change constantly:

Take the numbers as "a handful of connections per IP to the big consumer providers," not as targets to hit.

Concurrency and connection reuse: the two knobs that matter most

If you run your own MTA, the two settings that dominate throttling behavior are:

1. Outbound concurrency per destination. How many simultaneous connections you open to one MX. Postfix:

# /etc/postfix/main.cf
initial_destination_concurrency = 2
default_destination_concurrency_limit = 10
gmail_destination_concurrency_limit = 4      # via transport-specific tuning

Postfix actually has elegant built-in behavior here: it starts at initial_destination_concurrency and slowly raises concurrency for destinations that accept mail cleanly, and immediately drops it when it sees deferrals. Respect that feedback loop; don't override it with static high limits.

2. Connection reuse (SMTP pipelining / caching). Opening a fresh TCP+TLS connection per message is expensive for both sides and providers count it. Postfix's smtp_connection_cache_on_demand or a fixed connection_cache lets one connection deliver many messages to the same MX:

smtp_connection_cache_on_demand = yes
smtp_connection_cache_time_limit = 2s
smtp_connection_reuse_time_limit = 300s

For ESP users: your platform handles this, but your account-level throughput is still shaped by plan and reputation. A sudden 10x spike on a marketing automation tool will produce deferrals even on their warmed IPs.

Exponential backoff, done right

When you do get deferred, the retry strategy matters more than the pacing that caused it. Bad retry logic — fixed 60-second retries, or worse, immediate retries across more connections — is the most common self-inflicted deliverability wound in custom sending code.

Correct approach: exponential backoff with jitter, capped, and keyed per destination:

retry = 0
base_delay = 60          # seconds
max_delay = 3600         # cap at 1 hour
max_retries = 12         # ~ gives up after several hours total

while retry <= max_retries:
    result = smtp_send(message, mx)
    if result.accepted:
        break
    if result.is_permanent_failure():      # 5xx: never retry
        mark_bounced(message)
        break
    # 4xx deferral: back off exponentially with jitter
    delay = min(base_delay * (2 ** retry), max_delay)
    delay = delay * random.uniform(0.5, 1.5)   # jitter avoids thundering herd
    sleep_until(message, delay)
    retry += 1

Three details that separate this from naive backoff:

• Jitter is mandatory. If 5,000 queued messages all defer at once and all retry exactly 60 seconds later, you've built a self-inflicted DDoS. Randomizing ±50% spreads the retry wave.
• Back off per destination, not globally. A 421 from Gmail says nothing about Yahoo. Naive systems pause the whole queue; correct systems throttle only the deferring MX while other destinations flow.
• Reduce concurrency on deferral, not just timing. Each 4xx should also shrink your connection count to that destination for a while (Postfix does this automatically). Retrying slower through the same 20 open connections misses half the signal.

How do you pace an IP or domain warmup?

Warmup is throttling's scheduled cousin: you're artificially limiting volume to build the reputation that earns bigger allowances. A sane starting schedule for a new dedicated IP sending to consumer providers — adjust by engagement, and note these are order-of-magnitude guidance, not magic numbers:

Rules that matter more than the table: start with your most engaged recipients (openers and clickers first — complaint-free volume builds reputation fastest), spread sends across the day rather than one hourly cron burst, hold volume flat for 2–3 days whenever deferrals spike, and never "catch up" after a paused day by doubling the next one. The deeper methodology — including whether purchased warmup services actually work — is in does email warmup work?.

The burst penalty after quiet periods deserves special mention. Providers decay their memory of you. An IP idle for 3–4 weeks is treated almost like new; hit it with your old volume on day one back and you'll eat a wave of 421s. Coming back from any pause longer than a couple of weeks, re-ramp at roughly half the original warmup schedule. Seasonal senders (holiday retail, annual events) hit this every year and blame "the algorithm." It's just arithmetic.

This is also where your IP strategy intersects: on a shared IP, the ESP smooths these curves across thousands of senders and you mostly don't think about warmup at all; on a dedicated IP, every one of these curves is yours to manage. The trade-offs are covered in dedicated IP vs shared IP.

ESP throttling settings vs self-hosted: who does what?

On an ESP, your controls are coarse: send-time spreading ("send over 4 hours"), per-campaign rate limits, and sometimes domain-level caps. The connection-level and backoff machinery is theirs — and generally good, because their deliverability team tunes it against live provider behavior. Your job is campaign-level pacing: don't mail 500k cold contacts at 9:00 sharp; spread over hours; segment by engagement so the weakest chunk goes last (and gets cancelled if deferrals spike).

Self-hosted, everything above is yours: Postfix/Exim/Haraka/PowerMTA tuning, per-destination concurrency, backoff logic, warmup scheduling, and monitoring. PowerMTA exists precisely because doing this well at millions-per-day scale is a specialty. The upside is control; the downside is that a misconfigured retry loop at 2 a.m. can burn a quarter of reputation.

Either way, measure before and after changes. Send a probe through the deliverability tester during a pacing change to confirm authentication and DNS stay clean while you isolate the throttling variable — a 0–100 score across 70+ checks beats reading tea leaves in bounce logs. And when you're building or changing sending code, exercise your backoff and queue logic against the email sandbox first: you want to discover that your retry loop hammers deferred MXes in staging, not against Gmail's production filters.

One last check worth running while you're tuning: pacing problems rarely travel alone — they tend to surface alongside authentication gaps or missing compliance headers that make providers less forgiving of your volume. A pass through the sender compliance checker confirms the rest of your sending config is clean, so when deferrals do hit, you know pacing is the actual variable.