Your Message Has Too Many Recipients Gmail Error Explained

If you've typed "your message has too many recipients gmail" into a search bar at 2 a.m. while a mail-merge script sits dead at row 101, here's the short version: you didn't hit a daily quota. You hit a per-message ceiling that Gmail's outbound servers enforce on a single SMTP transaction, and it clears the instant you open a new one.

Most pages that rank for this error fold it into a generic "Gmail sending limits" roundup and tell you to wait 24 hours before trying again. That's the wrong fix, and it costs you a day you didn't need to lose. The 100-recipient cap on one transaction has nothing to do with the daily quota tracked against your account. They're different counters, checked at different points, and one of them resets in milliseconds.

Your Message Has Too Many Recipients Gmail Error: Where It Comes From

Every email you send goes out as one SMTP transaction. Your mail client or script opens a connection, says MAIL FROM, lists every recipient with a separate RCPT TO command, then sends DATA once. Gmail's outbound mail servers — smtp.gmail.com for regular accounts, smtp-relay.gmail.com for Google Workspace's relay service — read every RCPT TO in that transaction before deciding whether to accept the message.

RFC 5321, the SMTP protocol specification, only requires a server to accept a minimum of 100 recipients in a single transaction. Past that floor, a server is free to reject additional recipients with a 452 "too many recipients" response — a response the spec explicitly frames as temporary, something the client can recover from within the same session. Gmail implements close to that floor. Push a single message past 100 combined To, Cc, and Bcc addresses in one transaction, and it stops accepting recipients and comes back with some version of "Error: your message has too many recipients, please try to resend with fewer recipients."

That's a protocol-level limit on the shape of one transaction. It's not a statement about how much mail you're allowed to send that day.

Transaction, Connection, and Day: Three Different Counters

Three things get conflated in most write-ups of this error, and they reset on completely different schedules.

A transaction is one MAIL FROM → RCPT TO (×N) → DATA cycle. Its recipient count goes back to zero the moment the transaction ends — whether it ends because the message was accepted, because you issued RSET, or because the connection dropped.

A connection is one TCP/TLS session to Gmail's mail server, authenticated once. A single connection can carry many transactions back to back without you having to log in again each time.

A day is the rolling 24-hour quota Google tracks against your authenticated sending account — total recipients or messages sent, independent of how many transactions or connections you used to send them.

You can open one connection, run 50 transactions of 90 recipients each — 4,500 recipients — and never come close to the per-transaction cap. You'll still eventually hit whatever daily figure applies to your account type, and that's a separate wall entirely.

Why RSET Clears It Instantly and Waiting 24 Hours Does Not

RSET is an SMTP command that resets the current transaction — it drops the recipient list and the MAIL FROM you'd already declared — without closing the connection. Send it, and the recipient counter for that transaction goes back to zero right away. Opening a fresh connection does the same thing, just with more overhead.

Almost every SMTP library does one of these for you automatically. In Python's smtplib, calling server.sendmail() a second time starts a brand-new transaction on the same connection object. In Nodemailer, calling transporter.sendMail() again does the same. If your script died because it tried to cram 300 addresses into one sendmail() call, the fix isn't a new script — it's calling that function once per chunk of recipients.

Waiting 24 hours doesn't help because the per-transaction counter was never running on a clock. It's reset by a protocol event, not by time passing. If your first attempt got refused, the correct response is to send again with fewer recipients in that transaction, immediately, not to sit on it overnight.

Batching a Bulk Send Under the 100-Recipient Ceiling

If you're sending one message with a long list of recipients — an internal announcement, a shared invoice reminder, whatever — split the list into chunks before you build the transaction. I keep chunk size at 90, not 100, to leave room for a Cc or Bcc you forget you added.

for chunk in chunks_of(recipient_list, 90):
    server.sendmail(from_addr, chunk, message)

Each call to sendmail() opens its own transaction on the same connection, so you're not paying for a new TLS handshake and login every time — just a new MAIL FROM/RCPT TO cycle.

If what you're actually doing is a mail merge — a personalized message per person, not one message to a shared list — you should already be sending one message per recipient. Each of those is its own transaction with exactly one RCPT TO, so the 100-recipient ceiling never enters the picture. What you'll manage instead is total volume against your account's daily limit, which is a different problem with a different fix — pacing the send over more of the day, or moving to a plan with a higher daily allowance.

This is the approach SendHustle uses for bulk campaigns and automated sequences sent from a customer's own verified domain: one message per recipient, queued and paced automatically, so this particular error doesn't show up regardless of list size. The free tier caps out at 300 emails a month either way, but the sending mechanism underneath is the same one the paid plans use at higher volume.

The Daily Counters This Error Is Not

It's worth being precise about what this error is not, because the fixes for daily limits are completely different and won't touch this one.

A daily sending-limit refusal shows up as a distinct bounce, usually with its own enhanced status code, and it's tracked over a rolling 24-hour window against your account or your whole Workspace organization. Splitting your list into 90-recipient transactions doesn't get you past it, because the daily counter adds up recipients or messages across every transaction and every connection you use that day. The only things that move that number are time — the window rolling forward — or a plan with a higher allowance.

The too-many-recipients refusal, by contrast, cares about exactly one thing: how many RCPT TO commands showed up in the current transaction. It doesn't know or care what you sent yesterday, or an hour ago, or thirty seconds ago in a different transaction. Treating it like a daily quota — and waiting accordingly — just means your list sits unsent for a day it never needed to.

Frequently asked questions

Is there a limit to how many recipients I can put in one Gmail message? Yes — Gmail's outbound servers stop accepting additional RCPT TO commands once a single transaction passes roughly 100 combined To, Cc, and Bcc addresses. That's separate from the total number of recipients you can reach across multiple messages in a day.

How many recipients does Gmail allow per day? Google publishes separate daily limits by account type — consumer Gmail accounts and Google Workspace accounts have different figures, and Workspace's SMTP relay service has its own allowance on top of that. Check Google's current sending-limits documentation for your specific account type, since these numbers are set by Google and can change.

Does issuing RSET actually clear the recipient count, or do I need to open a new connection? Either works. RSET clears the current transaction's recipient list without closing the connection, and starting a new connection obviously starts fresh too. Most SMTP libraries issue one or the other automatically every time you call the send function again, so you often don't have to do anything explicit.

Will splitting addresses across To, Cc, and Bcc get around the 100-recipient limit? No. Gmail counts To, Cc, and Bcc together for the purposes of this limit — it's the total number of RCPT TO commands in the transaction that matters, not which header field the address sits in.

What's the difference between this error and a "daily user sending limit exceeded" bounce? This error is about the size of one transaction and clears the moment you start a new transaction with fewer recipients. A daily-limit bounce is tracked over a rolling 24-hour window against your account and only clears as that window rolls forward or your plan's allowance increases — no amount of resending will get past it early.

Frequently asked questions

Is there a limit to how many recipients I can put in one Gmail message?

Yes — Gmail's outbound servers stop accepting additional RCPT TO commands once a single transaction passes roughly 100 combined To, Cc, and Bcc addresses. That's separate from the total number of recipients you can reach across multiple messages in a day.

How many recipients does Gmail allow per day?

Google publishes separate daily limits by account type — consumer Gmail accounts and Google Workspace accounts have different figures, and Workspace's SMTP relay service has its own allowance on top of that. Check Google's current sending-limits documentation for your specific account type since these numbers are set by Google and can change.

Does issuing RSET actually clear the recipient count, or do I need to open a new connection?

Either works. RSET clears the current transaction's recipient list without closing the connection, and starting a new connection obviously starts fresh too. Most SMTP libraries issue one or the other automatically every time you call the send function again.

Will splitting addresses across To, Cc, and Bcc get around the 100-recipient limit?

No. Gmail counts To, Cc, and Bcc together for this limit — it's the total number of RCPT TO commands in the transaction that matters, not which header field the address sits in.

What's the difference between this error and a daily user sending limit exceeded bounce?

This error is about the size of one transaction and clears the moment you start a new transaction with fewer recipients. A daily-limit bounce is tracked over a rolling 24-hour window against your account and only clears as that window rolls forward or your plan's allowance increases.