Google Workspace Email Sending Limits: The Full 2026 Table
Google publishes the google workspace email sending limits as one table with six rows, and nearly every confused forum thread about a blocked account comes from reading one row while tripping a different one. The rows measure different things - messages, recipients, external recipients, per-message recipients - and an account can be nowhere near one ceiling while standing on another.
This is the whole table, then each row translated into the situation where it actually bites.
The google workspace email sending limits table
| Limit | Value for paid Workspace |
|---|---|
| Messages per day | 2,000 |
| Messages auto-forwarded | 10,000 |
| Recipients per message | 2,000 total, of which at most 500 external |
| Recipients per message via smtp.gmail.com or the Gmail API | 100 |
| Total recipients per day | 10,000 |
| Unique external recipients per day | 3,000 |
Trial accounts run on a reduced schedule - roughly 500 messages a day - until the domain converts to paid and ages a little. All the daily rows are rolling 24-hour windows, not calendar days, so capacity returns gradually starting 24 hours after each send, never all at once at midnight.
Messages versus recipients: the two currencies
The table charges you in two currencies at once, and every send spends both.
Send one message to 400 people: that is 1 message (of 2,000) and 400 recipients (of 10,000). Send 1,500 individual personalized emails: 1,500 messages and 1,500 recipients. The first pattern exhausts recipients long before messages; the second does the reverse. Mail-merge workflows - one message per recipient by design - are message-currency spenders, which is why a 2,000-row merge dies at exactly 2,000 no matter how few people it reached before.
Neither currency cares about content, size, or whether recipients are duplicates across messages. The counters are stupid on purpose, and their stupidity is what makes them predictable enough to plan around.
The external rows, where marketing dies
Two rows only count addresses outside your domain, and they are the ones campaign senders hit:
- 500 external per message caps how wide any single message can go beyond your organization, even though the same message could carry 2,000 internal addresses.
- 3,000 unique external per day caps your reach: after 3,000 distinct outside addresses in the window, additional new addresses bounce even if your message and total-recipient budgets are healthy. Re-mailing the same 3,000 people does not spend more of this row - it counts unique addresses, the only row that does.
Put together: a Workspace mailbox can, at absolute best, introduce itself to 3,000 new outside people per day. That is the hard shape of the product, and it is the number to compare against any list before choosing this route.
The odd row: 100 via smtp.gmail.com
Mail submitted programmatically - through smtp.gmail.com or the Gmail API - carries a stricter per-message cap of 100 recipients, regardless of the 2,000/500 row above. The web interface gets the generous per-message allowance; your script does not. This is the row behind bounces that say a message has too many recipients when the count seemed fine by the main table: the count was fine for a human, not for SMTP submission.
Design around it by batching programmatic sends under 100 recipients per transaction, or better, by sending one message per recipient and accepting that you are spending message currency.
What happens when a row trips
Google does not silently drop mail at these ceilings; it bounces with specific vocabulary, and the vocabulary names the row:
- 550 5.4.5 Daily user sending limit exceeded - message or total-recipient daily budget spent.
- Messages to external recipients language - one of the two external rows.
- Message has too many recipients - a per-message row, usually the programmatic 100.
Sending typically remains blocked for up to 24 hours from the moment of the trip. Nothing an admin clicks shortens it; the window is the window. The productive response is classification - which row, from which sending path - so tomorrow's job is shaped to fit.
Limits the table does not cover
Three adjacent systems have their own math and get wrongly debugged against this table. The SMTP relay service (smtp-relay.gmail.com) runs a separate 10,000-recipient-per-user allowance with its own configuration. Groups sending has per-group throttles managed elsewhere. And Google's bulk-sender requirements - authentication, one-click unsubscribe, spam-rate thresholds for anyone mailing thousands of Gmail inboxes - are policy gates layered on top of these mechanical ceilings; passing the table does not exempt you from them.
Reading your own consumption before it trips
Workspace gives no live meter, so the practical monitor is your own sending log: count messages and distinct external recipients over any trailing 24 hours and compare against the rows. For teams running steady operational mail, one glance at the busiest day of the last month tells you your margin. If that margin is under 3x - if a good Tuesday reaches a third of any ceiling - the workload is outgrowing a mailbox, and the graceful move is to a relay or a dedicated sending platform while everything still works, rather than after the Thursday when growth meets the wall mid-send.
The limits are not obstacles; they are the product's honest statement of what a mailbox is for. Reading all six rows together - not the one a search result quoted - is what turns them from surprises into a capacity plan.
Frequently asked questions
What are the Google Workspace email sending limits per day?
A paid Workspace account can send 2,000 messages per rolling 24 hours, reaching at most 10,000 total recipients, of which no more than 3,000 can be unique external addresses. Trial accounts are limited to roughly 500 messages until the domain converts and ages.
Do Google Workspace sending limits reset at midnight?
No. Every daily row is a rolling 24-hour window, so capacity returns gradually beginning 24 hours after each message was sent. An account blocked at 3 PM starts recovering around 3 PM the next day.
Why is my script limited to 100 recipients when the limit says 2,000?
Mail submitted through smtp.gmail.com or the Gmail API has its own 100-recipient-per-message cap. The 2,000-recipient per-message row applies to the web interface, not programmatic submission - batch under 100 or send individually.
Can Google raise my Workspace sending limits?
No, the published limits are fixed per account type. Volume beyond them belongs on the Workspace SMTP relay service for operational mail, or on dedicated bulk-sending infrastructure for campaigns - both exist precisely because mailbox limits do not negotiate.