SMTP error 550 5.5.3: too many recipients

550 5.5.3 is a 5yz permanent failure paired with 5.5.3, defined in RFC 3463 under the

"mail system" category to mean too many recipients. This fires when a single SMTP transaction

accumulates more RCPT TO commands than the receiving server will accept before it will process

the DATA stage — it is a per-connection, per-message limit, separate from any daily or hourly

sending quota.

A real transcript

MAIL FROM:<you@yourdomain.com>
250 2.1.0 Sender OK
RCPT TO:<r1@example.com>
250 2.1.5 Recipient OK
RCPT TO:<r2@example.com>
250 2.1.5 Recipient OK
...
RCPT TO:<r101@example.com>
550 5.5.3 Too many recipients

Receiving servers commonly cap this somewhere between 50 and 500 recipients per message, depending

on the provider and whether the sending IP has an established reputation.

How the big three set this limit

Because none of these figures are contractually guaranteed to stay fixed, the safest engineering

approach is to batch well under the lowest number you have actually observed, not the highest one

you have read about.

Diagnose it yourself

1. Count the actual `RCPT TO` lines your sending code issues per `MAIL FROM` — log the

recipient count per transaction and compare it against the point where failures start.

1. Check whether the failure happens at a consistent recipient count across multiple sends to

the same provider — a consistent cutoff confirms a hard per-message cap rather than a load-based

or reputation-based variable limit.

1. Test with a deliberately small batch (five or ten recipients) to confirm the rest of your

sending pipeline is otherwise healthy before troubleshooting the limit itself.

Common causes

1. Exceeding the maximum recipient limit a specific receiving server allows per message — this

varies by provider and is rarely documented precisely.

1. Bulk email sending without proper configuration — using a single MAIL FROM/RCPT TO block

for a whole list instead of sending through infrastructure built to batch it.

1. Suspicious sending patterns — a message with an unusually large recipient count, even under

the hard limit, can itself be read as a spam signal and trigger stricter enforcement.

How to fix it, in order

1. Reduce the number of recipients per email. Split large recipient lists into smaller

batches, each sent as its own SMTP transaction.

1. Enable SMTP authentication if you are not already using it — some servers apply looser

recipient limits to authenticated senders with established standing than to anonymous

connections.

1. Optimise email-sending frequency — spread batches over time rather than firing them all in

immediate succession, which looks more like normal mail traffic.

1. Check and adjust sending limits in your own outbound mail software or ESP configuration to

match what the destination actually accepts, rather than relying on defaults.

1. Use multiple mailboxes for bulk sending, each warmed up and sending a portion of the volume,

rather than one address carrying the full recipient count.

1. Ensure compliance with anti-spam regulations (CAN-SPAM, GDPR consent requirements, and

similar) — a high single-message recipient count is one of the patterns regulators and

providers both scrutinise together.

Best practices for bulk email sending

Send to individually addressed messages with one recipient in To: (using BCC or per-recipient

sends, not one message with hundreds of visible recipients), batch through infrastructure designed

for volume rather than a single SMTP session, and keep each batch's size comfortably under any

limit you have observed from a given provider rather than sending right up against it.

What not to do

• Do not resend the identical oversized message — it will fail identically at the same recipient

count every time, and repeated identical failures at the same threshold are themselves a pattern

some providers flag as abusive probing.

• Do not simply trim the list down to "just under" the limit you hit once; different receiving

servers enforce different limits, and a message near one provider's ceiling may exceed another's

on the very next send.

• Do not put every recipient in To: or Cc: for a bulk send regardless of the limit question —

this also exposes every recipient's address to every other recipient, which is a privacy failure

independent of the SMTP limit.

MailPilot's architecture sends warm-up traffic through individually addressed, naturally paced

messages per mailbox rather than single high-recipient-count batches, which is both a better

deliverability pattern generally and avoids this class of per-message cap entirely.