Google Workspace SMTP Relay Limit: Four Ceilings, Not One

The Google Workspace SMTP relay limit that every sending-limit roundup quotes is 10,000 messages per user per 24 hours. That figure is real, it comes straight from Google's own relay documentation, and for most sends it is the wrong number to plan against.

The relay does not have one limit. It has four stacked ceilings and one structural rule, and a real send hits whichever of them its shape reaches first. Two of the four are per user, two are per organisation, and one of the per-user pair — the 10,000-message count — is mathematically unreachable unless every message you send goes to exactly one person. This page sets the four side by side, then works out which one binds for a send of a given shape, so you can size a campaign before you discover the ceiling from a rejection.

The Google Workspace SMTP relay limit, all four numbers of it

Google publishes these on the relay routing page. The last row is not a daily quota at all — it is a limit on how many addresses one SMTP conversation may carry.

Ceiling	The number	What it counts	What it takes to reach it
Per user, messages	10,000 per 24 hours	messages one relay user sends	10,000 messages each addressed to exactly one person
Per user, recipients	10,000 unique per 24 hours	distinct addresses one user sends to	100 messages of 100 recipients each
Per organisation, recipients	4,600,000 per 24 hours	recipients across every user in the domain	460 users each at their full per-user allowance
Per organisation, rate	319,444 recipients per 10 minutes	recipients accepted in any 10-minute window	32 users emptying an entire day's recipients at once
Per SMTP transaction	100 recipients	RCPT TO lines in one conversation	one message addressed to 101 people

The right-hand column is the part no ranking page works out, and it is the part that decides which number you actually need to care about.

Why the 10,000-message figure is unreachable for most sends

Put the two per-user ceilings next to each other and they interact. Call the average number of recipients on each of your messages r. You exhaust the recipient ceiling after 10,000 ÷ r messages. You exhaust the message ceiling after 10,000 messages. The two land in the same place only when r equals 1.

• At one recipient per message, both ceilings close at 10,000. The quoted number holds.
• At two recipients per message, you stop at 5,000 messages — half the figure in every roundup.
• At ten recipients per message, you stop at 1,000 messages.
• At the maximum 100 per transaction, you stop at 100 messages, having used 1% of your message allowance.

So the 10,000-message limit describes exactly one send shape: fully personalised, one address per message. That happens to be the shape of most campaign and transactional traffic, which is why the number gets quoted so confidently. But if you are sending anything with a cc list, a shared notification to a team, or a batched digest, the ceiling you will hit is the recipient count, and it arrives long before message ten thousand.

Sizing a send in four lines of arithmetic

Take R as the total recipients you need to reach in a day, r as recipients per message, and U as the number of Google Workspace users authenticating to the relay.

1. Users needed: R ÷ 10,000, rounded up. This is almost always the binding constraint, and it is a licence bill rather than a technical one.
2. Messages each user sends: (R ÷ U) ÷ r. If this exceeds 10,000, add users; the message ceiling has bitten before the recipient ceiling.
3. Share of the organisation ceiling: R ÷ 4,600,000. Under 460 fully loaded users this is never the limit.
4. Peak rate: recipients in your busiest 10-minute window against 319,444. Only a genuine burst gets near it.

Run those four and you will usually find the answer is step one and nothing else. The relay's headline number is a per-seat allowance, so scaling a send through it means buying seats, and the two organisation-wide ceilings sit so far above normal traffic that they never enter the conversation.

The 10-minute window is a burst rule, not a daily one

The 319,444-per-10-minutes figure gets reported as though it were a throttle you have to pace around all day. Multiply it out and it is not.

There are 144 ten-minute windows in 24 hours. 319,444 × 144 is 45,999,936 — very close to 46 million, which is ten times the 4.6 million the same organisation is allowed in a day. The rate ceiling permits ten days' worth of sending per day. It cannot be the thing that stops a normal send.

Turn the arithmetic the other way and it gets more useful: 4,600,000 ÷ 319,444 is 14.4 windows, or 144 minutes. An organisation pushing its entire daily allowance at the maximum permitted rate would spend it in two hours and twenty-four minutes and then sit idle for twenty-one hours. And because one user can contribute at most 10,000 recipients a day, filling a single 10-minute window to the brim needs 319,444 ÷ 10,000 ≈ 32 users all dumping their complete daily allowance inside the same ten minutes. If your send does not look like that, the window is not your problem, and spreading traffic out to respect it buys you nothing.

Worked example: 200,000 recipients on a Tuesday morning

A fully personalised send, one recipient per message, 200,000 people, and you want it out inside an hour.

• Users needed: 200,000 ÷ 10,000 = 20 relay users, each sending 10,000 single-recipient messages.
• Organisation daily ceiling: 200,000 ÷ 4,600,000 = 4.3% of the cap. Nowhere near it.
• Peak rate: an hour is six ten-minute windows, so 33,334 recipients per window against 319,444 allowed — about 10%. Even compressing the whole send into a single ten-minute window would put 200,000 against 319,444 and still pass.
• Transaction rule: irrelevant here, because r is 1.

Three of the four ceilings are untouched. The only one that binds is per-user, and it binds as a question of how many seats you are paying for. That is the honest answer to "can the relay carry 200,000 a day": yes, on twenty licensed users, and the pacing you were worried about was never the constraint.

Change one variable and the answer changes shape. Same 200,000 recipients at ten recipients per message: still 20 users, because the recipient ceiling is what those users are spending, but now each sends only 1,000 messages. Your message volume drops by 90% and your capacity does not improve at all — proof that on this service recipients are the currency and messages are just the packaging.

The repeat-send case, where the message count finally matters

There is one shape where the 10,000-message ceiling is the one that stops you: mailing the same list repeatedly. Google's wording is 10,000 unique recipients per user per day, so the second send to an address you already mailed consumes a message but no new recipient allowance.

A 2,000-address list mailed six times in a day is 12,000 messages against 2,000 unique recipients. The recipient ceiling is barely touched; the message ceiling closes after the fifth round. High-frequency operational mail — alerting, order status, anything that mails the same small set of people over and over — is the traffic that hits the number the roundups quote, and it is the one case where adding recipients to your list actually costs you nothing.

Not this limit: Gmail's own daily cap

The relay's limits are separate from the ones that apply when a user sends through Gmail. Google's Gmail sending-limits page lists 2,000 messages per day for a standard account, 1,500 for mail merge, 500 for a trial account, and 2,000 recipients per message with a maximum of 500 external recipients — and 100 recipients per message when sending via POP or IMAP with SMTP.

Those are a different door. smtp.gmail.com with a user's credentials is Gmail and gets Gmail's 2,000; smtp-relay.gmail.com on port 587 is the relay service and gets 10,000. Configuring the relay host but authenticating as a mailbox user, or the reverse, is the single most common reason an admin reports a limit five times lower than the documentation promises. Check which hostname your application is actually connecting to before you conclude the ceiling is wrong.

Two other configuration facts follow from the same page. Without TLS you may use port 25, 465 or 587, but you cannot use SMTP authentication and must authenticate by IP address instead. And Google Workspace no longer supports less secure apps, so credential-based sending has to go through OAuth.

The 100-recipient transaction rule is not a daily quota

The last row of the table is often misread as a per-day figure. It is not. RFC 5321 describes a mail transaction as a MAIL command, then "a series of one or more RCPT commands", then DATA, and notes that the recipient step "can be repeated any number of times". Google caps that repetition at 100 for the relay.

Practically: a message to 250 people has to be split into three transactions, and a well-behaved mailer does that for you. It costs you three messages against your 10,000 and 250 recipients against your other 10,000. It resets per transaction, not per day, so it never accumulates and never needs waiting out.

Trial and unbilled accounts sit lower

Google states that trial accounts have reduced limits and that an account must pay a Google-generated bill before relay capacity increases — a separate mechanism from the ordinary Gmail limit increases. If you are benchmarking the relay during a trial, the numbers above are not the numbers you will observe, and no amount of configuration will change that until billing has actually run.

Where the relay stops being the right tool

The relay is a good answer when your volume fits inside seats you already own and your mail is genuinely your organisation's own correspondence. It stops fitting at three specific points:

• When the seat maths turns silly. Needing twenty, fifty or two hundred Workspace users purely as sending capacity means you are paying per mailbox for something priced per message everywhere else.
• When you need per-message delivery data. The relay gives you SMTP acceptance and bounces. It does not give you opens, clicks, per-recipient event streams, suppression lists or webhook callbacks, and no ceiling adjustment adds them.
• When a ceiling is a business risk rather than an inconvenience. A per-user daily cap that resets on Google's clock is fine for internal notifications and awkward for a product whose signup flow stops working when it is reached.

If your send fits under the arithmetic above, the relay will carry it. If step one of the sizing keeps telling you to buy more mailboxes, the ceiling is not really the problem — the pricing model is.

Where these numbers come from

Every figure on this page is published by Google. The per-user and per-organisation relay ceilings, the 10-minute window and the 100-recipient transaction rule are on the relay routing page; the Gmail-side caps are on the sending-limits page; the definition of an SMTP transaction is in RFC 5321. Nothing here is estimated, and if Google changes a row the arithmetic changes with it.

Frequently asked questions

What is the Google Workspace SMTP relay limit per user?

Google publishes two per-user ceilings: 10,000 messages per user per 24 hours and 10,000 unique recipients per user per 24 hours. Both apply at the same time, so whichever one your send shape reaches first is the one that stops you.

Can I send 10,000 emails a day through the SMTP relay?

Yes, but only if each message goes to exactly one recipient. Because the 10,000 unique recipients ceiling applies in parallel, a send averaging two recipients per message stops at 5,000 messages, and one averaging ten stops at 1,000.

Does the 319,444 per 10 minutes rate limit slow down a normal send?

Almost never. There are 144 ten-minute windows in a day, so 319,444 per window works out to roughly 46 million recipients a day, which is ten times the 4.6 million an organisation is allowed in 24 hours. Filling one window would take about 32 users spending their entire daily recipient allowance simultaneously.

How many Workspace users do I need to send 200,000 emails a day?

Twenty, assuming one recipient per message: 200,000 divided by the 10,000 per-user recipient ceiling. At that volume none of the organisation-wide ceilings come close, so capacity is purely a question of how many licensed seats you authenticate with.

Why am I hitting a 2,000 a day limit instead of 10,000?

You are almost certainly sending through Gmail rather than through the relay. A standard Gmail account is capped at 2,000 messages a day on smtp.gmail.com, while smtp-relay.gmail.com on port 587 is the relay service with the 10,000 ceiling. Check which hostname your application actually connects to.

Why can I only add 100 recipients to a relay message?

Google caps one SMTP transaction at 100 RCPT TO recipients. It is a per-conversation rule rather than a daily quota, so a message to 250 people simply splits into three transactions and nothing accumulates or needs waiting out.