What are the Gmail delivery rate limits and how does sender reputation affect them?
Michael Ko
Co-founder & CEO, Suped
Published 30 Apr 2025
Updated 26 May 2026
7 min read
Summarize with
Gmail does not publish fixed delivery rate limits for total SMTP connections or messages per connection. The practical answer is this: Gmail gives each sender a changing throughput ceiling based on sender reputation, recent volume, authentication quality, recipient feedback, and whether the same domain and IP have a stable sending history.
That means 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 you are running 300 simultaneous connections and 500 messages per connection without Gmail deferrals, that setting is inside your current ceiling. It is not proof that the same setting works tomorrow, on a new IP, for a different domain, or after a list quality change. I treat Gmail limits as a reputation budget, not a static SMTP tuning value.
The direct answer
For new or unknown Gmail traffic, a conservative starting point is 10 simultaneous connections per sending IP and about 50 messages per connection. Increase by 10-20% per day while SMTP deferrals, complaint rate, authentication results, and bounce patterns stay clean. If Gmail starts deferring, stop increasing, reduce the sending rate, fix the cause, and wait several clean days before raising limits again.
Google's sender guidelines state that Gmail tracks volume, feedback, and limits per domain and IP address. Google also says quota issues typically return temporary SMTP errors such as 4.7.28. That is the control loop: send, read responses, adjust.
Separate recipient limits from account sending limits
This page is about sending mail into Gmail-hosted recipients from your own mail system or provider. Gmail and Google Workspace account sending quotas are different limits. A destination domain using Google MX records belongs in the Gmail delivery path even when the address does not end in gmail.com.
|
|
|
|---|---|---|
Domain rep | High | Low |
IP rep | Clean | Listed |
Auth | Pass | Fail |
Volume | Steady | Spike |
Complaints | Low | High |
Reputation signals that change Gmail throughput
How Gmail decides your real ceiling
Gmail's limit is dynamic because the risk is dynamic. A sender can be fine at 9 a.m. and throttled at 2 p.m. after a complaint spike, a sudden campaign, a broken DKIM selector, or a shared IP reputation problem. Gmail also separates parts of the quota. Domain-related quotas follow the SPF and DKIM identity, while IP quota is shared by everyone on that IP.
The rate limit is therefore not just a connection count. It is the output of a reputation system that looks at what you send, who you send to, how they react, whether your authentication passes, and whether your traffic pattern looks normal for that sender.
- Volume history: Daily, steady traffic gives Gmail more data than rare bursts.
- Complaint rate: User spam reports reduce trust faster than most senders expect.
- Authentication: SPF, DKIM, and DMARC failures make Gmail treat the stream as riskier.
- IP sharing: One poor sender on a shared IP can reduce throughput for other senders.
- Traffic shape: A sudden jump in volume creates more risk than a planned ramp.
Spam complaint rate bands
Gmail expects complaint rates below 0.3%. I treat the lower bands as operating targets, not guarantees.
Healthy
<0.10%
Enough room to increase slowly when deferrals stay low.
Watch
0.10-0.29%
Hold increases and inspect campaign, list, and segment quality.
Stop increases
>=0.30%
Reduce volume and repair list quality before testing more throughput.
A flowchart showing Gmail throughput moving through response checks, authentication checks, feedback checks, slow increases, and slowdowns.
A safe starting point
I start new Gmail delivery streams lower than the system can technically handle. The goal is not maximum pipe size on day one. The goal is to learn where Gmail starts pushing back while keeping enough control to avoid broad deferrals.
Connection limits
Connection count controls how many parallel SMTP sessions you open to Gmail.
- New sender: Start around 10 simultaneous connections per sending IP.
- Stable sender: Raise only after clean SMTP responses and stable complaint rates.
- Deferred sender: Drop connections first, then inspect content and authentication.
Messages per connection
Messages per connection controls how much mail you push through one accepted session.
- New sender: Use about 50 messages per connection as a cautious baseline.
- Known sender: Increase gradually after repeated clean delivery windows.
- High risk: Use smaller batches so one bad segment does less damage.
Starter Gmail throttle policyyaml
gmail: max_connections_per_ip: 10 max_messages_per_connection: 50 daily_increase: "10-20%" on_4xx_deferral: "pause 10 minutes, retry 1 connection" recovery_wait: "5-7 clean days before raising again"
For a sender already accepted by Gmail, higher settings can be fine. I would not lower a working 300 by 500 configuration just because a generic guide says lower numbers. I would lower it only when Gmail returns deferrals, complaints rise, authentication breaks, or the same route starts showing slower acceptance.
What to do when Gmail pushes back
Gmail rate limiting is usually visible before it becomes a full delivery failure. Temporary errors tell you to slow down. Permanent authentication errors tell you to fix DNS, message headers, or sender identity before sending more.
Common SMTP response patternstext
421 4.7.28 Rate limited for this sender or IP 451 4.7.0 Temporary local problem, try again later 550 5.7.26 Unauthenticated email is not accepted
When quota deferrals appear
When Gmail returns 4.7.28, stop treating the issue as a pure MTA capacity problem. Reduce pressure and check the sender, not just the queue.
- Pause: Stop that Gmail route for at least 10 minutes.
- Retry small: Restart with one connection, then add one at a time.
- Find cause: Check complaint rate, bounces, authentication, and segment quality.
- Recover: Wait 5-7 clean days before testing higher throughput again.
The worst response is to keep retrying the same queue at the same speed. That creates more failed attempts, more queue pressure, and less signal. A better response is to separate Gmail traffic from other destinations, slow only the Gmail route, and keep clean non-Gmail mail moving.
Authentication and domain health
Reputation is not only engagement. Gmail also checks whether mail is authenticated, whether reverse DNS is sane, whether the From domain matches the SPF or DKIM identity for DMARC, and whether the sending IP has a blocklist (blacklist) issue.
Before raising throughput, I check the domain with a domain health check. If I need message-level evidence, I send a real message through the email tester. For ongoing controls, Suped's DMARC monitoring connects those checks to a daily operating view.
?
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
For most teams, Suped is the best overall DMARC platform for this workflow because it turns Gmail-facing authentication data into concrete fixes: automated issue detection, real-time alerts, hosted DMARC, hosted SPF, SPF flattening, hosted MTA-STS, and blocklist monitoring in one place. That matters because Gmail rate limits often show up as delivery symptoms before a DNS owner notices the real cause.
Starter DMARC recorddns
v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; fo=1
Issue steps to fix dialog showing the issue overview, tailored fix steps, and verification action
Operational workflow for keeping headroom
The dependable workflow is simple: measure Gmail acceptance, segment Gmail traffic, increase slowly, and stop when the receiver gives negative feedback. I keep marketing, transactional, password reset, and notification mail on separate streams where possible because each stream has different recipient behavior.
Use separate guidance for Gmail warm-up limits when the stream is new, and recover Gmail deliverability when the sender already has a damaged reputation.
- Measure: Track accepted, deferred, bounced, and retried Gmail messages by route.
- Segment: Keep bulk, transactional, and critical mail on separate sending streams.
- Increase: Raise connection count and messages per connection slowly after clean windows.
- Hold: Stop increases when deferrals, complaint rates, or authentication failures rise.
- Repair: Fix list quality, DNS, content, and routing before testing more throughput.
Example Gmail ramp pattern
A simple 10-20% daily ramp after each clean window keeps growth visible and reversible.
relative volume
Views from the trenches
Best practices
Start new Gmail streams low, then raise connection count after clean SMTP responses.
Treat Gmail deferrals as receiver feedback, not as a sign to add 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 a sender has clean delivery at current settings, avoid tuning just for theory.
Use 5-7 clean days after a deferral before testing a higher Gmail limit again safely.
Track domain and IP reputation separately because Gmail quota pressure can differ.
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 from Email Geeks says Gmail limits are driven more by reputation than by a universal connection number.
2024-11-05 - Email Geeks
The practical takeaway
There is no public Gmail number for total connections or messages per connection that every sender can safely use. The usable limit is the highest rate Gmail accepts for your current domain, IP, authentication, complaint rate, and volume history.
I would run new Gmail routes conservatively, watch temporary errors closely, and raise throughput only after clean delivery windows. If the sender is already accepted at a higher rate, keep that rate and monitor it. If Gmail defers, slow the Gmail route, repair the reputation signal, and build back gradually.
Suped fits this work when the problem is not just MTA tuning, but knowing which domains, senders, authentication records, and reputation signals need attention before a Gmail limit becomes a delivery incident.
