452 4.5.3 too many recipients: limits by provider and how to fix it
452 4.5.3 means the server took some recipients and refused the rest because one message or session named too many. Split the send into smaller batches.
On this page(8 sections)
"452 4.5.3 Too many recipients" is a temporary refusal: the server took the recipients it had room for and turned away the rest, because one message or one SMTP session named more addresses than it allows. The fix is almost never a wait. It is a smaller batch.
This post reads that one error: what the two codes say, which limit you hit (per message, per day, or per connection), what the common providers publish, and how to split a send so nothing is lost or duplicated.
What does 452 4.5.3 mean?
It is two codes in one line. 452 is the SMTP reply code for a temporary "requested action not taken" refusal; any 4xx means try again later. 4.5.3 is the enhanced status code from RFC 3463: class 4 is a transient failure, subject 5 is "mail delivery protocol status", detail 3 is "too many recipients". The decoder for the whole family is in SMTP enhanced status codes, decoded.
The part that surprises people is the timing. The refusal happens at RCPT TO, one recipient at a time, so the first addresses in your list were accepted and the later ones were not. RFC 5321, section 4.5.3.1.8 says a server should accept at least 100 recipients per message, and that a client getting a 452 must hold the refused recipients and send them in a later transaction. Many clients do this on their own. Some do not, and that is where mail goes missing.
Which limit did you hit?
Three different limits produce the same text, so work out which one before changing anything.
| Limit | What it counts | Typical symptom | Fix |
|---|---|---|---|
| Per message | Addresses in To, Cc and Bcc of one message | Fails at the same recipient number every time | Send smaller messages |
| Per session | RCPT TO commands in one connection |
A big batch fails partway through | Open a new connection per batch |
| Per day or per quota | Recipients over a rolling 24 hours, or a plan quota | Worked this morning, fails now, even with one recipient | Wait, or raise the allowance |
If the failure happens with a single recipient, it is the third kind and splitting will not help. If it always fails at the same count, it is the first. That count is a number you can read straight from the log.
What limits do the big providers publish?
Providers publish different limits for different ways of sending, so state which route you use. These are the figures in each provider's own documentation at the time of writing; check the page before you rely on a number, because they change.
| Provider and route | Per message | Per day | Source |
|---|---|---|---|
| Google Workspace, SMTP or POP/IMAP client | 100 recipients | 10,000 total recipients, 3,000 external | Google Workspace sending limits |
| Google Workspace, Gmail web | 2,000 total, 500 external | same daily limits | same page |
| Google Workspace, Gmail API | 500 recipients | same daily limits | same page |
| Exchange Online, each mailbox | 500 by default, adjustable from 1 to 1,000 by an admin | 10,000 recipients in a 24-hour window | Exchange Online limits |
Two details matter in practice. Google's page counts a recipient every time a message is sent, so ten messages to the same 1,000 people is 10,000. Microsoft adds a message rate limit of 30 messages per minute per mailbox, and says that when volume passes it, the extra submissions are throttled and carried into the following minutes, so splitting a big send into hundreds of tiny messages can trade one limit for another.
Microsoft also adds a tenant-wide cap on external recipients per day, which it ties to the number of licenses in the tenant and sets at 5,000 for trial tenants. If a whole company's mail slows down at once, look there before blaming one sender.
Why does it fail even though I only have a few recipients?
Because a distribution list can count for more than you think. Microsoft counts a distribution group stored in the organization's address book as one recipient, but counts the members of a group stored in a mailbox's Contacts folder individually. For the tenant external limit, group members are counted individually after the group is expanded.
The other usual cause is a client that puts every address in one message when it should send many. A newsletter loop that builds one message with 400 Bcc addresses will hit a 100 or 500 limit on the first try. See per-provider throttling for why you also cannot simply blast the smaller batches back to back.
How do you split a send safely?
Batch by the lowest limit on your path, not the highest, and make each batch safe to repeat.
- Pick a batch size under the strictest limit. If any hop caps at 100, use 50 to 100, not 500.
- Send one message per recipient where the content is personal. It avoids exposing addresses and removes the per-message limit from the picture.
- Track each recipient's state yourself: queued, accepted, deferred, failed. Do not infer it from "the batch errored".
- Retry only the refused recipients. Re-sending the whole batch duplicates mail to the ones already accepted.
- Pace the batches. Space them out instead of opening many connections at once.
A minimal sketch of the retry rule, in pseudocode:
for batch in chunks(recipients, 100):
accepted, refused = submit(batch) # per-RCPT results, not one yes/no
mark(accepted, "accepted")
if refused:
queue_for_retry(refused, delay=60s) # only the refused onesThe point is the line that reads per-recipient results. A library that raises one exception for the whole batch hides which addresses made it. In Python's smtplib, for example, sendmail returns a dictionary of refused recipients when only some are refused, and raises only when all are.
How does Koltrix handle it?
Koltrix documents two different 452 4.5.3 replies on its SMTP relay, and they are the first and third limits above. The relay accepts up to 1,000 recipients per message, and a message with more than 1,000 RCPT TO gets 452 4.5.3 Too many recipients, with the instruction to send the rest in another message. A different 452 4.5.3 carrying the words "sending limit" means your plan's send quota is used up. That one is temporary on purpose: your client keeps retrying while you upgrade or the quota resets. See Limits.
The HTTP API has the same ceiling in a different form. POST /api/v2/emails rejects a request with more than 1,000 addresses across to, cc and bcc with a 400 and the text "too many recipients: at most 1000 addresses across to, cc and bcc". Every recipient, including cc and bcc, counts against your send quota. If you retry an API call with an Idempotency-Key, the replay does not count again, which is why idempotency keys belong in any batching loop.
What should you check first?
- Does it fail at the same recipient number each time? Then it is a per-message limit, and that number is the limit.
- Does it fail with one recipient? Then it is a daily limit or a quota. Splitting will not help.
- Does your client retry the refused recipients, or drop them? Test with a deliberately oversized message to a test inbox.
- Are you sending to a distribution list? Check how the provider counts its members.
- Is a hop between you and the destination, such as a relay or smart host, imposing a lower limit than your own?
Bottom line
A 452 4.5.3 means "not all of these, not now". Find out whether it is a per-message, per-session or per-day limit, batch under the lowest limit on your path, and retry only the recipients that were refused. Provider numbers are published in their own docs and they change, so read the current page rather than a blog's table, including this one.
Start with Koltrix
Your domain, one inbox, and an API that sends.
A team inbox where AI sorts and drafts (nothing is sent without your click), plus the transactional API and SMTP relay your product sends with. 7 days free, no card.
