452 4.5.3: Too many recipients in one message

At a glance

• Type: temporary failure (class 4, RFC 3463 §2). The sending server keeps the message and retries later (RFC 5321 §4.5.4.1); it bounces only if the problem lasts until the message expires.
• Basic code 452: “Requested action not taken: insufficient system storage” (RFC 5321 §4.2.3).
• Enhanced code 4.5.3: “Too many recipients” in the IANA registry (RFC 3463), in the group mail delivery protocol status (RFC 3463 §3.6).

Your message listed more recipients than the receiving server takes in one go. The server deferred the recipients over its limit; a well-behaved sending server delivers them in a later transaction.

What it means

RFC 3463 §3.6 defines X.5.3 as "too many recipients": more recipients were given than could be delivered. The RFC says this should normally lead the sender to split the message, sending the remaining recipients in a later attempt.

RFC 5321 sets the rules in detail:

• §4.5.3.1.8: a server must accept at least 100 recipients per message. Refusing fewer breaks the standard. A client sending to more than 100 should be ready to send in chunks of 100.
• §4.5.3.1.8: a server with a limit must reject the extra addresses, not silently drop ones it already accepted.
• §4.5.3.1.10: the correct reply when a server's recipient limit is reached is 452. Older software used 552; clients should treat that as temporary too. A server enforcing a site policy may use a 5yz code instead.

The recipient count here is the envelope list, one RCPT TO per address, which includes Bcc recipients.

Common causes

• A message sent to a large To, Cc or Bcc list in one transaction.
• A mailing tool that puts a whole batch of contacts into a single message instead of one message per recipient.
• Many recipients at one domain in the same message, against that domain's policy.

How providers use it

• Gmail returns 452 4.5.3 when a message has too many recipients, or exceeds a domain's policy limit per transaction, and suggests sending to the affected recipient separately (Google's SMTP error reference). Its permanent 550 5.5.3 means too many recipients for this sender.
• Microsoft 365 uses 4.5.3 when a message has more than 200 envelope recipients from the same domain (Exchange Online NDR reference).

How to fix it

1. Let your mail server retry. If it follows RFC 5321, the deferred recipients go out in a new transaction automatically.
2. If you control the sending code, send in smaller batches. 100 recipients per transaction is the size every compliant server must accept.
3. For newsletters and announcements, send one message per recipient rather than one message with a large Bcc list. Your recipients also get a message addressed to them.
4. If you also hit a daily limit, see 550 5.4.5; per-message and per-day limits are separate.

What to do with the address

Nothing. The addresses are fine; only the way they were grouped in one message was refused.

Related codes

• 552 5.3.4: The message is too big
• 550 5.4.5: The sender reached a daily sending limit (Google)
• 503 5.5.1: Commands sent in the wrong order

See every bounce code in the dictionary.

Many bounces from addresses that do not exist can be avoided: check an address with our free email checker, or clean a whole list before you send.

How we wrote this: drafted by the email-validation.org team with the help of AI writing tools, from our product documentation and the sources linked in the text.