What does 'rate limit exceeded' mean in email delivery, and how do I troubleshoot it?
Updated on 24 Oct 2026: We clarified sending quotas, low-volume account restrictions, and provider-specific recovery steps for email rate limits.
A "rate limit exceeded" error means a mailbox provider or sending platform has applied a sending or receiving limit. The limit can depend on volume, sender reputation, recipient activity, or account quotas. Receiver-side throttling usually defers mail with a 4xx SMTP response, while some sending quotas return a permanent 5xx rejection. The right response is to slow the queue, read the raw SMTP or API response, group failures by provider and MX group, and fix the cause before retrying at the same speed.
Investigate a 2.5% delivery-error rate, especially when it exceeds the affected provider's normal baseline. Read the percentage beside the affected-message count, because a few failures can distort a small send while a lower percentage can still leave a large queue on a high-volume send. A single short spike can settle after the sending pattern returns to normal. A rising line across several sends needs investigation of the first error and its scope before assigning a cause. Waiting usually makes the queue older and the next retry burst noisier.
Set acceptance and bounce targets for each mailstream using historical provider-level data rather than one universal percentage. Track temporary deferrals separately from final bounces and complaints. Those metrics do not prove inbox placement. A message can be accepted by Gmail, Yahoo, Microsoft, or a corporate gateway, then land in spam, so rate-limit troubleshooting needs both acceptance metrics and inboxing signals.
Fast answer
- The sender crossed a provider's acceptable send rate for the current reputation, quota, connection, or recipient state.
- Pull the first raw bounce or deferral response with its timestamp, queue ID, sending IP, and sender domains, then separate Gmail, Microsoft, Yahoo, MX groups, and other providers.
- Measure deferral rate separately from final delivery rate, because delayed retries can hide the first failure.
- If the error names one receiving mailbox, isolate that recipient. If it names a sending account, API, or daily quota, check submission limits.
- If the error contains HTTP 429 or Retry-After, handle it as API throttling, not SMTP delivery throttling.
- Reduce send speed, pause nonessential mail, remove bad recipients, and ramp volume back gradually.
What the error means
Rate limiting is a traffic-control decision. Mailbox providers use it when a sender sends faster than the provider is willing to accept at that moment. The limit can apply to one mailbox, one domain, one IP address, one sending domain, one shared pool, one authenticated customer account, one MX group, or one pattern of mail that looks unusual compared with recent history.
Think about the limit at four enforcement points. The sending platform can enforce a daily, per-account, per-message recipient, or tenant quota. The receiving server can limit messages, recipients, or connections. A mailbox provider can apply dynamic throttling based on reputation and engagement. A connected mailbox or API channel can throttle requests even when SMTP delivery is healthy.
Do not mix account submission quotas with receiver-side throttles. Google Workspace and Microsoft 365 account or tenant limits tell you what the sending identity can submit, while MX replies tell you what the receiving provider is willing to accept right now. The owner, log source, and fix are different.
In Exchange Online, 550 5.7.233 identifies the Tenant External Recipient Rate Limit (TERRL), which counts external recipients across the organization in a sliding 24-hour window. Check the tenant's actual quota and usage in its mail flow reports instead of assuming a per-mailbox allowance or a midnight reset. Exchange Online sending-limit guidance documents the error and reporting workflow.
Some limits are recipient-side mailbox receiving limits, not sender-wide blocks. Microsoft 365 documents Exchange Online receiving limits at 3,600 messages per hour, with a single-sender-to-recipient threshold based on 33% of that receiving limit. When that kind of limit is exceeded, messages can bounce to the sender until the hourly window refreshes, so do not assume the recipient will receive the backlog later. The fix is to stop sending to that recipient temporarily, spread automated alerts over a longer period, or route operational notices to more than one monitored mailbox.
Outbound message rate limits and API throttles look different. They usually mention the sending account, submission channel, daily allowance, request limit, client submission rate, HTTP 429, or Retry-After. If the logs show a quota before the message reaches the remote MX, the repair belongs in the sending workflow. If the remote MX returns a 4xx code after connection, the repair belongs in pacing, recipient quality, authentication, or reputation.
If one message with many To, Cc, or Bcc recipients fails while smaller batches succeed, suspect a per-message recipient or SMTP transaction limit. Splitting a one-off message can confirm the scope. Recurring newsletters need a list workflow with individual envelope recipients, suppression handling, and unsubscribe controls instead of repeated large Bcc batches.
The wording matters. "Rate limit exceeded" is a label, not a root cause. The root cause is usually visible in the surrounding SMTP response, queue event, API response, or bounce reason. A message about "unsolicited mail" points toward reputation or complaint risk. A message about one user receiving mail too quickly points toward recipient-level throttling. A message about delivery time expiring means the message sat in retry until the sending platform gave up.
The following are shortened examples; preserve the full provider response in incident records. Gmail's SMTP error reference documents its provider-specific code meanings.
Common SMTP cluestext
421 4.7.0 Rate limit exceeded. Try again later. 451 4.7.23 Sending IP has no PTR record or mismatched reverse DNS. 451 4.7.24 SPF record has suspicious entries. 421 4.7.26 This email has been rate limited because it is unauthenticated. 421 4.7.27 SPF authentication did not pass. 421 4.7.28 Gmail has detected an unusual rate of email. 421 4.7.29 TLS is missing for a bulk sender. 421 4.7.30 DKIM authentication did not pass. 421 4.7.32 From domain does not satisfy DMARC matching requirements for authenticated SPF or DKIM. 421 4.7.40 Sending domain does not have a DMARC record or policy. 450 4.2.1 The user is receiving email too quickly. 452 4.5.3 Too many recipients in one transaction. 451 4.4.2 Timeout - closing connection. 421 4.7.0 [TS04] Messages temporarily deferred. 550 5.1.1 The email account does not exist.
A 4xx SMTP code means temporary failure, but the response text determines whether the cause is throttling, a connection problem, or another temporary condition. A 421 also closes the connection. The sender should retry later, but not blindly. If the same batch retries aggressively, the provider sees more of the same pressure. A 5xx code means a permanent rejection for that message or delivery attempt, but it does not always mean the address is bad. Suppress an address only when the enhanced status code and response text identify an invalid or inactive recipient. Authentication, content, and policy rejections need a configuration or message fix instead. A 452 can mean too many recipients, a storage issue, or a transaction limit, so inspect the enhanced code and text before deciding whether to retry.
When Gmail returns 4.7.28 for unusual rate, pause that Gmail lane for at least 10 minutes, resume with one connection, and add connections one at a time only after acceptance stabilizes. If the single connection still fails, wait another 10 minutes. If the text names an IP address, SPF domain, DKIM domain, URL domain, or repeated Message-ID, investigate that scope. If Gmail does not name a quota scope, assume the IP, SPF domain, and DKIM domain quotas are all affected.
Why rate limits happen after only a few emails
A rate limit after a small manual send does not prove a provider error. Outlook.com sending limits vary with usage history and subscription status, and new accounts start with lower quotas. These consumer-account limits are separate from Exchange Online business-mailbox limits.
- Count recipients as well as messages. Under a recipient-based quota, one email addressed to 20 people counts as 20 recipient deliveries.
- Include background sending by connected apps and devices. Automated alerts or a stuck retry loop can consume the same account quota as manual email.
- Review sign-in logs and sent mail for unauthorized activity, and check connected-app access and mailbox rules. If compromise is confirmed, stop the unauthorized sending, reset affected credentials, revoke sessions and unauthorized app access, and enable MFA before requesting an unblock.
- Check account restrictions and the documented quota window. Complete any verification requested through the provider's own account interface; a rolling 24-hour quota does not reset at local midnight.
If legitimate activity is below the applicable limit, contact the mailbox provider or administrator with timestamps, the full error, and sending counts. Microsoft's outbound sending guidance covers message traces and account restrictions, including checks for compromised sending.
Where to look first
Start in the raw delivery logs from your ESP or MTA, not the campaign summary screen. The summary tells you the error rate. The raw log tells you who limited you, what code they returned, whether the issue was temporary, and whether the same recipients already failed earlier.
Create two separate views before changing throttles: first-deferral rate and final delivery rate. First-deferral rate is the share of unique messages deferred on their first delivery attempt within the selected provider and time window; do not count every retry as a new message. Final delivery rate shows the share accepted after retries finish. Keep the provider and send cohort consistent when comparing the two.
- Start with the first day or hour where the error line jumped, then compare it with the prior send.
- Calculate deferral rate separately from hard bounces, soft bounces, and final delivery rate.
- Separate consumer mailbox providers, corporate domains, MX groups, and your own internal test addresses.
- Split 421, 450, 451, 452, 550, and 551 style events before making a recovery decision.
- Confirm whether the limit came from SMTP delivery, an API, a platform quota, or a connected mailbox channel.
- Look for phrases about unsolicited mail, low reputation, recipient rate, over quota, authentication failure, HTTP 429, Retry-After, and timeout.
Troubleshooting email rate limits: review logs, group providers, read SMTP responses, reduce sending, and ramp up.
When the affected provider is clear, focus there first. If only Gmail recipients were deferred, a global infrastructure change wastes time. If every provider slowed down at once, look at the sending platform, shared IP pool, authentication changes, an API throttle, connection pressure, or a campaign that exceeded the normal daily volume. Group by MX host when several domains share receiver infrastructure, because one shared receiver pool can hit a connection limit before the visible domains look busy.
How to identify the cause
Identify whether the limit applies to a recipient, sending source, account, or connection, then read the enhanced status code and full response to choose the fix. SMTP code meanings depend on the provider and response text.
|
|
|
|---|---|---|
Code 421 | Temporary service or connection failure; throttling is one cause | Read the full response, reconnect later, and reduce rate if throttled |
Code 450 | Temporary mailbox or recipient issue | Read the enhanced code and text before choosing a retry scope |
Code 452 | Recipient, storage, or transaction limit | Reduce recipients for transaction limits; check storage for mailbox-full errors |
Gmail 4.7.26, 4.7.27, 4.7.29, 4.7.30, 4.7.32, 4.7.40 | Authentication, TLS, or DMARC domain-matching failure | Fix the specific condition named in the response |
Gmail 4.7.28 | Unusual sending rate or reputation-related throttling | Pause and investigate the IP or domain scope named in the reply |
HTTP 429 or Retry-After | API throttle | Wait, then retry |
TS or TSS deferral | Yahoo traffic or trust issue | Segment Yahoo |
Repeated Message-ID | Repeated submissions or message-ID reuse | Use unique IDs for distinct messages; preserve the ID when retrying the same message |
Code 5.1.1 | Invalid recipient | Suppress address |
Over quota | Mailbox full or account limit | Wait for a sending-quota reset or resolve the receiving mailbox storage issue |
Low reputation | Trust issue | Reduce volume |
Time expired | Retry window ended | Review queue |
Quick mapping for common log clues.
"Delivery time expired" deserves special handling. Sending systems retry temporarily deferred mail for a configured window; check the platform's queue expiry setting rather than assuming a fixed duration. When the window ends, the platform records a failure even though the first problem happened much earlier. That means you need the first deferral event, not only the final timeout event.
Search strings for log reviewtext
rate limit exceeded unusual rate of mail unsolicited mail low reputation receiving mail at a rate delivery time expired over quota does not exist too many recipients Message-ID PTR record TLS required SPF authentication did not pass DKIM authentication did not pass TS04 TSS04 unauthenticated DMARC record 429 Too Many Requests Retry-After
Do not retry everything at once
A rate limit is feedback. Retrying the whole queue at full speed can make the next attempt look worse than the original send. Clear permanent failures first, keep deferred mail in its own lane, then reintroduce it at a slower pace with exponential backoff and random jitter. Check queue age and message expiry before retrying time-sensitive mail, and discard expired one-time codes or alerts.
Fix the sending pattern before retrying
The recovery plan should reduce pressure and improve signal quality at the same time. If the limit was caused by a sudden volume jump, send less. If it was caused by poor list quality, remove risky recipients. If it was caused by low reputation, keep only the most expected and engaged mail flowing until deferrals fall.
For persistent Yahoo or AOL deferrals, use the response text to distinguish reputation issues from volume or connection limits. If it identifies poor reputation, isolate the affected traffic, send only to recipients with recent confirmed activity, reduce retries, and address the cause before raising volume.
Good recovery plan
- Set separate message and connection caps for the affected mailbox provider.
- Cap messages per connection and recipients per SMTP transaction for the affected provider.
- Send transactional and recent-consent mail before broad promotional batches.
- Suppress confirmed invalid recipients and complainers, then quarantine stale or repeatedly deferred records for review.
- Keep severe Yahoo and AOL recovery traffic small, steady, and limited to active recipients.
Risky recovery plan
- Pushing the entire deferred queue back at the same provider can extend throttling.
- Treating invalid users, quota issues, and rate limits as one bounce bucket hides fixes.
- Jumping back to normal volume before deferrals settle creates another spike.
- Adding fresh IPs while the audience and complaints stay the same spreads the problem.
A practical ramp starts the affected provider lane well below the rate that triggered the limit. Hold that rate until acceptance and queue age stabilize, then raise it in small steps. Recover Gmail, Microsoft, and Yahoo lanes separately because each provider has its own view of the mailstream.
Example first-deferral action bands
Illustrative internal thresholds for unique messages deferred on their first attempt, measured for one provider and send cohort. These are not mailbox-provider rules or complaint-rate thresholds; adjust them to the normal baseline.
Within example baseline
Below 0.5%
Compare queue age and error text with the normal baseline.
Investigate
0.5% to below 2%
Pull raw logs and isolate the affected providers.
Act now
2%+
Throttle volume, clean recipients, and pause low-value mail.
A 2% deferral spike and a 99% final accepted rate can both be true if retries eventually clear. That is why first-deferral rate, final bounce rate, hard-bounce rate, complaint rate, and provider split need separate columns. A blended delivery number hides whether the issue was temporary queue pressure, bad addresses, or spam-folder placement.
Rate limits, throttling, and pauses
There is no universal safe sending speed. Treat published account quotas as hard ceilings, and use recent clean acceptance by mailbox provider as the operational baseline. During recovery, start well below pre-incident throughput and increase only while deferrals, complaints, and queue age remain stable.
For new domains or new dedicated IPs, sender warm-up means increasing volume only after providers accept the prior traffic cleanly. A schedule that doubles volume before the previous sends produce stable acceptance, low complaints, and clean authentication can turn a warm-up into reputation throttling.
Judge speed by accepted delivery, not by the number of messages the ESP handed to its outbound servers. A platform can inject mail quickly, then hit temporary failures at Gmail, Microsoft, Yahoo, corporate gateways, or a recipient mailbox that received too many automated messages. That looks fast in the campaign interface and slow in real inboxes.
Connection limits are separate from message rate limits. A provider can defer mail because the sender opened too many simultaneous SMTP sessions to the same MX group, even when the total message count looks reasonable. Cap concurrent connections per provider or MX group, lower recipients per minute for that lane, retry 4xx responses with longer exponential backoff, and let the queue drain before raising the rate.
Messages per connection and recipients per SMTP transaction matter too. For personalized marketing and transactional mail, one envelope recipient per message keeps retry handling, suppression, and tracking cleaner. High recipient counts fit internal announcements better than individualized customer mail.
Exponential backoff should be deliberate, not accidental. Use your MTA's documented retry schedule and provider-specific SMTP guidance, with increasing delays and random jitter so workers do not retry the same MX group together. Honor a Retry-After interval when an API supplies one. If SMTP deferrals continue, reduce concurrency and volume again instead of letting the queue keep hammering the same MX group.
If the error appears inside a connected mailbox app, check whether the limit came from the mailbox provider's API rather than SMTP delivery. Microsoft 365 and Microsoft Graph throttles often clear after request volume drops. Preserve the HTTP 429 response, request ID, and Retry-After value, wait for that interval, and reduce automation. If no Retry-After value is supplied, use exponential backoff. Switching to webmail does not reset an account-wide sending quota.
A pause is not the same as pacing
Smooth throttling adjusts throughput by recipient domain after temporary SMTP failures. A hard pause after a large burst usually points to an hourly cap, queue rule, backoff timer, platform policy, daily quota, API throttle, or manual campaign limit. It can protect reputation, but the ESP should explain the trigger.
- Ask for accepted, deferred, bounced, and retried counts by recipient domain.
- Ask for the SMTP response codes that triggered throttling or pausing.
- Ask for the exact time the queue paused, resumed, and completed retries.
- Ask whether the limit came from recipient feedback, sender reputation, platform policy, connection pressure, API throttling, or a hard quota.
- Ask for the maximum safe throughput recommended for the next urgent send.
Check authentication and reputation
Rate limiting is not always caused by authentication, but weak authentication can make rate limiting persist. If SPF breaks, DKIM stops signing, or DMARC checks fail on part of the mailstream, the provider has less evidence that the mail is legitimate. That matters most when volume also increases. Gmail bulk senders need SPF and DKIM plus a DMARC record with at least p=none. DMARC passes when either SPF or DKIM passes with the required match to the visible From domain; changing the DMARC policy alone does not clear a rate limit.
Gmail returns explicit rate-limit clues for unauthenticated mail, PTR problems, suspicious SPF records, SPF failure, DKIM failure, missing DMARC policy, From-domain mismatch, TLS problems, repeated Message-ID values, URL domains, and IP netblocks. Treat those as configuration or scope defects first, not as ordinary pacing issues, because slowing a broken source does not make the sender identity pass.
Run a broad check with the domain health checker if you need a fast view of DMARC, SPF, DKIM, and related DNS issues. Use DMARC monitoring to see which sources are passing authentication over time, and add blocklist monitoring when you need domain and IP reputation checks across major blocklists (blacklists).
DMARC record detail view showing SPF, DKIM, DMARC, rDNS diagnostics, and DNS records
Suped's product brings those checks into one workflow. For rate-limit investigations, use the context around a parsed record to identify which sending sources changed, which sources fail authentication, whether SPF lookup pressure increased, whether a domain or IP hit a blocklist (blacklist), and which fix should happen first.
What to confirm before ramping volume
- The DMARC policy, reporting address, and identifier matching mode fit the domains you send with.
- SPF evaluation uses no more than 10 DNS-querying mechanisms and modifiers, including nested includes, and authorizes only current senders.
- Each active sender signs DKIM with the expected selector and domain.
- Forward and reverse DNS for sending IPs match the active mailstream.
- For personal Gmail accounts, keep the daily user-reported spam rate below 0.1% and prevent it from reaching 0.3%; other providers use their own measurements and thresholds. See Gmail's sender FAQ.
- Gmail bulk senders' marketing and promotional mail has RFC 8058 one-click unsubscribe headers and a visible unsubscribe link; unsubscribe requests are honored within 48 hours.
- The sending IPs and domains are not newly listed on a major blocklist or blacklist.
Test a real message
A DNS check verifies published records. A real message test checks whether one message leaving your platform authenticates with those records. When rate limits appear after a platform change, template change, or new sending source, send a fresh message through the email tester and inspect the headers, authentication result, message content, and warnings.
Email tester
Send a real email to this address. Suped shows a results button when the test is ready.
?/43tests passed
Use the test result to answer specific questions. Did DKIM pass with a signing domain that matches the visible From domain under the configured DMARC mode? Did SPF pass for the actual envelope sender (Return-Path)? Did DMARC pass for the visible sender domain? Did the content include tracking domains that changed recently? None of those alone proves the rate limit cause, but they remove avoidable noise before you ask a provider to trust more volume.
How Suped fits into the workflow
Suped's product brings authentication and reputation signals into the same incident workflow. Use its DMARC reports to confirm active sources and authentication status, then check blocklist (blacklist) status and documented fix steps before restoring volume. DMARC aggregate reports arrive periodically and summarize authentication; raw SMTP deferral logs from your ESP or MTA remain the source of truth for provider codes, affected recipients, and queue timing.
Issue steps to fix dialog showing the issue overview, tailored fix steps, and verification action
For a rate-limit incident, confirm which authenticated sources sent mail in Suped, check whether authentication broke, and review new or unverified sources. Then correlate those findings with the provider-specific deferrals in your delivery logs and assign each fix to an owner. For MSPs and agencies, the multi-tenant dashboard keeps client domains separate while making cross-domain authentication or reputation issues easier to spot.
- Alerts notify teams when authentication or reputation signals change during an incident.
- Fix steps show specific actions for DNS, source verification, and authentication failures.
- Hosted records reduce DNS coordination for DMARC, SPF, and MTA-STS changes.
- The reputation view checks blocklist and blacklist signals alongside authentication data.
Views from the trenches
Best practices
Start with raw SMTP logs, then group failures by provider, code, and campaign window.
Track first-deferral rate beside final delivery rate before changing provider send speed.
Keep authentication clean so reputation checks do not compound a temporary send spike.
Common pitfalls
Treating every rate limit as a transient issue and leaving the queue untouched for days.
Looking only at aggregate bounces instead of isolating Gmail, Microsoft, and Yahoo traffic.
Retrying old, invalid addresses after a timeout, then adding hard bounces to the spike.
Expert tips
Compare the affected day with previous sends to find sudden volume changes per provider.
Read the provider wording before changing infrastructure, because the clue is often literal.
Pause low-value mail first, then let transactional mail recover on a steadier cadence.
Marketer view
Marketer from Email Geeks says reputation-based throttling often starts after an unexpected traffic spike that does not match the sender's previous pattern.
2023-08-17 - Email Geeks
Marketer view
Marketer from Email Geeks says the same label can mean too much mail to one recipient or too much mail for the current IP and domain reputation.
2023-08-17 - Email Geeks
