Email Throttling Rates by Provider: Real Limits

Throttling is the polite version of receiver enforcement — instead of bulk-folder placement or outright rejection, your mail is held back temporarily to slow your sending rate. For bulk senders, throttling is a daily reality, and understanding the rough limits at each major provider helps you architect sending patterns that respect them. This guide covers observed throttling behavior at the major receivers, what to do about it, and when throttling crosses into a real deliverability problem.

The honest caveat: no major provider publishes hard rate limits. Numbers below are based on industry observation, ESP guidance, and my own client work.

Why throttling happens

Receivers throttle for several reasons:

1. Protect their infrastructure — limit any single sender from overwhelming inbound capacity
2. Slow down questionable senders — buy time to evaluate reputation
3. Apply reputation-tiered limits — established senders get more bandwidth than new ones
4. Respond to reputation drops — sudden complaint spike → throttle while filters reassess
5. Defend against compromised accounts — sudden volume change → defer pending review

Throttling shows up as 421 deferrals (temporary, retry) or extended connection delays. It's not the same as a 5xx permanent rejection.

Gmail throttling

Gmail doesn't publish rate limits. Observed behavior:

Sender state	Typical tolerance per IP
New IP, no history	10-50 messages/minute
Warming up (week 2-3)	50-200/min
Established, good reputation	100-500/min
High-volume, dedicated IP, strong rep	500-2000+/min
Reputation problem	10-50/min, frequent 421s

Gmail's throttling is reputation-driven more than volume-driven. A long-established IP can push high volume with little throttling; a new IP at the same volume sees constant deferrals.

The signal: 421 errors with try again later text, often 421 4.7.0. See 421 try again later.

For monitoring, use Google Postmaster Tools.

Yahoo throttling

Yahoo enforces tighter per-IP rate limits than Gmail. Observed:

Sender state	Typical tolerance per IP
New IP	5-20/min
Warming up	20-100/min
Established	100-300/min
High-volume	300-1000/min

Yahoo also covers AOL.com, Verizon.net, AT&T.net on the same infrastructure. Throttling applies across all of them.

Yahoo's throttling often comes with TS-prefix codes (Cloudmark content filter) or simple 421s. For the Yahoo postmaster details, see Yahoo Postmaster Tools.

Microsoft throttling

Microsoft (Outlook.com, Hotmail, Live.com, custom Outlook.com domains) throttling varies by:

• Sending region
• Recipient server (different Hotmail data centers behave differently)
• Sender reputation in Microsoft SNDS
• Whether you're enrolled in JMRP (Junk Mail Reporting Program)

Observed:

Sender state	Typical tolerance per IP
New IP, no SNDS	20-100/min
SNDS green	200-500/min
SNDS yellow/red	5-50/min, frequent 421/451

Microsoft uses a mix of 421 4.7.0, 451 4.7.500-699 codes, and outright 550 5.7.1 rejections. Each tells you something different.

iCloud throttling

iCloud has the strictest rate limits among major receivers. Observed:

Sender state	Typical tolerance per IP
New IP	5-15/min
Established	50-150/min
High-volume good reputation	150-500/min

Apple's throttling is opaque — limited error messages, no public reputation dashboard. See iCloud deliverability guide.

Comcast throttling

Comcast (Xfinity Mail) uses Cloudmark filtering and tends to throttle on volume velocity:

• New IP: 10-30/min
• Established: 50-200/min
• High-volume: 200-500/min

Comcast also uses RL000-prefix codes for rate-limit specific deferrals. See Comcast postmaster.

How to send into throttling cleanly

The strategy:

1. Let your ESP handle pacing. SendGrid, Mailgun, Postmark, Klaviyo all have throttling intelligence that respects per-recipient-domain limits. Don't try to outsmart this with manual rate config.
2. Warm up new infrastructure. 30 days minimum for new IPs and domains. Start low, ramp gradually.
3. Distribute volume. Don't blast 100k messages at 9 AM Monday. Spread across hours or days.
4. Maintain consistent baseline. Stay within ±25% of typical daily volume for routine sends.
5. Plan campaign spikes. Ramp up 5-10 days before any 5x+ volume event.

Practitioner note: The most common throttling self-inflicted wound is sending a 50k-recipient campaign through a small ESP plan in the first hour of the morning. The ESP queues it, throttles outbound, and 30% of the campaign delivers 6-12 hours late. Either spread the send naturally over hours or upgrade your ESP tier.

When throttling becomes a real problem

Throttling is normal background noise for bulk senders. It crosses into deliverability problem when:

• Persistent for 48+ hours from the same provider
• Affecting majority of mail to that provider (not just edge cases)
• Combined with reputation drops in Postmaster Tools or SNDS
• Accompanied by 5xx rejections (not just 421 deferrals)
• Spreading across multiple providers simultaneously

When throttling becomes persistent, the underlying cause is usually:

• Authentication regression (DKIM rotation that broke alignment)
• Complaint rate spike from a bad send
• IP blocklist
• Sudden volume change
• Compromised sending account

Throttling vs blocking

It's important to distinguish:

Symptom	Type	Action
421 4.x.x, message retried	Throttling	Wait, monitor, ESP handles retry
451 4.x.x	Soft fail	Same as 421, slightly more concerning
550 5.7.x	Permanent reject	Investigate immediately
553 5.x.x	Sender rejected	Authentication or reputation issue
Connection refused/timeout	IP-level block	Likely blocklist, check immediately

For 550 5.7.1 specifically, see 550 5.7.1 rejection.

What ESPs do under the hood

Modern ESPs throttle outbound by recipient domain automatically:

• Track current rate per recipient domain
• Adjust based on receiver's deferral patterns
• Queue and retry deferred messages
• Spread volume across sending IPs in the pool
• Provide visibility through the dashboard

If you're on a shared IP pool, throttling intelligence is the ESP's responsibility. If you're on a dedicated IP, you're more exposed to your own volume mistakes.

Monitoring throttling

In your ESP, track:

• Deferred-then-delivered rate by recipient domain
• Time-to-delivery percentiles (p50, p99)
• 421 frequency by recipient domain over time
• Bounce rate (real rejections vs deferrals)

Sudden increases in 421 to a specific provider, especially Microsoft or Yahoo, are early signals of reputation pressure. Investigate before they escalate to outright rejections.

If you're seeing widespread throttling and want help diagnosing whether it's normal volume management or a reputation problem, book a consultation. I do throttling diagnostics for bulk senders dealing with delivery latency and queue backups.

Sources

• Gmail Sender Guidelines — Google
• Microsoft sender requirements — Microsoft
• Yahoo Sender Hub — Yahoo
• RFC 5321 — SMTP — IETF
• M3AAWG Sender Best Common Practices — M3AAWG

---

v1.0 · May 2026