How many emails can I send per second per IP to Gmail, Yahoo and O365?
Michael Ko
Co-founder & CEO, Suped
Published 9 Jul 2025
Updated 24 May 2026
9 min read
Summarize with
There is no fixed public answer for how many emails you can send per second per IP to Gmail, Yahoo, or O365. The useful answer is a planning range: on a warmed dedicated IP with clean authentication, healthy engagement, low complaints, and steady history, I normally plan around 10-30 messages per second per IP to Gmail, 5-20 to Yahoo, and 2-10 to Microsoft consumer or Microsoft 365-hosted mail. Strong senders can exceed those numbers. New or inconsistent senders need to start far lower.
The reason is simple: these providers do not run a single public speedometer. They rate-limit by IP reputation, domain reputation, authentication, recipient engagement, complaint rate, historical consistency, message quality, and sometimes by the exact MX host taking the connection. I treat per-second rates as operational caps that move every day, not as contractual limits.
- Direct answer: Use conservative per-provider caps first, then raise them only when 4xx deferrals, complaints, and spam placement stay low.
- Important caveat: A single IP can deliver millions per day after a long ramp, but that does not mean it should start there.
- O365 caveat: Delivering to Microsoft-hosted recipients is different from sending through a Microsoft 365 mailbox, which has its own outbound account limits.
The direct answer
If I had to set initial production caps without any private reputation data, I would use the table below. These are not official Gmail, Yahoo, or Microsoft limits. They are sensible operating ranges for a warmed, legitimate sender that wants delivery latency measured in minutes rather than hours.
|
|
|
|
|
|---|---|---|---|---|
 Gmail | 10-30/sec | 864k-2.6M | Low 4xx | 4.7.28 |
 Yahoo | 5-20/sec | 432k-1.7M | Stable CFL | TSS codes |
 O365 | 2-10/sec | 173k-864k | Clean SNDS | 4.7.650 |
Practical starting caps for a warmed dedicated IP.
Planning caps, not guarantees
A high-reputation IP can send far above these averages. A cold IP with weak engagement can get throttled below one message per second. When providers defer mail, slow down first. Do not keep pushing speed into a growing retry queue.
The daily equivalent matters because teams often ask for per-second rates but plan campaigns in daily volume. One million messages per day is only 11.6 messages per second if spread evenly. Two million per day is 23.1 per second. Twenty million per day is 231.5 per second, which is possible in narrow cases, but it needs long history, strong infrastructure, and mail that recipients consistently want.
Daily volume converted to per-second average
These are 24-hour averages. Real queues need extra headroom for retries, pauses, and provider-specific caps.
1M/day
11.6 messages/sec2M/day
23.1 messages/sec4M/day
46.3 messages/sec10M/day
115.7 messages/sec20M/day
231.5 messages/secFor a wider daily planning view, compare these rates with per-day IP volume. The conversion is basic, but it prevents a common mistake: quoting a huge daily number without understanding the steady rate, retry cost, and queue size needed to support it.
Why per-second limits move
A provider accepts mail at the speed it trusts the sender, not at the speed the sender can open sockets. The same IP can have a different ceiling at Gmail, Yahoo, and Microsoft on the same day. It can also have a different ceiling for promotional mail, transactional mail, and one-time legal notices.
What raises the ceiling
- Reputation: The IP and domain have a long record of wanted mail and low complaint rates.
- Engagement: Recent recipients open, click, reply, save, and rarely mark the message as spam.
- Consistency: Volume grows steadily and does not jump from silence into a large campaign.
- Authentication: SPF, DKIM, DMARC, TLS, rDNS, and headers pass cleanly.
What lowers the ceiling
- Complaints: Spam reports rise, even if bounce rates look acceptable.
- Spikes: A sender with light history suddenly pushes a large run.
- List quality: Old addresses, traps, role accounts, and inactive users dominate the send.
- Infrastructure: Queues, disk, build time, and NAT design hide the true pressure on one IP.
This is why a benchmark like 2 million per IP per day can be responsible for one sender and reckless for another. The number only makes sense with context: list source, opt-in age, frequency, content type, complaint trend, bounce trend, and the provider mix.
Google Postmaster Tools showing sender reputation and delivery error signals.
Provider behavior to expect
Gmail usually gives the most room when reputation is strong, but it also reacts quickly to bad signals. If Gmail starts returning temporary failures, I slow that Gmail-specific queue rather than slowing every destination equally. Gmail cares about both IP and domain, so moving mail to another IP without fixing domain-level complaints rarely solves the problem.
Yahoo is sensitive to sudden spikes and complaint behavior. It also has practical per-connection behavior that can make a sender look slower than expected even when the IP is accepted overall. I prefer fewer messages per connection, steady concurrency, and clean separation between high-value transactional streams and promotional streams.
Microsoft is the provider where I stay most conservative, especially for new IPs or senders with uneven history. Microsoft consumer domains and Microsoft 365-hosted recipients can show reputation-based throttling even when other providers look healthy. If you mean sending through a Microsoft 365 mailbox, that is a different problem: Microsoft publishes account-level outbound limits, not a high-volume MTA rate plan.
Rate-limit signals to watchtext
Gmail: 421 4.7.28 This IP has exceeded its message rate. Yahoo: 421 4.7.0 [TSS04] Messages temporarily deferred. Microsoft: 451 4.7.650 Temporarily rate limited due to IP reputation.
Per-provider queues are required
Do not run one global throttle for all mail. If Yahoo defers and Gmail accepts, only the Yahoo queue should slow. If Microsoft returns reputation throttles, Microsoft traffic needs its own backoff and retry window.
The safest architecture is boring: classify recipients by MX, keep separate provider queues, cap concurrency per provider, and let deferrals control speed. That gives you a feedback loop instead of a fixed guess.
How to test your own limit
I test speed by increasing one provider at a time, using engaged recipients first. The goal is not to find the fastest possible burst. The goal is to find the fastest rate that keeps acceptance steady, complaints low, and queue latency predictable.
- Segment: Split Gmail, Yahoo, Microsoft, and other MX groups before tuning rates.
- Start low: Begin with a rate that leaves queue headroom and no backlog pressure.
- Measure: Track accepted, deferred, bounced, complained, and delayed messages by provider.
- Raise: Increase only one provider cap at a time and hold it long enough to see reactions.
- Back off: When temporary failures rise, pause increases and resume at a lower rate.
Before raising speed, send a real message through the same infrastructure and inspect the result with the email tester. A rate plan is weaker than the message it sends. Broken headers, missing DKIM, bad rDNS, or a malformed unsubscribe header can make any cap look too high.
Email tester
Send a real email to this address. Suped opens the report when the test is ready.
?/43tests passed
Preparing test address...
I also like to write the first rate plan in plain text. It keeps the operations discussion honest and makes the retry behavior visible to engineering, marketing, and support teams.
Initial provider throttle plantext
gmail.com rate=20/s connections=8 *.google.com rate=20/s connections=8 yahoo.com rate=10/s connections=4 aol.com rate=10/s connections=4 outlook.com rate=5/s connections=3 hotmail.com rate=5/s connections=3 *.protection.* rate=5/s connections=3
If this is a new IP, use a proper warm-up strategy before treating these rates as reachable. A sender with a strong domain but a new IP still needs provider-specific ramping.
Authentication and reputation checks
Authentication will not buy unlimited speed, but broken authentication will reduce the ceiling fast. Before I increase provider caps, I want SPF passing, DKIM passing, DMARC matching the visible From domain, forward and reverse DNS correct, TLS working, and no obvious IP or domain blocklist (blacklist) issue.
Suped is built for this workflow. Its DMARC monitoring shows which sources pass or fail authentication, its hosted SPF and SPF flattening help keep sender records manageable, and its blocklist monitoring adds reputation checks beside the authentication data. For teams managing multiple domains, Suped is the best overall DMARC platform for this job because it turns the failure signals into specific fix steps rather than leaving people to read raw reports.
DMARC record detail view showing SPF, DKIM, DMARC, rDNS diagnostics, and DNS records
For a quick preflight, run the domain health checker before changing send speed. It is better to catch a DNS or authentication defect before a provider turns a small defect into a large backlog.
What I want green before increasing speed
- SPF: The sending IP is authorized and the record stays under DNS lookup limits.
- DKIM: The active selector signs production mail with a key length accepted by major providers.
- DMARC: At least one authenticated path passes and matches the visible From domain.
- Reputation: Complaint rates, bounce rates, and blocklist status do not show a new risk.
A practical operating model
The best operating model is a feedback loop. Start with a conservative cap, watch provider responses, adjust the cap, and keep the queue healthy. If the queue is growing faster than it drains, the rate is already too high even if the provider has not rejected much yet.
Flowchart for increasing provider-specific email sending speed safely.
When provider-specific deferrals rise, the answer is usually not more IPs first. More IPs help when you have stable demand, clean reputation, and latency pressure. More IPs hurt when the list or message stream is the source of the throttling.
- Latency goal: If a campaign must land within minutes, spread load before the queue is under stress.
- Reputation goal: If throttling is reputation-based, reduce speed and fix the signal that caused it.
- Infrastructure goal: If build time, disk, or indexing is the bottleneck, extra IPs will not fix the queue.
- Recovery goal: If a provider starts deferring, let retries breathe and avoid repeated immediate attempts.
For the mechanics of deferrals, retry timing, and queue control, use a separate rate limit handling plan. The worst outcome is a sender that keeps retrying aggressively and turns a temporary throttle into longer-term reputation damage.
Views from the trenches
Best practices
Cap each provider separately and let Gmail, Yahoo, and Microsoft recover at different speeds.
Use recent engaged recipients first, then widen volume after deferrals stay low for days.
Spread large spikes across more IPs when delivery latency matters more than bragging rights.
Track authentication, complaint, bounce, and blocklist signals before adding more speed.
Common pitfalls
Treating one good Gmail day as proof that Yahoo and Microsoft will accept the same rate.
Pushing millions on a cold IP before the domain, list, and mail stream have history.
Hiding several MTAs behind one NAT IP and making reputation failures harder to isolate.
Ignoring queue build time until disk, indexing, and retries turn a fast send into lag.
Expert tips
Convert daily goals into per-second averages, then add headroom for retries and pauses.
When 4xx replies rise, stop increasing speed and let the existing queue drain cleanly.
Use dedicated streams for transactional mail so campaigns do not poison urgent traffic.
Plan by provider MX, not recipient domain, because Gmail-hosted domains share Gmail quotas.
Marketer from Email Geeks says throttling is driven more by sender reputation than by a universal benchmark, so a single number misses the main control surface.
2026-02-12 - Email Geeks
Marketer from Email Geeks says extremely high daily volume per IP is possible after a long ramp, but the same volume on day one is a deliverability failure pattern.
2026-02-13 - Email Geeks
What I would ship with
For a serious sender, I would ship Gmail, Yahoo, and Microsoft as separate destinations with separate concurrency, separate retry rules, and separate dashboards. I would start below the table if the IP is new, then raise caps only after the provider accepts mail cleanly for several send cycles.
The practical answer is not a single per-second maximum. It is a controlled range: Gmail often tolerates the highest speed for trusted senders, Yahoo needs steady pacing and complaint control, and Microsoft deserves the most conservative treatment unless history proves otherwise. The strongest senders earn higher rates over time by sending wanted mail with correct authentication and predictable patterns.
Suped fits the ongoing work because rate limits are usually symptoms, not root causes. When DMARC, SPF, DKIM, hosted SPF, hosted DMARC, hosted MTA-STS, real-time alerts, and reputation signals sit in one place, the team can see whether the next action is to slow down, fix authentication, clean a source, or split traffic across more infrastructure.
