What are the Gmail delivery rate limits and how does sender reputation affect them?
Updated on 10 Oct 2026: We clarified Gmail throttling, SMTP retry handling, and the difference between delivery acceptance and inbox placement.
Gmail does not publish universal inbound SMTP delivery rate limits for total SMTP connections or messages per connection. The practical answer is that Gmail gives each sender a changing throughput ceiling based on sender reputation, recent volume, authentication quality, recipient feedback, and the sending history of the domain and IP.
A sender with strong reputation gets more headroom. A new sender, a sender with sudden volume spikes, a sender on a poor shared IP, or a sender with failing authentication gets less. Gmail exposes the limit through SMTP behavior, especially temporary deferrals, rather than a public number that applies to every sender.
If 300 simultaneous connections and 500 messages per connection produce no Gmail deferrals, that setting is inside the stream's current ceiling. It does not prove that the same setting will work after a volume spike, on a new IP, for a different domain, or after list quality changes. Treat Gmail limits as a reputation budget, not a static SMTP tuning value.
Gmail has no universal inbound SMTP rate limit
One illustrative starting configuration for new or unknown Gmail traffic is 10 simultaneous connections per sending IP and about 50 messages per connection. These are test settings, not a Google quota or a guaranteed safe allowance; a new sender can need lower limits. A 10-20% daily increase is an optional experiment only while SMTP deferrals, user-reported spam, authentication results, and bounce patterns stay stable. If Gmail starts deferring, stop increasing, reduce the sending rate, fix the cause, and wait for repeated clean windows before raising limits again.
Google's sender guidelines say to limit sending from a single IP based on the MX-record domain and to monitor SMTP responses so rates can be adjusted. Quota issues typically return temporary SMTP errors such as 4.7.28. The control loop is send, read the full response, and adjust the affected route.
Separate inbound throttling from account quotas
Inbound Gmail delivery limits control mail sent to Gmail-hosted recipients by an external mail system or provider. Gmail and Google Workspace account sending quotas, plus per-mailbox receiving limits, are separate from sender-wide throttling. Route traffic according to the recipient domain's MX record, because a custom domain with Google MX hosts belongs in the Gmail delivery path even when the address does not end in gmail.com.
|
|
|
|---|---|---|
Domain reputation | Strong | Poor |
IP reputation | Stable | Poor or unknown |
Authentication | Passes | Fails |
Volume pattern | Steady | Sudden spike |
Gmail user-reported spam rate | Below 0.10% | At or above 0.30% |
Reputation signals that change Gmail throughput
Requirements that affect Gmail throughput
Gmail's sender requirements apply to mail sent to personal Gmail accounts, which end in @gmail.com or @googlemail.com. All senders need SPF or DKIM, valid forward and reverse DNS, TLS, RFC 5322 formatting, and a Postmaster Tools spam rate below 0.30%. Google recommends staying below 0.10% so an occasional spike does not reach the enforcement threshold.
Google treats a sender that reaches about 5,000 messages to personal Gmail accounts in a 24-hour period under one primary domain as a bulk sender. Messages sent by subdomains count toward the same primary-domain total, and bulk-sender status does not expire once assigned. Gmail has actively increased enforcement against non-compliant traffic since November 2025, including temporary and permanent rejections. The 5,000-message threshold classifies bulk senders; it is not a daily delivery allowance.
- Authenticate bulk mail with both SPF and DKIM, and publish a DMARC record. Gmail accepts a DMARC policy of p=none for this requirement. Use DKIM keys of at least 1024 bits; Google recommends 2048 bits.
- Under relaxed DMARC alignment, the visible From domain must share an organizational domain with either the authenticated SPF domain or the DKIM signing domain. Strict alignment requires an exact domain match.
- Add RFC 8058 one-click unsubscribe to marketing and subscription messages, keep a visible unsubscribe link in the body, and honor requests within 48 hours.
- Keep transactional mail, such as password resets and reservation confirmations, separate because Gmail excludes it from the one-click unsubscribe requirement.
One-click unsubscribe headerstext
List-Unsubscribe-Post: List-Unsubscribe=One-Click List-Unsubscribe: <{HTTPS_UNSUBSCRIBE_ENDPOINT}>
The HTTPS unsubscribe endpoint must process the POST request without a sign-in or confirmation step. A valid DKIM signature must cover both unsubscribe headers. A mailto-only header or a body link alone does not meet Gmail's one-click unsubscribe requirement.
How sender reputation affects Gmail throttling
Gmail's limit is dynamic because sender risk changes. A stream can be accepted in the morning and throttled later after a complaint spike, a sudden campaign, a broken DKIM selector, or a shared IP reputation problem. Read the complete SMTP response because a 4.7.28 error can identify an IP, IP netblock, SPF domain, DKIM domain, URL domain, or repeated Message-ID as the affected quota or signal.
The usable rate is more than a connection count. Gmail evaluates sending patterns, user-reported spam, authentication, domain and IP reputation, list quality, and whether recipients expected the mail. An IP quota is shared by all domains sending through that IP, while SPF and DKIM quotas are domain-specific. Switching IPs does not remove a domain quota.
- Steady daily volume gives Gmail a more predictable history than rare bursts.
- User spam reports reduce trust and can lower inbox placement as well as throughput.
- SPF, DKIM, and DMARC failures can cause rate limiting or rejection before concurrency becomes relevant.
- Poor traffic from another sender on a shared IP can reduce available headroom.
- Invalid recipients, stale lists, and weak consent increase bounces and complaints.
Do not use open rate as a direct Gmail reputation or quota control. Google says it does not track open rates and cannot verify the accuracy of open metrics reported by third parties. Use user-reported spam, deferrals, bounces, authentication results, and domain or IP reputation data instead.
Spam complaint rate bands
Google recommends staying below 0.10% and avoiding 0.30% or higher. These operating bands do not guarantee a specific delivery rate.
Low reported spam
<0.10%
Increase slowly only while deferrals and other reputation signals stay stable.
Watch
>=0.10% and <0.30%
Hold increases and inspect campaign, list, and segment quality.
Stop increases
>=0.30%
Reduce volume and repair consent or list quality before testing more throughput.
Gmail email throttling workflow: monitor SMTP responses, check authentication and recipient feedback, then adjust the sending rate.
Gmail acceptance is different from inbox placement
A final 250 response after SMTP message submission means Gmail accepted the message. It does not establish whether the message reached the inbox or spam folder. The Promotions tab is part of Gmail's inbox, so placement there is not a delivery failure.
|
|
|---|---|
Accepted throughput | Messages Gmail accepts per minute, measured separately from attempted sends and retries. |
Deferral rate | The share of SMTP delivery attempts receiving temporary 4xx responses. |
Queue age | How long the oldest undelivered message has been waiting; growth shows a delivery backlog. |
Inbox placement | Where accepted messages appear; a successful SMTP response does not provide this result. |
Metrics for Gmail throttling and placement
Gmail's user-reported spam rate measures complaints about mail delivered to the inbox, not all messages attempted or automatically filtered into spam. A low rate does not prove good inbox placement. Missing data is not a zero complaint rate: privacy thresholds and reporting delays limit the available evidence. Use live SMTP logs for rate control and Gmail's reporting data for longer-term diagnosis.
An illustrative Gmail throttle starting point
Start new Gmail delivery streams below the mail system's technical capacity. Connection count and messages per connection do not define messages per minute. Set a destination sending-rate cap as well, and spread traffic evenly rather than releasing the queue in bursts.
Connection limits
Connection count controls how many parallel SMTP sessions open to Gmail.
- Test around 10 simultaneous connections per sending IP only as an example; start lower when sending history is limited.
- Raise a stable sender only after clean SMTP responses and low user-reported spam.
- Reduce connections for a deferred sender, then inspect content, consent, and authentication.
Messages per connection
Messages per connection controls how much mail moves through one accepted session.
- Treat about 50 messages per connection as an illustrative test setting, and reduce it if Gmail defers.
- Increase a known sender gradually after repeated clean delivery windows.
- Use smaller batches for a high-risk segment so it can be isolated quickly.
Illustrative Gmail throttle configurationyaml
gmail: max_connections_per_ip: 10 max_messages_per_connection: 50 daily_increase: "optional 10-20% test after a clean window" on_4_7_28: "pause at least 10 minutes, retry 1 connection" on_other_4xx: "back off and investigate the full SMTP response" recovery: "raise only after stable acceptance and normalized deferrals"
Higher settings can be reasonable for a sender that Gmail already accepts. Keep a tested configuration while acceptance and reputation signals stay stable. Lower it when Gmail returns deferrals, user-reported spam rises, authentication breaks, or acceptance slows.
How to handle Gmail SMTP deferrals and rejections
Temporary 4xx responses require queued, slower retries and investigation of the full response. Treat a 5xx as a permanent failure for that message; do not automatically retry it unchanged. Fix authentication or policy errors before a new send, and suppress confirmed invalid recipients such as those returning 550 5.1.1. A policy rejection does not by itself mean the recipient address is invalid.
Common Gmail SMTP response patternstext
421 4.7.28 Unusual rate of email; temporarily rate limited 421 4.7.26 Unauthenticated email; temporarily rate limited 451 4.7.23 Missing or mismatched PTR; temporarily rate limited 550 5.7.26 Unauthenticated email rejected under the domain's DMARC policy
When quota deferrals appear
When Gmail returns 4.7.28, inspect the full response to identify whether it names an IP, netblock, SPF domain, DKIM domain, URL domain, or Message-ID. Reduce pressure on the affected route and investigate that signal. If the response does not identify the exceeded quota, assume the SPF, DKIM, and IP quotas are all affected.
- Stop sending on that Gmail route for at least 10 minutes.
- Restart with one connection. If it fails, wait another 10 minutes.
- If one connection succeeds, add connections one at a time while watching responses.
- Check user-reported spam, bounces, authentication, volume changes, list quality, and the specific identity named in the error.
- Resume growth only after deferral rates normalize across repeated clean delivery windows.
The pause and single-connection restart follow Google's retry guidance. Apply them to quota deferrals and investigate authentication or DNS failures separately.
Do not retry the same queue at the same speed. That creates more failed attempts and queue pressure. Separate Gmail traffic from other destinations, slow only the Gmail route, and keep clean non-Gmail traffic moving. Monitor queue age, stagger retries, and avoid releasing the entire backlog as soon as one connection succeeds.
Authentication and domain health
Reputation includes more than recipient behavior. Gmail checks authentication, forward and reverse DNS, TLS, message formatting, and whether an authenticated SPF or DKIM identity has DMARC alignment with the From domain. IP reputation and blocklist (blacklist) findings also help explain delivery symptoms, although an external listing is not a direct measure of Gmail's hidden quota.
Before raising throughput, check the domain with a domain health check. For message-level evidence, send a real message through the email tester. Suped's DMARC monitoring connects authentication checks to a daily operating view.
?
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
Suped is our DMARC and email authentication platform. It collects aggregate DMARC reports, identifies SPF and DKIM alignment failures, alerts teams to authentication changes, and provides DNS remediation steps alongside blocklist monitoring. Suped does not expose Gmail's hidden connection ceiling, so use those findings with SMTP responses, Postmaster spam data, and queue metrics.
Starter DMARC TXT record at _dmarc.example.comdns
v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com
Replace the example reporting address with a working destination for aggregate DMARC reports. The p=none policy requests no DMARC enforcement; publishing it does not guarantee higher Gmail throughput. DMARC reports show authentication results and reported handling, not inbox placement.
Issue steps to fix dialog showing the issue overview, tailored fix steps, and verification action
Operational workflow for keeping headroom
The dependable workflow is to measure Gmail acceptance, segment Gmail traffic, increase slowly, and stop when the receiver gives negative feedback. Keep marketing and transactional mail on separate streams, with priority for time-sensitive security messages and account notifications. After an IP change, a new DKIM signing domain, or a major message-format change, increase the affected traffic separately.
Use separate guidance for Gmail warm-up limits when the stream is new, and follow the steps to recover Gmail deliverability when the sender already has a damaged reputation.
- Track accepted, deferred, bounced, and retried Gmail messages by route and sender identity, including queue age and messages accepted per minute.
- Separate bulk campaigns, transactional mail, security messages, and account notifications.
- Adjust one throttle setting at a time only after a clean delivery window, and spread the resulting traffic evenly.
- Hold increases when deferrals, user-reported spam, or authentication failures rise.
- Repair consent, list quality, DNS, content, or routing before testing more throughput.
Example Gmail ramp pattern
This illustrative 10-20% daily ramp is an operational test, not a Gmail-published allowance. Continue only after each clean window.
relative volume
Field experience with Gmail rate limits
Best practices
Start new Gmail streams low, then raise connection count after clean SMTP responses.
Treat Gmail deferrals as receiver feedback instead of adding more queue pressure.
Separate essential mail from bulk campaigns so one stream cannot slow every message.
Review authentication and list quality before changing MTA concurrency settings.
Common pitfalls
Using one universal Gmail limit across senders ignores reputation and sending history.
Increasing volume during deferrals turns a small limit event into a bigger issue.
Trusting high engagement while ignoring complaints leaves reputation risk hidden.
Sharing an IP without sender controls lets one tenant reduce everyone else's headroom.
Expert tips
After a Gmail quota error, pause the route, retry one connection, then increase slowly.
If Gmail accepts the current settings cleanly, avoid tuning only for a generic baseline.
Wait for normalized deferral rates across repeated clean windows before raising volume.
Track domain and IP reputation separately because Gmail quota pressure can differ.
Marketer view
Marketer from Email Geeks says Gmail does not publish fixed connection or messages-per-connection limits, so SMTP response monitoring is the control point.
2024-11-05 - Email Geeks
Marketer view
Marketer from Email Geeks says Gmail limits are driven more by reputation than by a universal connection number.
2024-11-05 - Email Geeks
