Email sending limits by provider (Gmail, Outlook, SMTP, SES)

Every mail provider publishes a sending limit and every one of them counts a different thing. Google counts messages per day and recipients per day as separate ceilings. Microsoft counts recipients per mailbox per day, messages per minute, and a tenant-wide external-recipient total calculated from your licence count. Amazon SES counts recipients rather than messages and expresses the limit as a rate as well as a total. Reading one provider's number as though it means what another's does is how teams discover a ceiling by hitting it mid-campaign.

Every provider counts a different unit, and that is the whole problem

Four units are in play, and no provider uses all four:

• Messages — one submission, regardless of how many people are on it.
• Recipients — one message to 50 people consumes 50.
• Unique recipients — the same address twice in a day counts once.
• Rate — messages or recipients per second or per minute, independent of the daily total.

A single ceiling of "10,000" therefore means at least four different things depending on whose documentation it appears in. For one-to-one cold outreach the message and recipient counts converge, since every send has exactly one recipient — which is convenient right up until a shared mailbox sends one internal announcement to 400 people and consumes a fifth of the day's budget in one submission.

There is also a fifth, invisible unit: the window. Google's limits reset "for up to 24 hours" after being hit. Microsoft's daily limits are a rolling 24-hour window, which behaves quite differently — Microsoft's own worked example has a user sending to 5,000 recipients at 09:00, 2,500 at 10:00 and 2,500 at 11:00, hitting the 10,000 ceiling, and then being unable to send again "until 09:00 AM the next day". Capacity returns at the hour it was consumed, not at midnight.

Google Workspace: five ceilings, and which one binds a one-to-one sender

Google publishes these per user, per day:

• Messages per day: 2,000, and 1,500 for mail merge, and 500 for trial accounts.
• Recipients per message: 2,000, of which a maximum of 500 may be external. Submitting via SMTP, POP or IMAP drops that to 100 recipients per message; the Gmail API allows 500.
• Total recipients per day: 10,000, or 1,500 for mail merge.
• External recipients per day: 3,000.
• Unique recipients per day: 3,000, of which 2,000 may be external, and 500 external for trial accounts.

Work out which one binds for cold outreach, where every message goes to one external person. Messages per day caps you at 2,000. Unique external recipients per day also caps you at 2,000. Those coincide, so the effective ceiling is 2,000 a day, and the 10,000 total-recipient figure that gets quoted in comparison tables is irrelevant to this use case entirely.

The trial-account row deserves separate attention because agencies hit it constantly. A Workspace trial is capped at 500 messages a day and 500 unique external recipients — a quarter of the paid ceiling. A fleet of trial tenants spun up for a launch will hit a wall at one quarter of the volume the planning assumed.

Google's SMTP relay service is a different product with its own limits and its own errors. Google documents a hard "100-recipient limit per SMTP transaction for smtp-relay.gmail.com" and error strings including "Daily SMTP relay limit exceeded for customer" and "Peak SMTP relay limit exceeded for customer", but does not publish the numeric value of either limit on its error-code page. Anyone quoting you a specific relay ceiling is inferring it from experience, not reading it from Google.

Microsoft 365: three limits per mailbox, plus one that lives above them

Exchange Online publishes these identically across Microsoft 365 Business Basic, Standard and Premium, and Office 365 Enterprise E1, E3 and E5:

• Recipient rate limit: 10,000 recipients per day per mailbox, on a rolling 24-hour window.
• Recipient limit: customisable up to 1,000 recipients per message.
• Message rate limit: 30 messages per minute.
• Recipient proxy address limit: 300 aliases per mailbox.
• Recipient limit for encrypted messages: about 200.

Submitting over authenticated SMTP adds a constraint that is not in the plan tables and that breaks integrations more often than any daily figure. Microsoft documents that "Up to three concurrent connections are allowed to send email messages at the same time", and a fourth receives 432 4.3.2 Concurrent connections limit exceeded. A sending worker with a pool of ten threads will produce that error continuously while every individual limit remains untouched, and the fix is connection pooling rather than a quota increase.

Exceeding the daily recipient limit over SMTP AUTH produces 554 5.2.0 STOREDRV.Submission.Exception:SubmissionQuotaExceededException. Exceeding the per-minute rate does not error at all — Microsoft says the excess "is throttled and successively carried over to the following minutes", so the symptom is unexplained latency rather than a failure, which is considerably harder to diagnose.

Microsoft also states its own position on the use case plainly: Exchange Online "isn't suited to accommodate bulk-mailing scenarios", and the documentation points bulk senders at Azure Communication Services email instead. That is worth reading as guidance about what the platform is engineered for, not as a formality.

The Microsoft tenant formula, worked at real seat counts

The limit most teams never see until it stops them is the Tenant External Recipient Rate Limit, or TERRL. Microsoft defines it as "the maximum number of external recipients a tenant can send to per day (24-hour sliding window)", where external means any address whose domain is not an accepted domain in the tenant. It applies across the whole tenant, above the per-mailbox ceilings, and it expands distribution groups first: a message to a group containing 1,000 external members counts as 1,000.

Microsoft Learn states that the limit "depends on the number of licenses a tenant has" and refers to its Exchange Team Blog for the detail. The calculation published there is 500 multiplied by the number of non-trial email licences raised to the power of 0.7, plus 9,500. Trial tenants are capped separately at 5,000 external recipients a day regardless of licence count, and the tenant's own figure is shown in the Exchange admin centre under Reports and then Mail flow.

Run it at sizes that matter:

• 1 licence — 10,000 external recipients a day.
• 5 licences — 11,043.
• 10 licences — 12,006.
• 25 licences — 14,259.
• 50 licences — 17,231.
• 100 licences — 22,059.
• 1,000 licences — 72,446.

Now compare that against the per-mailbox arithmetic. Ten mailboxes, each with a 10,000-recipient daily limit, sum to 100,000. The tenant ceiling for those ten licences is 12,006 — about 12% of the sum. The exponent of 0.7 is what does this: because it is below one, each additional licence buys less headroom than the one before, so the gap between the per-mailbox figure and the tenant figure widens as you add seats. A team planning capacity from the 10,000 figure alone will be wrong by nearly an order of magnitude, and will find out when a whole tenant stops sending at once rather than when one mailbox does.

Amazon SES: a rate, a daily total, and a sandbox that is a gate rather than a limit

SES states its counting rule at the top of its quota documentation: "Quotas are based on the number of recipients, rather than on the number of messages." A message to 30 recipients consumes 30 of the daily quota, not one.

A new account sits in the sandbox, per AWS Region, with three restrictions:

• 200 messages per 24-hour period.
• 1 message per second.
• Delivery only "to verified email addresses and domains, or to the Amazon SES mailbox simulator".

That third restriction is the important one. The sandbox is not a low quota you can grow out of by sending well; it is a gate that makes cold outreach impossible by construction, because no cold recipient is a verified identity in your account. Production access is requested through the console or the CLI, AWS provides "an initial response to your request within 24 hours", and the resulting quota is set from the use case you describe rather than from a published table — the documentation says only that it "varies based on your specific use case".

Two further fixed limits worth knowing: 50 recipients maximum per message, not adjustable, counting every address across To, CC and BCC; and a maximum message size of 10 MB via the v1 API or 40 MB via the v2 API and SMTP interface, both after base64 encoding.

The error strings, and what each one tells you to change

Match the string, then act. These are the exact texts each provider documents.

Volume limit reached, wait it out.

• 550 5.4.5 Daily user sending limit exceeded. — Google, per user.
• 550 5.4.5 Daily SMTP relay limit exceeded for user. — Google, relay service.
• 554 5.2.0 STOREDRV.Submission.Exception:SubmissionQuotaExceededException — Exchange Online, daily recipient limit over SMTP AUTH.
• 454 Throttling failure: Daily message quota exceeded — Amazon SES over SMTP; the API returns a ThrottlingException carrying Daily message quota exceeded.

Rate limit, slow down and retry.

• 454 Throttling failure: Maximum sending rate exceeded — SES. AWS's documented remedy is to "wait for an interval of up to 10 minutes, and then retry the send request".
• 432 4.3.2 Concurrent connections limit exceeded. — Exchange Online, more than three simultaneous SMTP AUTH connections. Fix the connection pool, not the quota.
• 450 4.2.1 The user you are trying to contact is receiving email too quickly. — Google, and note this is about the recipient, not you.

Reputation, not volume. Stop sending and diagnose.

• 421 4.7.28 Gmail has detected an unusual rate of unsolicited email originating from your DKIM domain — and the variants naming your IP address or your SPF domain. This is temporary rate limiting applied for cause.
• 550 5.7.28 — the permanent form of the same judgement.
• 550 5.7.1 This message is likely unsolicited email. To reduce the amount of spam sent to Gmail, this message has been blocked.

The distinction in that last group is the one that costs teams the most time. A 4.7.28 looks like a rate limit and reads like one, but Google's own wording attributes it to unsolicited mail rather than to volume. Raising your daily cap will not fix it, lowering it will not fix it either, and the thing to check is authentication and complaint rate. What the receiving side actually publishes about how it decides separates the two cases properly.

Why the provider limit is not the number you should be sending

A provider limit exists to protect the provider's infrastructure from abuse. It is not a statement about what recipients will tolerate, and the two are separated by more than an order of magnitude.

Placement is decided by authentication, complaint rate, bounce rate and sending pattern, and every one of those degrades long before a mailbox approaches 2,000 messages a day. A brand-new domain sending 300 on its first day is inside every published limit here and is behaving in a way no human mailbox ever has. The published ceiling has nothing to say about that, because it was never designed to.

The scaling answer is more mailboxes rather than a hotter one, which changes the arithmetic from "how high can this mailbox go" to "how many mailboxes, warmed for how long, to reach a target volume by a date". The email warmup planner models that tradeoff in the browser, and how many cold emails a day is actually safe covers the reasoning behind the per-mailbox figure. At fleet scale the binding constraints stop being provider limits at all and become ramp state, hourly pacing and sending windows, which is the subject of scaling outreach without wrecking deliverability.

Autocloz enforces per-mailbox daily and hourly caps with a minimum gap between sends, rotates across a mailbox pool, and ramps new mailboxes automatically through inbox warmup. Its free plan covers 5 users and 10 mailboxes with that pacing and the DMARC monitoring included — start free if the current setup is one mailbox and hope.

What these limits do not cover, and what Autocloz does not do

None of the published numbers describe placement. Every limit here governs acceptance — whether the provider will take the message from you. Whether a human sees it is decided afterwards by a filtering system that publishes no quota at all, and a mailbox comfortably inside every limit on this page can have all of its mail filed in spam.

The numbers also move. Google's limits page, Microsoft's Exchange Online limits page and the SES quota tables are all revised without a release note, and the Microsoft page carries a revision date inside the last six months. Treat any figure here as accurate as published on the date it was read, and check the vendor page before building a capacity plan on it.

And they are not portable between products. A Google Workspace ceiling says nothing about the Gmail API, an Exchange Online ceiling says nothing about Azure Communication Services, and an SES production quota is specific to one account in one AWS Region.

Autocloz specifically: it paces sends against the caps you configure and against its own ramp state, and it connects to Microsoft 365 and Outlook, Gmail and Google Workspace, Amazon SES and generic SMTP through the same email sending stack. It cannot raise a provider's limit, request a quota increase on your behalf, or see your Exchange tenant's TERRL value — that figure is visible only in the Exchange admin centre, under Reports and then Mail flow. It cannot tell you in advance which of several stacked limits will bind, because two of them are tenant-wide and one is a formula over your licence count. And it will not present a provider ceiling as a target, because the number that decides whether your mail is read is not on any of these pages.