Say a 12-person insurance brokerage calls on a Tuesday afternoon. The office manager sent the monthly renewal notices from her own mailbox, the way she has for three years, and partway down the list Gmail stopped her. Some clients received the notice. Some did not. Nobody in the office can say which, and the failures came back as a bounce nobody can read.
Nothing is broken here. This is a quota. Google publishes a set of per-user ceilings for Gmail, and once a mailbox crosses one, that mailbox sends nothing new for up to 24 hours. You cannot buy your way past them and support cannot lift them for you, so the only useful questions are which ceiling you hit, and which channel that volume should have travelled on instead.
What a ceiling looks like from the inside
A sending limit shows up in three different places, and the three look nothing alike.
In the Gmail interface the send refuses, with a message saying a sending limit has been reached. Nothing reaches the recipient, and a copy often sits in Sent anyway, which is why people are sure it went out. When the mail leaves through an app, a script or an add-on authenticated as that user, the refusal arrives as an SMTP rejection and the user never sees it. The person who finds it is whoever reads the application log, usually days later.
When the mail goes through the Workspace SMTP relay, Google is specific about which ceiling applies. Its error list names three separate conditions: Daily SMTP relay limit exceeded for user, Daily SMTP relay limit exceeded for customer, and Peak SMTP relay limit exceeded for customer. The first two are a stop for the day. The third is temporary, and Google states that relay mail for the account is deferred rather than rejected while it applies. The same page warns that the error may never reach a human at all, because the sending server has to accept a non-delivery report for the message to come back.
The record that settles the argument is Email Log Search in the Admin console. It gives the event per message, per sender, with the reason attached, which is the only way to answer the brokerage's real question: which of those 300 renewal notices actually went out, and to whom.
The caps, as Google lists them
These are the list values on Google's own Gmail sending limits page for Google Workspace, checked 20 October 2026. Google states on that page that the limits can change without notice, so treat any copy of them, this one included, as a figure to verify on the day you need it.
- 2,000 messages a day per user account. 1,500 a day when the send goes out as a mail merge, and 500 a day on a trial account.
- 2,000 recipients per message, counted across To, Cc and Bcc, with no more than 500 of them external to your Workspace account.
- 10,000 total recipients a day, counted on every send: five messages to ten addresses spends fifty of the allowance, not five. A mail merge counts against 1,500 instead.
- 3,000 unique recipients a day, counting each address once however often you write to it, and 3,000 external recipients a day.
- 500 recipients per message over the Gmail API, and 100 per message for mail a POP or IMAP user sends over SMTP.
- Mail that is auto-forwarded by a filter or a forwarding rule is not counted against the daily sending limit. It carries its own ceiling of 10,000.
Two of these trip small companies far more often than the headline 2,000. The recipient count is the first: an eight-message update to a 400-address list is eight messages and 3,200 recipients, so the 10,000 recipient ceiling arrives long before the message count does. The rolling window is the second. The daily figures do not reset at midnight, they run over the preceding 24 hours, so a send that started at 4pm yesterday is still spending the allowance at 10am today. That is why a limit reached on Tuesday evening feels like a limit that lasted all of Wednesday morning.
When it is not the limit at all
Roughly half the cases that arrive described as a sending limit turn out to be something else. Three problems feel identical from the sender's chair: it worked yesterday, it stopped today, and some recipients got the message.
The first is rate limiting rather than a quota. Gmail defers mail with a 4xx code because of how fast or how suspiciously it arrived, not because the mailbox ran out of allowance, and the fix is a different one. A 421 4.7.28 deferral is the common shape.
The second is authentication. A message that fails SPF and DKIM alignment is rejected on arrival, which from the sender's side looks exactly like a ceiling: partial delivery, no obvious cause, worse on some domains than others.
The third is a sender that is not Gmail. A CRM, an invoicing platform or a mail-merge add-on sending as your domain has its own ceiling and its own reputation, and when it fails, Gmail's quota was never involved.
Check the cheap thing first. If SPF, DKIM and DMARC are not clean for the sending domain, fix that before redesigning how the business sends mail. A quota only explains a stop you can point at a number for.
The right channel for the volume
Once you know the real ceiling, the decision is not technical. It is which of the company's kinds of outbound mail belongs in a person's mailbox and which does not. Most small companies have three or four jobs running through one account: personal mail, client notices, invoices from an app, and something that is effectively a newsletter.
| Channel | What it is for | Documented ceiling | What it asks of you |
|---|---|---|---|
| A user mailbox | Person to person mail, small internal notes | 2,000 messages and 10,000 recipients a day, 500 external per message | Nothing, until one person becomes the whole company's outbound |
| Gmail mail merge | A personalised send to a list you already own | 1,500 recipients a day | No real reporting, and unsubscribes are yours to honour by hand |
| Google Group | Internal distribution, announcements, a shared address | Counted per group, far higher: 50,000 external recipients a day, 5,000 per 10 minutes | A policy for who may post and where replies go |
| Workspace SMTP relay | Application, device and script mail from your domain | 10,000 recipients a day per user, 100 per SMTP transaction | Admin setup, and a lockdown so it is not an open door on your domain |
| A sending platform | Marketing and high-volume transactional mail | Set by the vendor | A separate sending identity to authenticate and align |
What the relay and a group really give you
The Workspace SMTP relay is the right answer for application mail and the wrong answer for a newsletter. It accepts mail at smtp-relay.gmail.com on ports 25, 465 and 587, and Google's own page puts it at 10,000 recipients a day for each user in the organisation, with 100 recipients to a single SMTP transaction. That is five times the mailbox ceiling, which is usually enough for invoices, alerts, a scanner and a web form put together. What it does not do is improve how your mail is received, and configured loosely it will happily relay for senders you never intended. The settings that decide that are the ones we go through in SMTP relay and Send mail as.
A Google Group is for distribution. Google's group limits are counted per group and per account rather than against one person's daily allowance, and for a small company the binding figure is the external one: 50,000 external recipients a day for a single group, with 5,000 in any 10 minutes. Google notes that a subgroup counts as a recipient in addition to its own members, so a group of groups spends more than it looks like, and that a restriction usually lasts about an hour but can last 24.
One caution that costs people real money. Google's documentation sets separate limits for groups; it does not say that mailing a 400-member group costs one recipient against your user allowance. Plenty of blog posts say exactly that. Design around a group for distribution and shared addresses, and do not treat it as a way to launder volume past a quota.
None of this changes the real constraint anyway. Google's sender guidelines put the spam complaint rate that matters at well under 0.3%, and the ceiling that ends badly is never the published one. Volume you are allowed to send is not the same as volume anyone wants to receive.
The order we work in on a client account
- Pull the log before changing anything. Email Log Search for that sender over that window tells us what left, what was refused and why. Without it, every step after this is a guess.
- Separate the quota from the rejection. A quota stops the message before it leaves the account. A rejection comes back from the receiving side with a code, and that code names a different problem.
- Count the real recipient load per sender, per week, not per message. This is the number that explains most ceilings, and almost nobody knows theirs.
- Authenticate the domain first. SPF inside the ten-lookup budget, DKIM signing on every sender, DMARC with alignment that holds. Moving volume to a new channel before this is how a quota problem becomes a reputation problem.
- Split the jobs across channels as the table above sets them out, and give application mail its own identity, usually a sending subdomain, so its behaviour never drags the mailboxes down with it.
- Alarm the right number. A weekly recipient count per sender, reviewed once a month, catches the next ceiling weeks before it arrives. A daily message count does not.
How Guanacos Tech helps
Most of this work is a decision, not a configuration: which kind of mail belongs in a mailbox, which belongs on a relay, and which was never a job for Workspace. We read the logs, find the ceiling the business is actually near, split the channels, verify the records so the move does not cost you delivery, and leave the admin with the one number to watch. If a single mailbox is carrying your invoices, your renewals and something that has quietly become a newsletter, that is worth an hour with Google Workspace consultants before it turns into a morning of mail that never went out. A 30-minute call is enough to tell you which ceiling you are near and what moving the volume would involve.
Sources
- Gmail sending limits in Google Workspace (Google Workspace Admin Help)
- Send email from a printer, scanner, or app: SMTP relay limits (Google Workspace Admin Help)
- SMTP relay service error messages (Google Workspace Admin Help)
- Understand Groups policies and limits (Google Workspace Admin Help)
- Email sender guidelines (Gmail Help)