4.5.3

Enhanced Status Code 4.5.3: Too Many Recipients - Temporary

Temporary failure Medium severity Protocol RFC 3463
What it means

Enhanced Status Code 4.5.3 means “Too Many Recipients - Temporary.” The transaction named more recipients than the server will accept at once, or exceeded a size limit for a single transaction. Splitting the send into smaller batches resolves it.

At a glance
Code4.5.3
Bounce typeSoft (temporary)
SeverityMedium
CategoryProtocol
What to doQueued and retried automatically
StandardRFC 3463
What it looks like in your mail logs
452 4.5.3 Your message has too many recipients

What does 4.5.3 mean?

Enhanced status code 4.5.3 is the temporary form of too many recipients. RFC 3463 registers X.5.3 for more recipients being specified than the protocol could deliver. Google returns 452 4.5.3 both for a message with too many recipients and for a transaction exceeding a domain policy size limit, and Microsoft returns 4.5.3 as too many recipients.

The limit applies per transaction, not per message and not per day. Most servers accept somewhere between one hundred and a few thousand RCPT TO commands in a single conversation, and a well-behaved MTA responds to this code by splitting the recipient list and opening additional transactions. Senders that hit it persistently are usually doing their own SMTP and delivering a large list in one go.

Because it is temporary, the correct handling is to retry with fewer recipients rather than to treat it as a failure. The other reason it appears is a very large message combined with a moderate recipient count, where the total transaction size rather than the recipient count trips the limit. If reducing recipients does not help, look at message size.

How 4.5.3 plays out

Your server attempts delivery
The recipient defers with a temporary 4.5.3 reply
Your server queues the message and retries on a back-off schedule
It delivers on a later attempt, or becomes a hard bounce if it keeps failing

Where 4.5.3 sits: soft vs hard bounce

Soft bounce (4xx) Hard bounce (5xx)
NatureTemporaryPermanent
SMTP class4xx5xx
What to doLet it retrySuppress the address
Recoverable?OftenNo
4.5.3 is✓ this code

Common causes of 4.5.3

  • More RCPT TO commands were issued in one transaction than the server accepts
  • A large recipient list was delivered in a single conversation rather than in batches
  • The total transaction size exceeded a domain policy limit
  • A large message combined with many recipients exceeded a combined limit
  • A mailing list expanded to more addresses than the downstream server permits
  • The sending code does not split recipients by destination domain

How to fix 4.5.3

  • Split the recipient list into smaller batches and open a transaction per batch
  • Group recipients by destination domain, which reduces per-transaction counts naturally
  • If reducing recipients does not help, check message size against the transaction limit
  • Let your MTA handle recipient splitting rather than doing it in application code
  • Retry rather than failing, since the leading 4 makes this recoverable
  • Check 5.5.3 for the permanent form, which some servers use instead

Frequently asked questions

What does 452 4.5.3 mean?
It means you named more recipients in a single SMTP transaction than the server will accept, or the transaction exceeded a size limit. It is temporary, so the correct response is to split the recipients into smaller batches and retry rather than treating the messages as failed.
How many recipients can I put in one transaction?
It varies by server, typically between one hundred and a few thousand RCPT TO commands. There is no universal number, which is why the correct approach is to respond to the code by splitting rather than to hard-code a batch size. A good MTA does this automatically.
I reduced the recipients and still get 4.5.3. Why?
Because the limit may be on total transaction size rather than recipient count. Google returns this code for a domain policy size limit as well as for recipient count. A very large message with even a modest recipient list can exceed it, so check message size next.
How is 4.5.3 different from 5.5.3?
Only in finality. 4.5.3 defers and invites you to retry with fewer recipients; 5.5.3 refuses permanently. Servers vary in which they use for the same condition, so treat a 5.5.3 for too many recipients as the same diagnosis with a less forgiving response.
Should my application split recipients itself?
Preferably not. Handing the full list to a real MTA and letting it handle batching, per-domain grouping and retries is more robust than reimplementing that logic. Applications that do their own SMTP and their own splitting are where this code shows up most often.
Reviewed by Jennifer Jackson, Email Deliverability Analyst · June 2026 ← All bounce codes