Enhanced Status Code 4.5.3: Too Many Recipients - Temporary
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.
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
4.5.3 replyWhere 4.5.3 sits: soft vs hard bounce
| Soft bounce (4xx) | Hard bounce (5xx) | |
|---|---|---|
| Nature | Temporary | Permanent |
| SMTP class | 4xx | 5xx |
| What to do | Let it retry | Suppress the address |
| Recoverable? | Often | No |
| 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