TL;DR
4.5.3 is a temporary per-transaction recipient limit. Preserve accepted-versus-remaining recipient context, split only the remainder, retry in bounded batches, and keep list suppression tied to independent permanent results.
What this code means
X.5.3 applies when more recipients were specified than the protocol could deliver in one transaction. The standard normally calls for splitting the message and delivering remaining recipients on a subsequent attempt.
Provider examples
452 4.5.3 Too many recipients452 4.5.3 Domain policy size per transaction exceeded, please try this recipient in a separate transaction. For more information, go to Message bounced due to a policy rule. - gsmtp452 4.5.3 Your message has too many recipients. For more information regarding Google's sending limits, go to Limits for sending & getting email. - gsmtpTechnical meaning
The recipient count in this transaction exceeded what the protocol could handle. The result says neither which recipients were already accepted nor which product limit applied; that requires the transaction trace.
Delivery status
The leading 4 makes this temporary. It does not mean a recipient address is invalid, that all original recipients failed, or that resending the entire list unchanged is safe.
- Class
- Temporary failure
- Retry
- Controlled retry
- Suppression
- Check the full context
Retry decision
Identify unprocessed recipients from the trace, split only that remainder into smaller batches, and retry with idempotency, backoff, jitter, and a limit. Stop after success, permanent result, or exhaustion; do not indiscriminately resend already accepted recipients.
Suppression decision
Do not suppress based on 4.5.3 alone. Use per-recipient outcomes and independent permanent signals before applying list policy.
Common causes
- The message specified more recipients than the protocol could process in one attempt.
- Microsoft Exchange Server's MaxRecipientsPerMessage example is provider-specific practice, not the full definition.
Diagnostic steps
- Confirm exactly 4.5.3 with a 4xx reply and retain the complete response.
- Use the transaction trace to identify original, already accepted, and remaining recipients.
- For the exact Microsoft response "452 4.5.3 Too many recipients", confirm the inbound Exchange Server context and applicable Receive connector limit.
- Split the remaining recipients, retry in bounded batches, and stop at success, permanent result, or the configured limit.
Actions by owner
Sender administrator
- Record per-recipient transaction outcomes and send only remaining recipients in smaller batches.
- Use idempotency and bounded retries to avoid duplicate delivery to already accepted recipients.
Provider
- Preserve recipient-stage context and exact limits where available.
- Apply or adjust managed limits according to policy without turning the temporary limit into recipient suppression.
Sources
These sources define what this enhanced status code means, mainly through the IANA registry and related RFCs. When provider examples appear on the page, they come from that provider's published documentation. Follow the links to read the original wording in context.
- SMTP Enhanced Status Codes — IANA registry of enhanced mail system status codes.
- RFC 5248 — A Registry for SMTP Enhanced Mail System Status Codes — Creates and governs the IANA enhanced status code registry.
- RFC 2034 — SMTP Service Extension for Returning Enhanced Error Codes — Defines how SMTP returns enhanced status codes to clients.
- RFC 3463 — Enhanced Mail System Status Codes — Defines the class/subject/detail model for enhanced status codes.
- Message size and recipient limits in Exchange Server — Microsoft Learn reference for Exchange message and recipient limits.
- Gmail SMTP errors and codes — Official Gmail Help table of SMTP error messages and status codes.
Last verified:
