5.4.5 Daily User Sending Limit Exceeded: Which Quota You Hit
A bounce that says 5.4.5 daily user sending limit exceeded is Google telling you that one specific counter attached to one specific mailbox has run out. It is not a reputation problem, not a spam filter, and not a block on the domain. The mailbox can still receive mail perfectly well; it simply cannot originate any more of it until the counter refills.
The part almost every write-up skips is that Google issues two different bounces under the code 5.4.5, and they point at two counters that are tracked entirely separately. Fix the wrong one and you will hit the same wall tomorrow. So before changing anything, read the words after the number.
Two bounces wearing the same code
Google's SMTP error reference lists these as distinct entries:
| Code | The text that follows it | What ran out |
|---|---|---|
| 5.4.5 | Daily user sending limit exceeded |
The Gmail sending quota for that one user |
| 5.4.5 | Daily SMTP relay limit exceeded for user |
That user's SMTP relay quota |
| 5.7.1 | Daily SMTP relay sending limit exceeded for this customer |
The relay quota for the whole organisation |
That third row matters more than it looks. A customer-wide relay cap does not come back as 5.4.5 at all — it arrives as 5.7.1, a code most people associate with authentication or policy rejection. If one script in your company drains the org's relay allowance, everyone else's bounce will name a code that sends them off investigating SPF.
And the two relay rows are not drawn from the same pool as the first. Google's relay documentation is explicit: "There are different per-user sending limits for sending email with Gmail, rather than SMTP relay. The SMTP relay and Gmail user sending limits are independent and counted separately from each other." A user who has exhausted their Gmail quota may still have a full relay allowance sitting unused, and vice versa.
The counters that can produce this error
There is no single "Gmail limit". There is a stack of them, and any one going to zero produces the same bounce. These are the figures in Google's Gmail sending limits documentation for Workspace accounts:
| Counter | Paid account | Trial account |
|---|---|---|
| Messages per day | 2,000 | 500 |
| Messages per day via mail merge | 1,500 | — |
| Total recipients per day | 10,000 (1,500 for mail merge) | — |
| External recipients per day | 3,000 | — |
| Unique recipients per day | 3,000 total / 2,000 external | 500 external |
| Recipients per message | 2,000 total, max 500 external | — |
| Recipients per message, SMTP/POP/IMAP client | 100 | — |
| Recipients per message, Gmail API | 500 | — |
Two things fall out of this table immediately.
The first is that messages and recipients are counted separately. Send 400 messages to 25 recipients each and you are nowhere near the 2,000-message ceiling, but you have spent 10,000 recipients and you are done for the day. People who hit the wall at a few hundred sends are almost always hitting a recipient counter, not a message counter.
The second is that the path you send through changes the per-message limit by a factor of twenty. The same account that can address 2,000 recipients from the Gmail web interface is capped at 100 per message through an SMTP client, and 500 through the API. A merge tool that batches recipients into a single message will trip this long before the daily numbers matter.
Free @gmail.com accounts run on a simpler and much lower set: Google's consumer limits page gives 500 emails per day and 500 recipients in a single email.
Why a block that clears itself arrives as a permanent 550
This is the part that causes real damage, and no one mentions it.
Enhanced status codes are defined in RFC 3463. Under that standard, the subject/detail pair .4.5 means mail system congestion, and the RFC adds a specific instruction about its class: "This is useful only as a persistent transient error." Persistent transient is the 4.x.x class — "the message as sent is valid, but persistence of some temporary condition has caused abandonment or delay", and "sending in the future may be successful".
Google returns it as 550, which is the 5.x.x class: "A permanent failure is one which is not likely to be resolved by resending the message in the current form. Some change to the message or the destination must be made for successful delivery."
The condition is temporary. The code says permanent. That mismatch has consequences that outlive the block itself:
- A standards-compliant MTA will not retry a 5xx. It generates a non-delivery report and drops the message. Nothing in your outbound queue survives to be sent when the quota refills.
- Sending tools that classify bounces by class can file these under hard bounces, which is the same bucket as an address that does not exist.
- Your logs will show a permanent delivery failure for a mailbox that was working an hour earlier and will be working again in a few hours.
If you take one operational rule from this article: after a 5.4.5, treat the affected recipients as unsent, not as bounced. Re-queue them yourself, because your mail server will not.
Midnight is not the reset
The universal advice on this error is "wait until tomorrow". That advice is wrong, and Google's own documentation says so: "Limits per day are applied over a rolling 24-hour period, not a set time of day." The suspension lasts up to 24 hours, and after it "sending limits are reset and users can resume sending mail". Consumer Gmail is worded the same way — you "should be able to send emails again within 1 to 24 hours".
A rolling window means capacity returns in the same shape you spent it. Work an example:
- Tuesday 09:00 — a merge fires 1,800 messages in twenty minutes.
- Tuesday 09:25 — message 2,001 bounces with 5.4.5.
- Wednesday 00:00 — nothing happens. The clock is not a calendar day.
- Wednesday 09:00 — the Tuesday-morning burst ages out of the window and roughly 1,800 messages of headroom return at once.
Whereas a sender who spread 2,000 messages evenly across Tuesday regains capacity evenly across Wednesday, a few dozen at a time. This is why "I waited overnight and it still bounced" and "it started working again at a random time in the morning" are both normal. Neither is a bug, and neither is a signal about your reputation.
Tracing your own 5.4.5 daily user sending limit exceeded bounce
Work through these in order. The answer is usually found in the first two steps.
- Read the words after the code.
Daily user sending limit exceededis the Gmail mailbox quota.Daily SMTP relay limit exceeded for useris the relay quota. They have different fixes and different numbers. - Identify the path the message took. Gmail web interface, an SMTP client on
smtp.gmail.com,smtp-relay.gmail.com, or the Gmail API. Relay traffic is metered separately and allows 10,000 messages per user per 24 hours, with a 100-recipient limit per SMTP transaction. - Count recipients, not messages. Multiply your message count by the average recipients per message. If that product is near 10,000 — or near 3,000 for recipients outside your domain — you found your counter.
- Check the account type. A trial account is capped at 500 messages a day, a quarter of the paid figure.
- Check whether the failure is per-message rather than per-day. A bounce on the very first send of the day is never a daily quota. It is the per-message recipient cap for the path you used: 100 on an SMTP client, 500 on the API.
Trial accounts sit under a lower ceiling than you were sold
This one generates more confusion than every other counter combined, because the fix people reach for does not work.
Trial Workspace accounts are held to 500 messages a day and 500 unique external recipients. The obvious response is to start paying. But Google's limits documentation states that the higher limits apply once "your domain has cumulatively paid at least $100 USD", and that the increase "can take up to 75 days after meeting this payment threshold".
Read that carefully. It is cumulative spend, not subscription status. A small team on a modest plan can be paying Google for months before it crosses $100, and then wait up to another 75 days for the ceiling to move. Upgrading on Monday does not lift the cap on Tuesday. If you are planning a launch around a new Workspace domain, that gap is the thing to plan around.
Moving the send off the quota that keeps stopping it
Once you know which counter you tripped, there are only three honest responses.
- Spread the send. Because the window rolls, pacing a campaign across the day converts a hard stop into a slower send. This is the only fix that costs nothing.
- Change the path. SMTP relay is metered independently of the Gmail user quota, so moving application and campaign traffic onto the relay leaves the mailbox quota for the human using it. Note the 100-recipient-per-transaction limit when you do.
- Stop sending campaigns from a mailbox. A Gmail quota exists to stop one person's mailbox flooding the internet. It is not a sending platform, and no amount of tuning turns it into one. Campaign and transactional volume belongs on infrastructure that sends from your own domain with its own throughput — which is what SendHustle does — rather than borrowing a personal mailbox's allowance.
The diagnostic habit is worth more than any of the three. A bounce code is not a verdict on your sending; it is a pointer to one exhausted counter. Read the string, name the counter, and the fix picks itself.
Frequently asked questions
How long does a 5.4.5 sending block last?
Google applies the limit over a rolling 24-hour period rather than resetting at a set time of day, and its documentation says the suspension lasts up to 24 hours before limits reset. In practice capacity comes back in the same shape you spent it, so a burst sent at nine in the morning frees up around nine the following morning rather than at midnight.
Does a 5.4.5 bounce mean my domain has been flagged for spam?
No. It is a quota counter reaching zero on one mailbox, not a reputation or policy judgement, and the mailbox continues to receive mail normally throughout. Reputation problems come back under different codes, most of which mention sender guidelines or unsolicited mail rather than a daily limit.
What is the difference between the two 5.4.5 errors Google sends?
One reads 'Daily user sending limit exceeded' and refers to the Gmail sending quota for that user; the other reads 'Daily SMTP relay limit exceeded for user' and refers to that user's SMTP relay quota. Google counts the two pools independently, so exhausting one leaves the other untouched, and a third, organisation-wide relay cap returns 5.7.1 instead.
Should I resend the messages that bounced with 5.4.5?
Yes, but you will usually have to do it yourself. Because Google returns the error as a permanent 550, a standards-compliant mail server will not retry it and will drop the message instead, so treat those recipients as unsent rather than as hard bounces and re-queue them once the window has rolled.
Why am I still capped at 500 emails a day after upgrading from a trial?
Google's limits documentation says the higher limits apply once the domain has cumulatively paid at least $100 USD, and that the increase can take up to 75 days after that threshold is met. Upgrading the plan on its own does not lift the cap, which is why the restriction often outlasts the trial by months on a small subscription.