Daily SMTP Relay Limit Exceeded for This Customer: The Org Cap

Guides·September 21, 2026·By The SendHustle Team·12 min read

The word doing the work in "daily smtp relay limit exceeded for this customer" is customer. Google uses it to mean your entire Google Workspace organisation — every user, every app, every script relaying through smtp-relay.gmail.com — not the account whose credentials were on the connection that failed. The mailbox named in your bounce may have sent forty messages all day. It still got refused, because someone else in the same tenancy spent the organisation's allowance.

So the fix is not the one most people reach for. This is not the 2,000-messages-a-day Gmail quota, and raising or spreading out the one account's send will do nothing. The relay is metered separately, on numbers most admins have never seen: 4.6 million non-unique recipients per organisation per 24 hours, and 319,444 per rolling 10-minute window. This guide maps that error and its three look-alikes to the exact ceiling each one reports, shows you which ones defer and which ones drop the mail for good, and works out from Google's own published figures how few senders it takes to exhaust a number that size.

What daily SMTP relay limit exceeded for this customer actually means

Google's SMTP relay service counts on four separate meters, and each has its own refusal. Two are organisation-wide ("customer"), one is per user — with two counters of its own — and one applies to a single SMTP conversation. Confusing them is why so many threads about this error end with an admin auditing one mailbox and finding nothing wrong with it.

The counters that matter for the customer errors are non-unique recipients. A message addressed to 100 people adds 100 to the organisation's total, not one. A nightly job that mails the same 8,000-address list adds 8,000 every night regardless of how few distinct humans are involved. Message count is not what the customer ceiling measures — recipient-deliveries are.

The four relay refusals, side by side

Google documents these on separate pages, which is why nobody sees them together. Here they are with the SMTP codes its error-code reference pairs them with the strings on its relay error page:

Error text	SMTP code	Ceiling it reports	Mail gone, or just delayed?
Daily SMTP relay sending limit exceeded for this customer	550 5.7.1	4.6 million non-unique recipients, org-wide, per 24 hours	Permanent — the message is rejected
Peak SMTP relay limit exceeded for this customer	450 4.2.1	319,444 recipients, org-wide, per 10-minute window	Temporary — relay mail is deferred
Daily SMTP relay limit exceeded for user	550 5.4.5	10,000 messages, or 10,000 unique recipients, per user per 24 hours	Permanent — rejected
Your message has too many recipients	452 4.5.3	100 recipients per SMTP transaction	Retry in a fresh transaction
Daily user sending limit exceeded	550 5.4.5	Gmail's own per-user daily quota — not the relay at all	Permanent — rejected

A note on the wording before anything else: the first string is not stable. Google's error-code reference renders it "Daily SMTP relay sending limit exceeded for this customer", while its relay error page heads the same condition "Daily SMTP relay limit exceeded for customer". If you are grepping logs or writing an alert rule, match on "relay" plus "customer" rather than on the full sentence, or you will miss half of them.

Two further things in that table are worth slowing down for.

The first is that 550 5.4.5 is ambiguous on its own. Google's SMTP error reference gives that same code to both "Daily user sending limit exceeded" and "Daily SMTP relay limit exceeded for user". One is the Gmail quota, one is the relay quota, and Google counts them independently of each other. If your monitoring alerts on codes rather than on the text after them, it cannot tell you which quota you hit. Match on the string, not the number.

The second is that the two customer errors behave in opposite ways. The peak one is a 4xx: Google is deferring, your sending server should retry, and the message will most likely go. The daily one is a 5xx: that delivery attempt is finished, and whatever queue it came from has to re-inject it after the window moves, or the mail is simply lost. Anyone treating both as "we're being throttled" will quietly drop mail.

Where each ceiling actually sits

Google states these on its SMTP relay routing page. Written as rates rather than totals, they look like this:

319,444 recipients per 10 minutes, org-wide — about 532 recipient-deliveries every second, sustained.
4.6 million recipients per 24 hours, org-wide — about 53 per second, averaged across the whole day.
10,000 messages per user per 24 hours, and separately 10,000 unique recipients per user per 24 hours. Both are per user; whichever you touch first stops that user.
100 recipients per SMTP transaction on smtp-relay.gmail.com, regardless of everything above.

That last one surprises people who have read that a relayed message may carry up to 10,000 recipients. Both are true and they are not the same rule: the message-level allowance is about the message, and the 100 is about how many RCPT TO commands Google accepts in one transaction. Google's own remedy is to start another transaction — a new connection, or an RSET on the existing one.

Spreading the send out will not save you

Here is the arithmetic nobody publishes, and it changes what you should do next.

There are 144 ten-minute windows in a day. At the peak ceiling, 319,444 × 144 works out to roughly 46 million recipients — ten times the 4.6 million the daily ceiling allows. The two limits are an order of magnitude apart.

The consequence is blunt: if you hit the daily customer limit, you were already sending at about a tenth of the peak rate or less, so throttling further cannot fix it. Rate-limiting your sender, adding sleep between batches, staggering cron jobs — all of it is aimed at the peak ceiling, which you never came close to. The daily ceiling is a volume problem, and only sending less volume, or sending some of it somewhere else, resolves it.

The inverse is also useful. If you are getting 450 4.2.1 peak deferrals and not the daily one, you have a shape problem rather than a volume problem. Your day's traffic is compressed into a burst. Spreading that same volume across more of the day is exactly the right fix, and you have roughly ten times the daily allowance worth of peak headroom to spread it into.

How few senders it takes to reach 4.6 million

Four point six million sounds unreachable until you divide it by the per-user allowance.

Sending to distinct people: each user is capped at 10,000 unique recipients in 24 hours, so it takes about 460 users, every one of them relaying to a full, entirely distinct 10,000-address list on the same day, to reach the organisation total.
Re-sending to the same list: the customer counter is non-unique, so repeat sends stack. One user may relay 10,000 messages a day, each carrying up to 100 recipients — 1,000,000 recipient-deliveries, all landing on the same ≤10,000 distinct addresses. Five users doing that exceed 4.6 million between them.

That gap is where the error usually comes from. A tenant does not trip the customer ceiling because 460 people started mailing; it trips because a small number of automated senders are hammering the same recipient list, and the per-user meters never flag them, because their unique recipient count stays low. Transactional retries, a mis-scheduled digest firing hourly instead of daily, a staging environment pointed at the production relay and the production list — these are the usual culprits, and all three look harmless on a per-user report.

Finding the ceiling you hit from your own bounce log

You can identify the meter without console access, in this order:

Read the string, not the code. Find the words "for this customer" or "for user" in the refusal text. That single distinction tells you whether to look at the organisation or at one mailbox, and it is the step almost everyone skips.
Check the first digit. 4xx means deferred and retryable; 5xx means that attempt is over. This decides whether you need to re-inject the message yourself.
Count your own recipient-deliveries, not your messages. Sum recipients across every relayed message in the last 24 hours, counting duplicates. Comparing message counts to a recipient ceiling is the most common way people convince themselves the numbers cannot possibly be theirs.
Check whether the traffic is yours at all. A customer-level refusal can be caused by any account or app on the tenancy. If your own total is nowhere near, the answer is elsewhere in the organisation — an admin needs to look at relay traffic across all users.
Only then look at the per-user meters. If the text said "for user", compare that one account against both 10,000 messages and 10,000 unique recipients; either will stop it.

What an admin can change, and what nobody can

The SMTP relay setting in the Admin console governs who may relay and from which addresses and IP ranges. It is an authorisation control. It does not contain a field for the size of the quota, and Google publishes the relay ceilings as service limits: its error pages point readers to the published limits rather than to a request form. Treat 4.6 million, 319,444, 10,000 and 100 as fixed inputs to your design rather than as numbers to negotiate.

What is genuinely in your hands:

Reshape bursts when you are seeing peak deferrals — there is roughly ten times more room per day at the peak rate than the daily ceiling permits.
Honour the 4xx. A sending server that retries deferrals on a sane schedule turns peak refusals into delivered mail at no cost. One that treats 450 as fatal throws away mail Google was willing to accept.
Deduplicate before you relay. Since the customer meter counts non-unique recipients, collapsing repeated sends to the same address is the only lever that reduces the number the daily ceiling actually measures.
Split the traffic by type. Bulk campaign volume and per-transaction application mail compete for one organisation-wide counter when they share a relay. Moving one of them onto its own sending path removes the contention outright, and it is usually the only structural fix available once a tenant is regularly touching a customer-level ceiling.
Remember the meters are independent. Relay and Gmail user limits are counted separately, so a user sitting well under their Gmail quota tells you nothing about their relay position, and vice versa.

Where these numbers are published

Every figure above comes from Google's own documentation rather than from a third-party round-up, and the four pages are worth bookmarking separately because Google splits the relay story across all of them — the error strings on one page, the ceilings on another, the SMTP codes on a third, and the Gmail quotas it is so easily confused with on the fourth.

Frequently asked questions

Does the SMTP relay quota come out of my 2,000-a-day Gmail sending limit?

No. Google counts the SMTP relay service and Gmail user sending limits independently of each other, so relayed mail does not consume a user's Gmail quota and Gmail traffic does not consume relay allowance. This is why a user sitting comfortably under 2,000 messages can still be refused by the relay, and why checking their Gmail usage tells you nothing about the relay ceiling.

Is "daily SMTP relay limit exceeded for this customer" temporary or permanent?

It is permanent for that delivery attempt. Google pairs the daily customer refusal with a 550 5.7.1, which means the message is rejected rather than deferred, so your sending system has to re-inject it once the 24-hour window has moved rather than relying on normal retry. The peak customer error is the temporary one: it comes back as 450 4.2.1 and the mail is deferred.

Can a Google Workspace admin raise the customer relay limit?

The SMTP relay setting in the Admin console controls who is allowed to relay and from which addresses and IP ranges, not the size of the quota. Google publishes the relay ceilings as service limits and its error pages direct readers to those published numbers rather than to a request form, so 4.6 million recipients a day, 319,444 per ten minutes, 10,000 per user and 100 per transaction are best treated as fixed design constraints.

Why did my send fail at 100 recipients when the relay allows 10,000 recipients per message?

Those are two different rules. Google documents a 100-recipient limit per SMTP transaction on smtp-relay.gmail.com, which caps how many RCPT TO commands it will accept in a single conversation, independently of any message-level recipient allowance. The remedy Google gives is to start another transaction, either by opening a new connection or by issuing RSET on the existing one.

If I slow my sending down, will the daily customer limit stop firing?

Almost certainly not. The peak ceiling of 319,444 recipients per ten-minute window works out to roughly 46 million recipients a day, about ten times the 4.6 million the daily ceiling permits, so anything that trips the daily limit was already running at a tenth of the allowed rate or less. Throttling targets the peak ceiling you never reached; only reducing total volume, deduplicating repeat sends, or moving some traffic onto a different sending path affects the daily one.

All articles