452 4.5.3 is a 4xx code — doesn't that mean I should just retry?

Yes and no. The leading 4 means transient (RFC 5321 §4.2.1): the session was fine and the server isn't down, so a retry is allowed. But retrying the identical message against a fixed per-message recipient cap just hits the same cap and fails again. The 4xx only self-resolves when the limit was momentary. When it's a hard cap — Gmail's SMTP path, a Postfix smtpd_recipient_limit, an Exchange connector — the durable fix is to split the recipient list and send it as several transactions, not to re-queue the same fat one.

How is 452 4.5.3 different from 452 4.2.2 or 550 5.5.3?

Different problems that read alike. 4.5.3 (RFC 3463, 'Too many recipients') is about the *count* of recipients in one message — too many RCPT commands in a single transaction. 4.2.2 ('Mailbox full') is about *one* recipient's storage quota, not the count. 550/552 5.5.3 is the *permanent* form of the same too-many-recipients condition — same meaning as 4.5.3 but non-retryable, which is what Exchange returns (RESOLVER.ADR.RecipLimit) when a transport or mailbox envelope limit is hit rather than a connector limit. And 421 4.7.x is rate/reputation throttling at the connection level, not a recipient count.

What's the actual recipient limit, and is it my server or theirs?

It depends on whichever server rejected the RCPT. Gmail's SMTP paths cap a single transaction at 100 recipients (its web UI and API allow more — a separate limit). Postfix defaults smtpd_recipient_limit to 1000. On-premises Exchange Receive connectors default MaxRecipientsPerMessage to 200 and deliberately return 452 4.5.3 to force the sender to chunk; Exchange Online defaults to 500 per message. Read the bounce: the host that emitted 452 4.5.3 owns the cap, and your fix is to send within it.

452 4.5.3 Too Many Recipients: Why Retrying Won't Help

Problem

A message bounces — or your mail server logs — 452 4.5.3 Too many recipients, sometimes worded 452 4.5.3 Your message has too many recipients. It’s the newsletter script, the “reply-all” to a 300-person list, the cron job that CCs every customer. The tempting read is that mail is broken and a retry will sort it out. It won’t, not on its own. You put too many recipients on one message, and a server along the way declined to take them all at once.

Symptoms

The bounce or log line carries 452 4.5.3 and text about “too many recipients.”
Small sends work; the failure only shows up on messages with large recipient lists.
Some recipients on the message did receive it, and only the overflow bounced.
Re-sending the identical message reproduces the exact same rejection, every time.
It surfaces on an automated path — a script, a mailing tool, a printer/scanner emailing a big group — not when you hand-type a couple of addresses.

What 452 4.5.3 Actually Means

Read the code as two halves. The 452 is the SMTP reply (RFC 5321): a transient negative — class 4 means “the command didn’t succeed, but the condition is temporary and may be tried again” (§4.2.1). The 4.5.3 is the enhanced status code, and RFC 3463 defines it precisely: “Too many recipients — more recipients were specified for the message than could have been delivered.” RFC 3463 even prescribes the cure in the definition: segment the message and deliver the remaining recipients in a subsequent attempt.

There’s a piece of SMTP history baked in here. RFC 821, the original 1982 spec, listed the too-many-recipients error under reply code 552. RFC 5321 §4.5.3.1.10 corrected that: the right code for “I’ve hit my per-transaction recipient limit” is 452, and a client that gets it should deliver to the recipients that were accepted, then retry the rejected ones in a new transaction. That’s the whole design intent — 452 4.5.3 is not “your mail is rejected,” it’s “send them in smaller batches.”

And the reason there’s a floor at all: RFC 5321 §4.5.3.1.8 requires every SMTP server to buffer at least 100 recipients per message. Rejecting a message with fewer than 100 RCPTs for being “too many” violates the spec. Above 100, a server is free to cap, and a well-behaved client is expected to transmit in 100-recipient chunks when it does.

Top 3 Causes

You blew past a hard per-message cap. Gmail’s SMTP paths (smtp.gmail.com, smtp-relay.gmail.com) reject beyond 100 recipients in one transaction with exactly this code. The tell: the same message always fails at the same size, and the receiving side is a big provider. The fix is not a setting on their end — it’s chunking on yours.
The receiving mail server’s config set a limit. Postfix rejects past smtpd_recipient_limit (default 1000) with 452 4.5.3 Error: too many recipients. On-premises Exchange Receive connectors default MaxRecipientsPerMessage to 200 and return 452 4.5.3 on purpose, to make your server split the load. The tell: you control (or can ask about) the receiving server, and the number is oddly round.
You’re treating a permanent limit like a transient one. If the code is actually 550 5.5.3 (or Exchange’s RESOLVER.ADR.RecipLimit), that’s the permanent twin — a transport-wide or per-mailbox envelope limit, not a connector limit. Retrying will never clear it. The tell: a 5xx, not a 4xx. The fix is the same (split the list), but there’s no “wait and it’ll go through.”

Diagnose with DechoNet

Email Check — pull the recipient domain’s MX, SPF, DKIM, and DMARC in one pass. It won’t count recipients, but it confirms the receiving side is otherwise healthy, so you know 452 4.5.3 is purely a recipient-count problem and not an authentication bounce wearing a different hat.
DNS Lookup — confirm the MX actually points where you think, so you’re reading the right server’s limit and not chasing a stale or split-MX target that’s applying a cap you didn’t expect.

Resolution Checklist

Read the bounce and note the exact code — 452 4.5.3 (transient, retry the overflow) versus 550/552 5.5.3 (permanent, must split before any retry succeeds).
Identify which server emitted it — your outbound relay, or the recipient’s MX — from the Received/reject line. That server owns the cap.
Split the recipient list into chunks at or below that server’s limit (≤100 for Gmail SMTP is a safe universal floor) and send each chunk as a separate transaction.
If you run the receiving server and the limit is too low for a legitimate internal sender, raise the right knob — Postfix smtpd_recipient_limit, Exchange connector MaxRecipientsPerMessage — rather than removing the guardrail entirely.
For bulk or list mail, stop hand-rolling giant RCPT lists; use a mailer or ESP that batches and paces automatically.
Re-send a chunked test and confirm the 452 4.5.3 is gone.

When to Escalate

If you’ve chunked below 100 recipients per message and still get 452 4.5.3, the number in the message isn’t the real trigger — look for a daily recipient cap or a rate limit (often surfaced as 421 4.7.x), which is a volume and reputation problem, not a per-message one.
If the code is 550 5.5.3 from a server you don’t control, the recipient’s admin set an envelope limit below your send size. There’s no client-side retry that fixes it; coordinate a smaller batch size or ask them to adjust the limit for your sender.

Check your own domain now

Free, no sign-up. Runs the exact check this guide describes and shows what to fix.