Email Sending Limits by Provider: Google Workspace, Microsoft 365, and What Cold Email Really Allows

Google's sending limits page opens with the number everyone quotes: 2,000 messages per day. A team reads it, buys ten Google Workspace mailboxes, and builds a plan around 20,000 sends a day. Four rows further down the same table sits the figure that will actually stop them, which is 2,000 unique external recipients per day. For a cold campaign, where every recipient is external and every message goes to one person, those two limits are the same ceiling counted twice.

Microsoft's version of this trap is worse, because the limit that binds there is not attached to the mailbox at all. It belongs to the tenant, and buying more mailboxes inside that tenant does not raise it.

Here are the published figures for both providers, which limit binds in each case, and what happens when you cross one.

Google Workspace: the full table

Google publishes these in its Workspace knowledge base. The figures apply per user.

Nine of those twelve rows are irrelevant to a cold email programme, and working out which nine is the whole exercise.

Cold email sends one message to one person, and that person is always external. So every per-message recipient limit falls away immediately: 2,000 recipients per message, 500 external per message, 100 over SMTP, 500 over the Gmail API. None of them can bind when the recipient count per message is one. The 10,000 total recipients per day figure is similarly out of reach, because reaching it would require 10,000 messages and you are capped at 2,000.

That leaves three numbers in play, and they converge.

2,000Messages per day

The headline figure, and the one most plans are built on

3,000External recipients per day

Cannot bind first when messages cap at 2,000

2,000Unique external recipients per day

The real ceiling for cold sending, reached at the same moment as the message cap

500Trial account ceiling

Both messages per day and unique external recipients per day

The trial figure deserves attention out of proportion to its size, because of when it bites. New sending domains are typically set up on new Workspace accounts, and a new account is a trial account until it is paid. So the mailbox you carefully warmed for two weeks may be sitting on a 500-message ceiling and a 500 unique-external ceiling that nobody checked, and the campaign silently delivers a quarter of what was planned. Confirm billing status before you count a mailbox as capacity.

Microsoft 365: the same question, a different answer

Microsoft publishes its figures in the Exchange Online limits service description. The per-user numbers look generous.

A recipient rate limit of 10,000 per day per user reads like five times Google's allowance. Then you reach the Tenant External Recipient Rate Limit, which Microsoft abbreviates to TERRL and describes as "the maximum number of external recipients a tenant can send to per day (24-hour sliding window)".

Three properties of TERRL change how you plan.

It is tenant-wide. Every mailbox in the tenant draws from one shared pool of external recipients. The per-user 10,000 is a ceiling on an individual mailbox inside a budget the whole organisation shares.

It scales with licences rather than with mailboxes. Microsoft states that the limit "depends on the number of licenses a tenant has", and that admins can find their tenant's figure in the Tenant Outbound External Recipients report under EAC Reports and Mail flow. Microsoft does not publish a general formula, so the only trustworthy number is the one in your own report. Go and read it before planning against an assumption.

It counts distribution group members individually. Microsoft is explicit: "if someone sends a message to a group in the tenant that has 1,000 external recipients, it will be counted as 1,000 external recipients", counted "after the group (and its nested groups) is fully expanded to individual recipients". A single message can therefore consume a meaningful share of the tenant's daily external budget.

Google WorkspaceLimits attach to the user

• 2,000 unique external recipients per day, per user
• Each additional licensed user brings its own allowance
• Capacity grows in step with mailbox count
• No published organisation-wide external ceiling on this page
• Planning arithmetic is mailboxes multiplied by the per-user figure

Microsoft 365A tenant-wide ceiling sits above the user

• 10,000 recipients per day, per user, for all outbound and internal mail
• TERRL caps external recipients for the entire tenant
• The tenant figure depends on licence count, not mailbox count
• Trial tenants are capped at 5,000 external recipients per day
• Adding mailboxes inside one tenant does not raise the shared ceiling

The practical consequence is a planning rule rather than a preference. On Google, capacity is a multiplication. On Microsoft, capacity is whatever the EAC report says, and the per-mailbox arithmetic only tells you how that shared budget can be distributed.

The rolling window, and why it is not a midnight reset

Both providers meter over a moving window rather than a calendar day. Google's page states it plainly: "Limits per day are applied over a rolling 24-hour period, not a set time of day."

Microsoft illustrates the same behaviour with a worked example in its own documentation, and it is the clearest explanation of the mechanic anywhere in either vendor's docs.

1. 09:005,000 recipients

   A user sends to 5,000 recipients. The trailing 24-hour count stands at 5,000.

2. 10:002,500 recipients

   A second send. The trailing count reaches 7,500 of the 10,000 daily allowance.

3. 11:002,500 recipients

   A third send hits the 10,000 recipient rate limit exactly.

4. MidnightNothing happens

   The window is a trailing 24 hours, so the calendar date changing releases no capacity at all.

5. 09:00 next dayCapacity returns

   Microsoft: the user cannot send again until 09:00 the following day, when the first block of 5,000 falls out of the trailing window.

Read that timeline as a scheduling instruction. A programme that fires its whole daily volume in a burst at the same hour every morning permanently pins itself against the ceiling: capacity only returns at the hour it was consumed, so the burst and the reset chase each other around the clock and any overrun compounds into the next day. Spreading the same volume across the sending window keeps capacity rolling back continuously instead of in one lump, which is also what pacing for deliverability requires. The scheduling machinery that governs this sits in your sending tool, and how it behaves is covered in email sequencing tools.

What happens when you exceed a limit

The consequences differ by provider and by which limit you crossed, and none of them is a quiet failure you can ignore.

On Google, exceeding a sending limit produces error messages and the user cannot send new messages for up to 24 hours. Account access continues and incoming mail still arrives, so the mailbox looks healthy while it is unable to send. After the suspension period, Google resets the limits and sending resumes.

On Microsoft, the recipient rate limit blocks further sending until the trailing 24-hour count drops back below the threshold, which is the mechanic in the timeline above. The message rate limit behaves differently. Microsoft states that submissions over the rate via SMTP client submission "will be rejected and the client will need to retry", and its footnote adds that excess submission "will be throttled and successively carried over to the following minutes", typically without blocking the sender's account. The same footnote is worth quoting for what it says about intent: "Exchange Online isn't suited to accommodate bulk-mailing scenarios."

The pattern across both: a rate breach is a temporary rejection your tool must handle, and a daily breach is a suspension you cannot work around. Neither is a warning shot at reputation, which is a separate system entirely.

The ceiling that binds before any of these

Everything above describes what a provider permits. Permission is the loosest constraint on the page.

A single mailbox sending 2,000 cold messages a day is comfortably inside Google's published limits and far outside anything a receiving mail system will tolerate from a young domain. Receivers judge volume, ramp rate, complaint rate and engagement history, and they make that judgement per domain and per sending IP rather than against your Workspace licence. The provider ceiling and the reputation ceiling are two different systems, and the second one sits far below the first without publishing a number.

That is why sending capacity in practice comes from many mailboxes each operating well under their permitted rate, on domains kept separate from the primary company domain, warmed before they carry campaign traffic. Get the authentication underneath it right first, which is covered in SPF, DKIM and DMARC for cold email, watch what Gmail actually records about your sending in Google Postmaster Tools, and treat the wider infrastructure question as its own project using the cold email deliverability guide.

1. Step 1Start from the daily contact target

   Decide how many new people the programme needs to reach per day. This is the only number that comes from the business rather than from a vendor.

2. Step 2Divide by an operating rate, not the provider ceiling

   Use a conservative per-mailbox daily figure that reputation will tolerate. The published limit is a hard stop, never a target.

3. Step 3Check the tenant ceiling on Microsoft

   Read your TERRL from the Tenant Outbound External Recipients report under EAC Reports and Mail flow. On Google, multiply the per-user figure by licensed users instead.

4. Step 4Confirm every mailbox is paid, not trial

   Trial Workspace accounts cap at 500 messages and 500 unique external recipients per day. Trial Microsoft tenants cap at 5,000 external recipients per day.

5. Step 5Spread the volume across the window

   The 24-hour window is rolling, so capacity returns at the hour it was spent. Even pacing keeps it returning continuously and keeps you clear of per-minute rate limits.

The short version

Google Workspace allows 2,000 messages per day per user, 3,000 external recipients per day, and 2,000 unique external recipients per day, dropping to 500 messages and 500 unique external recipients on trial accounts. For one-to-one cold sending, the message cap and the unique-external cap describe the same wall, and every per-message recipient limit is irrelevant. Capacity scales with mailbox count.

Microsoft 365 allows 10,000 recipients per day per user and 30 messages per minute, with a recipient limit customizable up to 1,000 per message. Above all of that sits TERRL, the Tenant External Recipient Rate Limit, which caps external recipients for the whole tenant on a 24-hour sliding window and depends on licence count rather than mailbox count. Trial tenants are capped at 5,000 external recipients per day, distribution group members are counted individually after full expansion, and the only reliable figure is the one in your own Tenant Outbound External Recipients report. Adding mailboxes inside a tenant does not raise it.

Both providers meter over a rolling 24 hours. Microsoft's own example has a user hit 10,000 recipients by 11:00 and stay blocked until 09:00 the next morning, because capacity returns at the hour it was consumed. Exceeding a daily limit costs up to 24 hours of sending on Google and blocks Microsoft sending until the trailing count falls; exceeding the per-minute rate gets submissions rejected for the client to retry.

None of these is the constraint that decides whether the campaign works. Receiver reputation sits far below every published figure, judged per domain, and it is the number to plan against.

We run client sending across dedicated mailboxes on domains separate from the client's primary domain, paced well under provider ceilings. You can see what a campaign would look like for your market.

Provider limits verified against Google's and Microsoft's own documentation as of August 2026; the Microsoft service description page is dated 7 April 2026. Verify current limits with the provider before relying on them.

Sources: Gmail sending limits in Google Workspace, Exchange Online limits, Microsoft Learn