Email Throttling Explained: Send Rate Limits, SMTP Errors, and How to Fix Deliverability
Email throttling is one of the easiest deliverability problems to miss. Your campaigns are sending, delivery rates look normal, and nothing in the dashboard appears broken, yet engagement starts dropping, recipients stop seeing your emails, and bounce logs quietly fill with 4xx "rate limit" responses.
By the time the pattern becomes obvious, throttling has often already damaged sender reputation and pushed mail toward spam folders or blocks.
Most senders assume throttling only happens at high volume, but mailbox providers now enforce behavioral limits long before published caps are reached. A new Google Workspace account can face throttling well below the official 2,000/day limit if bounce rates rise or sending ramps up too quickly.
That's where the real challenge begins: identifying whether the issue is caused by volume spikes, reputation decline, authentication problems, or silent throttling where mail is accepted but delayed for hours without warning.
In this guide, we'll break down how email throttling actually works, the current send-rate limits at Gmail, Microsoft 365, Yahoo, and other providers, how to read SMTP 4xx and 5xx errors correctly, and the safest ways to ramp volume without damaging domain reputation.
We'll also cover silent throttling, detection methods, recovery steps, and the role verification plays in preventing bounce-triggered throttling before it escalates further.
TL;DR
Email throttling is when a mailbox provider deliberately slows or temporarily refuses your mail, usually because you're sending faster than your reputation supports. It's signaled by SMTP 4xx response codes (most commonly 421), different from 5xx codes which are permanent rejections. Throttling is your sending environment's warning sign that something needs to change before it escalates to spam-folder placement, blocks, or blacklisting.
Concrete daily send limits in 2026: Gmail free 500/day; Google Workspace 2,000/day per user (10,000/day via SMTP relay); Microsoft 365 10,000 recipients/day per user with 30 messages/min; Outlook.com personal/family 5,000 recipients/day; free Outlook.com ~300/day; Yahoo Mail unpublished but functionally ~500-1,000/day for new senders. Microsoft 365 also enforces a Tenant External Recipient Rate Limit (TERRL) that caps tenant-wide external sending; rollout extends to April 2026 for the largest tenants.
Ramp-up strategy that doesn't burn the domain: start at 20-50 emails/day from a fresh domain in week 1, increase by 25% per week if metrics stay clean, plateau at any sign of 4xx error rate climbing, and never increase by more than 25% week-over-week. Most domain burns happen in weeks 2-3 from senders who saw clean week-1 metrics and accelerated too aggressively. Verification before sending is the highest-leverage prevention: hard bounces from invalid addresses are what triggers most throttling at low volume.
What Is Email Throttling and Why Does It Happen?
Email throttling is when a mailbox provider deliberately slows or temporarily refuses to accept mail from a sender. It's a deliberate response to a sending pattern the receiver considers risky: too much volume, too fast a ramp, too many bounces, declining reputation, and authentication issues. Throttling shows up as SMTP 4xx response codes (temporary, retry later), as opposed to 5xx codes (permanent rejection) or silent deferrals (mail accepted but held for hours).
The core distinction worth nailing down: throttling is bilateral and symptomatic, not punitive. Bilateral because it happens to you (from receiving servers) and ideally also because of you (proactive self-throttling on your side). Symptomatic because it's a warning sign of an underlying issue: reputation, list quality, volume pattern, not the underlying problem itself.
Throttling vs. Deferral vs. Block
| Term | What it actually means | Failure mode |
|---|---|---|
| Throttling | Sending server slows or pauses you before a delivery attempt, or receiving server defers your message after the connection | Mail backs up in your sending queue or arrives late |
| Deferral | Receiving server accepts the connection but delays delivery (4xx response) | Mail bounces with 4xx; retried later by your sending system |
| Block (or rejection) | Receiving server refuses delivery permanently (5xx response) | Mail bounces with 5xx; sender's side must fix the cause before retrying |
Email throttling is the mildest form of these. A single 4xx response on a single message is just transient. Throttling is a sustained pattern: 5-20% of your messages bouncing with 4xx codes over a window of hours, or messages consistently arriving 30+ minutes late even when not bouncing.
Sustained throttling is the signal that mailbox providers are telling you to slow down before they escalate to blocks.
Key Insight: The throttling-to-blocking progression: the typical pattern is throttling → spam-folder placement → selective blocks → blacklisting. Each stage is harder to recover from than the previous one. Catching the problem at the throttling stage when you're seeing 4xx responses but mail is still functioning means recovery in 2-4 weeks. Catching it at the blacklisting stage means 8-12+ weeks. The early signal is worth treating seriously even when delivery rates still look acceptable.
What Are the 3 Types of Email Throttling in 2026?
Mailbox providers throttle at three layers. Stated limits are the documented daily caps each provider publishes. Behavioral limits are the dynamic thresholds enforced based on your reputation, volume pattern, and engagement; they are always lower than stated limits and never published. Silent throttling is the invisible delay where the receiving server accepts your mail and holds it for hours without bouncing it. All three apply simultaneously; understanding which one is hitting you is the first diagnostic step.
Most articles cover only the first layer (stated limits). Most senders run into the second layer (behavioral) without realizing it because the dashboards don't expose it.
The third layer (silent throttling) is the most insidious because there's no bounce notification; your mail looks delivered, but it's arriving so late that flash sales end, password resets expire, and OTP codes time out before recipients see them.
Layer 1: Stated Limits
These are the published daily caps: Gmail is free at 500/day, Workspace at 2,000/day, Microsoft 365 at 10,000 recipients/day, etc. These are real ceilings; if you cross them, you get hard 5xx errors and a 24-hour block.
But almost no sender hits them in practice. Most senders get throttled well below stated limits because of behavioral enforcement.
Layer 2: Behavioral Limits
This is where most throttling happens. Mailbox providers enforce behavioral limits below stated caps based on your sender reputation, volume consistency, bounce rate, complaint rate, and engagement velocity.
- A new Gmail Workspace account with no sending history gets throttled at 50-100 emails/day even though the stated cap is 2,000.
- A Microsoft 365 tenant with an elevated complaint rate gets throttled at 1,000-2,000 recipients/day even though the per-user cap is 10,000.
Behavioral limits are dynamic. They change based on your real-time signals. Send to a clean engaged list with behavioral limits expanded. Spike bounces, send to disengaged subscribers, or trigger complaints, and behavioral limits contract.
Behavioral throttling well below stated caps: industry observations
Gmail Workspace published cap: 2,000 emails/day per user. Real-world enforcement: brand-new Workspace accounts can be throttled to as few as 10-50 emails/day until they build sending history. One reported case from a Reddit thread: a user got blocked after sending 12 emails per day using Boomerang scheduled sends. The gap between stated cap and behavioral threshold is where most sub-quota blocks happen.
Layer 3: Silent Throttling
The hardest to detect. Silent throttling happens when the receiving server accepts your mail (returning a 250 OK in the SMTP transaction) but then holds the message for hours before delivery. There's no bounce, no error code, no notification.
Long after it was helpful to the recipient, the message finally arrives, typically 30 minutes to 12 hours later.
Silent throttling matters most for transactional mail. A password reset that arrives 6 hours late is functionally useless. A flash sale email that arrives after the sale ends is worse than no email at all.
Common Mistake: Don't treat throttling as something only "big senders" have to worry about. Behavioral throttling hits new senders at very low volumes. 100 messages a day from a fresh domain can trigger 4xx responses. The volume threshold for throttling depends on your reputation, not just the absolute number. If you're seeing rate-limit responses in your bounce logs, the answer is never "send more to push through" - the answer is to slow down and address what triggered it.
SMTP 4xx vs 5xx Errors: Which Codes Mean Throttling?
SMTP response codes follow a basic three-digit format: 2xx codes mean success, 4xx codes mean temporary failures (try again), and 5xx codes mean permanent failures (don't try again until you fix the cause). For throttling specifically, 4xx codes - especially 421 - are the signal you're being rate-limited. 5xx codes are escalations: blocks, blacklist listings, and hard rejections.
Reading bounce logs is a deliverability skill most marketers never learn. The codes look intimidating, but the logic is simple:
- First digit is the class: 2 = success, 4 = temporary failure (transient), 5 = permanent failure.
- Second digit is the subject: 0 = unspecified, 1 = address, 2 = mailbox, 3 = mail system, 4 = network, 5 = mail delivery protocol, 7 = security/policy.
- Third digit is the detail: specific information within the subject category.
When you see 421 4.7.0 in a bounce log, the basic code (421) tells you it's a temporary security/policy refusal; the enhanced code (4.7.0) confirms it's a security/policy issue at the temporary level.
The Codes That Actually Matter for Throttling
| Error Code | Type | What it means and what to do |
|---|---|---|
| 421 4.7.0 | Temporary | Generic throttling. Retry with exponential backoff. Most common throttling response across all providers. |
| 421 4.7.1 | Temporary | Apple iCloud: "Messages deferred due to excessive volume." Reduce volume to iCloud and retry. |
| 421 4.7.28 | Temporary | Gmail: "Unusual rate of unsolicited mail originating from your IP address." Reduce volume aggressively. |
| 421 4.7.0 [TSS04] | Temporary | Yahoo: "Deferred due to unexpected volume or user complaints." Reduce volume and check complaint rate. |
| 421 4.3.2 | Temporary | Connection limit hit. Too many concurrent SMTP connections to the receiver. Reduce connection concurrency. |
| 451 4.7.650 | Temporary | Microsoft 365: throttling for possible spam or compromised accounts. Continued abuse escalates to 5xx. |
| 450 4.7.0 | Temporary | Mailbox temporarily unavailable or recipient-side issue. Retry after a few hours. |
| 550 5.4.5 | Permanent | Gmail: "Daily quota exceeded." You hit the daily cap. 24-hour block until the rolling window resets. |
| 550 5.7.232 | Permanent | Microsoft 365 trial tenant: TERRL exceeded. Hard block. |
| 550 5.7.233 | Permanent | Microsoft 365 non-trial tenant: TERRL exceeded. Hard block until 24-hour sliding window clears. |
| 550 5.7.606 | Permanent | Microsoft Outlook: blacklist or sender reputation block. Investigate reputation; pause sending. |
| 554 5.7.x | Permanent | Hard rejection by content filter or policy. Review content and reputation; do not retry without fixes. |
The single most important reading rule: 4xx is throttling, retry slower; 5xx is a block, fix the cause first. Senders who treat 4xx and 5xx the same way (retrying both at the same volume) compound the problem in both directions.
Expert Tip: Set up alerts on your sending platform for 4xx response rate spikes within rolling hour windows. A sudden increase in 421s within an hour is a stronger signal than the same count spread across a week. Track the ratio of 4xx to 5xx bounces - if your 4xx rate is climbing while 5xx stays flat, you're being throttled, not blocked. The early warning gives you 24-48 hours to react before throttling escalates to blocks.
What Are Gmail and Google Workspace Email Sending Limits in 2026?
Gmail and Google Workspace have the most variation in published limits because Google offers multiple sending interfaces with different caps.
| Sending Interface | Daily Limit | Recipients per Message | Notes |
|---|---|---|---|
| Gmail web interface (free) | 500/day | 100 | Rolling 24-hour window |
| Gmail SMTP submission (free, port 465/587) | 100/day | Same per-message limits | Restricted SMTP cap for free accounts |
| Google Workspace web interface | 2,000/day per user | 2,000 (max 500 external) | Standard Workspace cap |
| Google Workspace SMTP submission | 2,000/day per user | Same per-message limits | Same as web interface |
| Google Workspace SMTP relay | 10,000/day | Higher limits, configurable | Admin must enable |
| Brand-new Workspace accounts | 10-50/day initially | Same per-message limits | Behavioral throttling until reputation builds |
How Gmail Counts Recipients
This is the gotcha that catches most senders. Every recipient address counts toward your daily limit. To, CC, and BCC fields all consume quota individually.
An email to 10 CC'd people uses 10 of your daily quota, not one. This matters for any kind of bulk send through standard Gmail/Workspace; if you're BCCing a list of 1,000 recipients on a single message, those are 1,000 against your daily cap, not one.
The Behavioral Throttling Reality
Stated caps are ceilings; behavioral enforcement is the floor. Real-world Workspace throttling for cold outbound and aggressive marketing typically kicks in at:
- Brand-new Workspace accounts with no sending history: 10-50 emails/day for the first 1-2 weeks.
- Newer accounts with some history but high bounce rate: 100-200 emails/day.
- Established accounts with poor reputation signals: 500-1,000 emails/day.
- Established accounts with good reputation: full 2,000/day stated cap.
Cold email specifically: industry deliverability consultants typically recommend 25-50 cold emails per day per inbox even at established accounts because cold outbound generates lower engagement velocity and higher complaint rates than opted-in marketing.
Gmail SMTP submission: the 100/day cap most senders don't know about
When sending through Gmail using SMTP submission (port 465 or 587 for outbound from your client to Google) on a free Gmail account, the daily cap drops to 100 emails per day, not the 500 of the web interface. Google enforces this stricter cap for SMTP because it's the channel commonly used by automated tools and outbound marketing.
The 550 5.4.5 Daily Quota Exceeded Error
When you cross Gmail's daily limit, you get:
550 5.4.5 Daily user sending quota exceeded.
Learn more at https://support.google.com/mail/answer/22839 – gsmtp
Once you hit this, sending from that account is blocked for ~24 hours until the rolling window clears enough headroom. There's no way to lift it early.
What Are Microsoft 365 and Outlook Sending Limits in 2026?
Per-User Limits (Exchange Online / Microsoft 365)
| Limit Type | Value | Notes |
|---|---|---|
| Recipient Rate Limit (RRL) per user | 10,000 recipients per 24 hours | Counts both internal and external recipients |
| Message rate per user | 30 messages per minute | Hard ceiling; spikes above this throttle aggressively |
| Recipients per message (default) | 500 | Customizable 1-1,000 by admin |
| Recipients per message (max configurable) | 1,000 | Hard ceiling |
| SMTP AUTH connections per user | 3 concurrent | Limit on simultaneous outbound SMTP connections |
| SMTP AUTH messages per minute | 30 | Same as overall message rate |
| SMTP AUTH recipients per day | 10,000 | Same as RRL |
These per-user limits are identical across all Exchange Online plans, from the lowest-cost Business Basic to the highest-tier E5. Paying more for a larger plan does not get you higher per-user sending caps.
The TERRL Layer (Tenant-Wide External Limit)
The Tenant External Recipient Rate Limit (TERRL) is Microsoft's 2024-2026 enforcement of tenant-wide external sending caps. It's separate from and additional to per-user RRL. The formula is license-based, with phased rollout extending into April 2026 for the largest tenants.
TERRL counts only external recipients; internal mail (within accepted domains in your tenant) doesn't consume the budget. Once exceeded, Exchange Online responds with hard 5xx blocks:
550 5.7.232 Your tenant has exceeded its daily limit for sending email to external recipients. (Trial tenant)
550 5.7.233 Your message can't be sent because your tenant has exceeded its daily limit for sending email to external recipients. (Non-trial tenant)
There's no soft throttle for TERRL exhaustion - it's a hard block until the 24-hour sliding window clears headroom.
Outlook.com Personal/Free Accounts
| Account Type | Daily Recipients | Per-Message |
|---|---|---|
| Microsoft 365 Personal/Family | 5,000/day | 100 |
| Free Outlook.com | ~300/day (community) | 100 |
| Brand-new free Outlook.com | ~10-100/day | 100 |
The 2025 Bulk-Sender Authentication Enforcement
Starting May 5, 2025, Microsoft began enforcing SPF, DKIM, and DMARC alignment for bulk senders delivering 5,000+ emails per day into consumer Outlook.com, Hotmail, and Live.com inboxes. Senders who don't comply face stricter throttling and routing-to-junk regardless of other reputation signals.
Common Mistake: Don't assume Microsoft 365 corporate sends through your tenant are exempt from TERRL. Many admins configure third-party services that route mail back through Exchange Online for final delivery, and Microsoft can double-count those external recipients against your TERRL budget. If you're using any third-party routing, check whether you can add a mail flow rule using the References header to prevent double-counting.
Yahoo and Apple iCloud Sending Limits
Yahoo and Apple are less transparent than Gmail and Microsoft about specific limits. The practical limits are still real - senders run into them - but they're enforced behaviorally rather than as published caps.
Yahoo Mail Send Limits
Yahoo doesn't publish a formal daily-cap number. Instead, Yahoo enforces limits through:
- Cloudmark's fingerprint-based filtering and reputation tiers.
- Bulk-sender requirements: 5,000+ messages/day to Yahoo addresses requires DMARC-aligned authentication since February 2024.
- Sender Hub Insights metrics (launched October 2025) that track complaint rate from inbox-delivered mail.
- Connection limits and concurrent SMTP session caps.
Practically, new senders to Yahoo addresses get throttled in the 500-1,000/day range until they build a reputation.
The throttling response code from Yahoo is most commonly:
421 4.7.0 [TSS04] Messages from <ip> temporarily deferred due to unexpected volume or user complaints
Reduce volume to Yahoo immediately when you see [TSS04] responses; continued sending at the same rate amplifies the throttle and can escalate to 5xx blocks.
Apple iCloud Send Limits
Apple is the most opaque major provider. There's no public postmaster dashboard, no documented daily cap, no Sender Hub equivalent. Apple's filtering decisions are private:
- Apple uses dynamic throttling that's heavily reputation-driven.
- New senders to iCloud addresses get throttled aggressively until reputation builds.
- Mail Privacy Protection (introduced 2021) inflates open rates by pre-fetching images, making engagement-based limits less reliable for iCloud.
The throttling response is a 421 4.7.1:
421 4.7.1 Messages to [email protected] deferred due to excessive volume. Try again later.
Smaller and Regional Providers
Comcast, AT&T, EarthLink, Cox, Verizon, and most US regional ISPs use Cloudmark for primary spam filtering at the gateway. International providers (Yandex, Mail.ru, GMX, Web.de, and regional ISPs in Asia and Europe) vary widely; the universal foundations apply, but specific limits and behaviors differ.
How Can You Detect Email Throttling in Bounce Logs and Email Headers?
Detect throttling by monitoring three signals: (1) SMTP 4xx response rate in your bounce logs - watch for sustained 421 responses or per-provider spikes; (2) the email Received: headers, which show which servers handled the message and at what timestamps - gaps reveal silent throttling; (3) delivery timing analysis, comparing your SMTP transaction timestamp against actual inbox arrival timestamp.
Detection Method 1: Bounce Log 4xx Rate Monitoring
Every ESP and SMTP service produces a bounce log of failed delivery attempts. The actionable analysis:
- Track 4xx response rate hourly (not daily). Throttling shows up as spikes within hours, not steady-state.
- Track the ratio of 4xx to 5xx bounces. Throttling means rising 4xx with stable 5xx.
- Track 4xx response codes per receiving domain. Throttling at one provider (e.g., Gmail) but not others is a Gmail-specific reputation issue.
- Set up alerts for 4xx rate spikes within rolling 1-hour and 4-hour windows.
Detection Method 2: Reading Received: Headers
Email headers contain a chronological trail of every server that handled the message. The Received: headers (there are usually 3-6 of them) show the time and identity of each hop. Throttling shows up as gaps between hops.
A normal sequence:
Received: from sender-mta.example.com
by recipient-mta.gmail.com
with SMTP id ABC123
for <[email protected]>;
Wed, 06 May 2026 10:00:01 +0000
Received: from recipient-mta.gmail.com
by recipient-storage.gmail.com
with internal-relay;
Wed, 06 May 2026 10:00:02 +0000
Notice the timestamps: 10:00:01 to 10:00:02 - one second between hops. That's normal.
A throttled sequence:
Received: from sender-mta.example.com
by recipient-mta.gmail.com
with SMTP id ABC123;
Wed, 06 May 2026 10:00:01 +0000
Received: from recipient-mta.gmail.com
by recipient-storage.gmail.com
with internal-relay;
Wed, 06 May 2026 14:23:47 +0000
Same message, but the storage hop happened 4 hours and 23 minutes after the receiver accepted it. That's silent throttling.
Detection Method 3: Delivery Timing Analysis
The most direct test for silent throttling. Compare your SMTP transaction timestamp (when your sending server handed off the message) against the actual inbox arrival timestamp at a test account you control.
A consistent gap of 10+ minutes across multiple messages to the same provider is a throttling signal.
Key Insight: Silent throttling is invisible in standard ESP delivery reports. The ESP marks the message as "delivered" when the SMTP transaction completes successfully - the holding period that follows isn't reflected anywhere in standard reporting. The gap between SMTP transaction success and actual inbox arrival is one of the most under-monitored signals in deliverability.
Silent Email Throttling: Why Are Emails Delayed Without Bounce Errors?
Silent throttling happens when the receiving server accepts your mail (returning a successful SMTP response) but holds it for hours before delivering it to the inbox. There's no bounce, no error code, no notification. The message arrives 30 minutes to 12+ hours late.
Common causes of silent throttling:
- New or cold IPs that haven't built reputation - the receiver wants more time to evaluate.
- Volume spikes from previously stable senders - the receiver throttles to evaluate whether the spike is legitimate.
- Borderline reputation signals - not bad enough to reject, not good enough for instant inbox routing.
- Provider-side capacity issues - the receiver is overloaded and queues lower-priority mail.
- Authentication issues that pass technically but fail alignment - the receiver wants to evaluate before delivering.
Where Silent Throttling Matters Most
| Mail Type | Impact of 30-60 min delay | Impact of 4-12 hour delay |
|---|---|---|
| Password resets / OTP | Often unusable; user retries | Completely unusable |
| Order confirmations | Mild; user may worry briefly | User contacts support |
| Account verification emails | Risks signup abandonment | Signup abandonment near-certain |
| Marketing newsletter | Negligible | Negligible |
| Time-bound offer / flash sale | Reduced engagement window | Offer often expired by arrival |
| Webinar invitations | May miss event if invitation late | Event already happened |
For pure marketing newsletters, silent throttling rarely matters in absolute terms. For transactional and time-bound mail, it's a critical problem that standard delivery monitoring will completely miss.
What Is the Safest Email Ramp-Up Strategy for New Domains?
The ramp-up principle is the same at every provider: gradual volume increases, predictable cadence, sending only to highly engaged recipients during early stages.
| Week | Daily Volume | Audience | Critical Metric |
|---|---|---|---|
| Week 1 | 20-50 | Most-engaged recipients only | Establish baseline; bounce rate must stay below 1% |
| Week 2 | 50-150 | Top engagement decile | Open and reply rates should feel real |
| Week 3 | 150-400 | Top 25% of named target accounts (B2B) or active subscribers (B2C) | Reply rates indicate genuine engagement |
| Week 4 | 400-1,000 | Half of normal audience | 4xx error rate stays below 2% |
| Week 5-6 | 1,000-2,500 | Full named-account list / scaled cadence | Plateau here for a week before further ramp |
| Week 7+ | Steady ramp | Full audience | Maintain consistency; avoid sudden spikes |
Why 25% per week is the ceiling: Mailbox providers calculate behavioral baselines on rolling weekly averages. Increasing volume by more than 25% week-over-week is the threshold above which the increase looks like a list acquisition or compromised account.
Common Mistake: Don't treat "audience size" and "daily send volume" as interchangeable when planning ramp. A 100,000-subscriber list doesn't mean you should be sending 100,000 emails on day 30 of warm-up. Volume to highly engaged recipients matters more than volume across the full list.
How Do You Recover From Active Email Throttling?
If you're actively throttled with a 4xx response rate above 5%, sustained for hours or days, follow this sequence:
Phase 1: Stop the Bleeding
- Pause campaigns to the affected provider for 24-48 hours.
- Audit your bounce logs. Identify the specific error codes producing the throttling.
- Run bulk verification on the recipient list for the affected provider (uSpeedo's EmailVerify API supports batch verification).
- Verify authentication is passing. SPF, DKIM, and DMARC alignment all 100%.
- Check sender reputation in Postmaster Tools / SNDS / Sender Hub Insights. Confirm whether throttling is volume-driven or reputation-driven.
Phase 2: Gradual Resumption
- Resume sending to the affected provider at 25% of pre-throttle volume.
- Send only to the most engaged segment for the affected provider.
- Monitor 4xx error rate hourly. If it stays below 1%, ramp by 25% next week.
- Continue at reduced volume for 2-4 weeks even after throttling stops, to rebuild reputation.
Phase 3: Post-Recovery Hardening
- Build the monitoring rhythm: weekly Postmaster Tools review, hourly 4xx alerts.
- Implement preventive controls: real-time verification at signup, bulk verification on imported lists.
- Document the incident to prevent future occurrences.
ESP Throttling vs. Receiving Server Throttling
Throttling happens in two directions: receiving-server throttling and sender-side throttling, either imposed by your ESP/SMTP provider or implemented proactively by you.
ESP-Imposed Throttling
Your ESP or SMTP provider has its own rate limits to protect shared sending infrastructure:
- Daily volume caps based on your plan tier.
- Per-second or per-minute send rate ceilings.
- Concurrent connection limits.
- Burst capacity (short bursts above sustained rate).
Proactive Self-Throttling
This is the practice that separates sustainable senders from reactive ones. Self-throttling means deliberately limiting your send rate to stay below where receiving-server throttling would kick in:
- Cap send rate per provider per hour. Spread across 4-6 hours.
- Pause on rising 4xx rates. If 421 responses spike, reduce rate.
- Implement exponential backoff for retry attempts after 4xx responses.
Expert Tip: Proactive self-throttling - reducing your send rate before the receiving server makes you do it - keeps you in the throttling stage indefinitely without escalating. The cost is somewhat slower campaign throughput; the benefit is permanent reputation health.
What Common Mistakes Trigger Email Throttling Faster?
1. Treating 4xx and 5xx the Same Way
4xx is throttling - retry slower. 5xx is a block - fix the cause first. Senders who retry both at the same volume amplify problems in both directions.
2. Ignoring Stated Limits and Trying to Push Through
Stated limits (Gmail 2,000/day, Microsoft 10,000/day) are real ceilings. Crossing them produces 5xx hard blocks that take 24 hours to clear. Plan campaigns within stated limits; for higher volumes, distribute across multiple sending accounts or use SMTP relay configurations designed for that volume.
3. Counting Recipients Incorrectly
Recipients in To, CC, and BCC all count. A single email to 1,000 BCC'd people uses 1,000 of your daily quota at every provider, not one.
4. Assuming Throttling Is Volume-Only
Throttling triggers from many factors beyond raw volume: bounce rate, complaint rate, authentication failures, content red flags, sudden cadence changes. A sender at 1,000/day with 5% bounce rate gets throttled harder than a sender at 5,000/day with 0.1% bounce rate.
5. Increasing Volume After Seeing Clean Week-1 Metrics
Most domain burns happen in week 2-3 of a ramp. Week 1 metrics look clean because volume is low and audience is engaged. The temptation to accelerate is constant; resist it. Stick to 25% per week increases until you've plateaued at full volume for at least 1-2 weeks.
6. Sending Without Verification
Hard bounces from invalid addresses are one of the top throttling triggers, especially at low volume. A new Workspace account with a 15% bounce rate gets throttled aggressively even at 50/day. Verification before send is the single highest-leverage prevention against bounce-triggered throttling.
7. Not Separating Transactional From Marketing
Mixing transactional and marketing mail through the same sending domain means marketing-side throttling affects transactional delivery. Use a dedicated subdomain (e.g., notify.yourcompany.com) for transactional emails, with its own reputation, IP, and authentication.
8. Reacting Only When Delivery Rate Drops
Standard delivery rate doesn't reflect throttling - throttled mail still counts as delivered if it eventually arrives. By the time the delivery rate visibly drops, throttling has been ongoing for days or weeks. Monitor 4xx response rate hourly and per-provider.
How Verification Prevents Bounce-Triggered Throttling
Bounce rate is one of the top behavioral throttling triggers at every major mailbox provider. Hard bounces from invalid addresses signal poor list quality, which mailbox providers respond to by throttling aggressively. Verification at signup, on every imported list, and on a recurring schedule prevents bad addresses from ever entering the sending stream.
The 3 verification layers that compound:
- Real-time verification at signup forms: Catches typos and junk before they enter your database via uSpeedo's EmailVerify API.
- Bulk verification on imported lists: Run before any third-party list goes into active sending. Use the BatchVerifyEmail endpoint for batch processing.
- Quarterly bulk re-verification: Catch data decay over 6-12 months.
If you're running into throttling and haven't verified your list recently, that's the first place to look.
Key Insight: The economics of verification vs throttling: a typical bulk verification run on 100,000 addresses costs a fraction of recovery expenses and takes a few hours. Recovery from throttling-triggered reputation collapse takes 4-12 weeks of disciplined ramp. Verification is the cheapest deliverability investment that exists.
Frequently Asked Questions
What Is Email Throttling?
Email throttling is when a mailbox provider deliberately slows or temporarily refuses to accept your mail. It's signaled by SMTP 4xx response codes (most commonly 421) - different from 5xx codes which are permanent rejections. Throttling happens at three layers: stated limits, behavioral limits (dynamic thresholds based on your reputation, well below stated caps), and silent throttling (where the receiver accepts your mail but holds it for hours).
What Is an Email Send Rate Limit?
Email send rate limits are the maximum number of messages or recipients you can send within a specific timeframe - daily, hourly, or per minute. Major providers publish stated limits: Gmail free 500/day, Workspace 2,000/day per user, Microsoft 365 10,000 recipients/day per user with 30 messages/min, and Outlook.com 5,000 recipients/day. Behavioral enforcement is typically lower than stated caps, especially for new senders or those with reputation issues.
What Is SMTP Throttling?
SMTP throttling is rate-limiting at the SMTP protocol level - the receiving server delays or temporarily refuses your sending connection or message. Signaled by 4xx response codes in the SMTP transaction. Common triggers: too many concurrent connections, too many messages per minute, too many recipients per 24-hour window, or reputation-based behavioral limits.
How Do I Ramp Up Email Sending Without Getting Throttled?
Start at 20-50 emails/day from a fresh domain in week 1, increase by 25% per week if metrics stay clean, plateau at any 4xx error rate increase. Send only to your most engaged recipients during early stages. Never increase by more than 25% week-over-week. The full ramp takes 6-8 weeks to reach normal volume. Run verification on your audience list before starting the ramp - bounce-driven throttling is the most common ramp failure.
What Does Gmail Throttling Look Like?
Gmail throttling typically appears as 421 4.7.0 SMTP responses in your bounce logs, often with text like "Unusual rate of unsolicited mail" or "Temporary System Problem." More aggressive throttling shows up as 421 4.7.28. Hitting the daily quota produces a hard 550 5.4.5 "Daily user sending quota exceeded" 5xx error and a 24-hour block.
What Is the Daily Email Send Limit at Gmail and Workspace?
Gmail free: 500 emails per day, 100 recipients per message. Google Workspace: 2,000 emails per day per user, up to 2,000 recipients per message (max 500 external). Gmail SMTP submission (free): 100/day. Google Workspace SMTP relay: 10,000/day. All operate on a rolling 24-hour window, not a calendar reset.
What Is the Daily Email Send Limit at Microsoft 365?
Microsoft 365 / Exchange Online: 10,000 recipients per day per user, 30 messages per minute, 500 recipients per message default (configurable 1-1,000). Per-user limits are identical across all Exchange Online plans from Business Basic to E5. Plus the Tenant External Recipient Rate Limit (TERRL), a license-based formula that caps tenant-wide external sending. Free Outlook.com: ~300/day. Microsoft 365 Personal/Family: 5,000 recipients/day.
What Is TERRL in Microsoft 365?
TERRL is Microsoft's Tenant External Recipient Rate Limit - a tenant-wide cap on external recipients per 24-hour window, separate from the per-user 10,000/day RRL. The cap is calculated by a license-based formula, with phased rollout extending to April 15, 2026 for the largest tenants. Once exceeded, Exchange Online responds with hard 5xx blocks (550 5.7.232 for trial tenants, 550 5.7.233 for non-trial tenants).