Skip to content

SMTP error 4.5.3 Too many recipients

What SMTP error 4.5.3 means

More recipients were named than the receiving system would accept in one transaction, reported as 451 4.5.3. It is transient by design: a well-behaved sender splits the list and delivers the remainder on a later attempt, which is exactly what the specification expects. In a business it turns up when somebody uses an ordinary mailbox to reach several hundred people at once, which is the job a bulk sending platform exists to do properly.

What SMTP error 4.5.3 Too many recipients actually means

The definition assumes segmentation. The sending system is supposed to break a large recipient list into batches and work through them, and the code exists for the cases where it cannot. Two separate limits produce it in practice: a cap on recipients in a single message, which on Exchange Online is 500 by default, and a cap on how many recipients an account may address over a period, which is applied per day. The first is easy to spot because the message fails immediately. The second creeps up on an organisation as its mailing habits grow, and it usually surfaces halfway through a send.

More recipients were specified for the message than could have been delivered by the protocol. This error should normally result in the segmentation of the message into two, the remainder of the recipients to be delivered on a subsequent delivery attempt. It is included in this list in the event that such segmentation is not possible.

RFC 3463

How 4.5.3 appears in a bounce

A server reporting this condition sends it alongside a three-digit reply code, and a bounce prints the two together. The registry lists 451 4.5.3 as the pairing for this status.

The leading 4 is the server's verdict rather than part of the code's identity: it marks this as a temporary failure, which means the sending server is still retrying.

What causes SMTP error 4.5.3 on a business phone system

How to fix SMTP error 4.5.3

  1. Count the fully expanded recipient listExpand every group and every nested group before assuming the limit is unreasonable. The number that matters is what the message resolves to, and it is frequently several times what the sender believes they addressed.
  2. Move genuine bulk mail off the mailbox platformA dedicated sending service gives you unsubscribe handling, bounce processing and delivery reporting, and keeps mass sending away from the reputation your day-to-day email depends on. It is also the only approach that scales past a few hundred recipients.
  3. Use a distribution list or a group for internal announcementsAddressing one group rather than pasting two hundred addresses is easier to maintain and stays within limits far more often. It also means leavers stop receiving company mail without anyone editing a spreadsheet.
  4. Check the recipient limit on your own connectorsWhere you run a server or an appliance, receive connectors have a configurable maximum recipients per message. Raising it on a specific connector used by one application is safer than raising it everywhere.
  5. Give a business process its own sending accountAn application that legitimately needs to reach many people should send through an account and route configured for it, with limits set deliberately, rather than through a member of staff's mailbox.

Fixing the underlying problem

This page explains the code. These guides walk through the fix in detail.

Questions about SMTP error 4.5.3

Will the recipients who were accepted still get the message?
Usually yes. Sending systems that segment a large list deliver the batches they can and retry the rest, so recipients receive it at different times rather than not at all. Check the queue if it matters who has and has not had it.
Outlook shows the message as sent, so why has nobody had it?
Because the message left the client and is sitting in the platform's queue being retried. Sent items records that the client handed it over, not that anybody received it, which is why the queue or a message trace is the place to look.
Can we just raise the limit?
A little, and not far. The caps exist to limit the damage a compromised account can do, and raising them across a tenant makes that worse for everyone. If the requirement is genuine and recurring, the right answer is a bulk sending platform rather than a bigger number.

Related SMTP status codes

Source. SMTP error 4.5.3 Too many recipients is defined in RFC 3463 and registered in the IANA SMTP Enhanced Status Codes registry. The causes and fixes above are drawn from our own experience supporting UK business email systems.

All Email delivery & SMTP codes

Sitemap