SMTP error 452, what it means and what to do
RFC 5321 defines 452 as "Requested action not taken: insufficient system storage", a temporary 4xx failure. Day to day, 452 shows up in two forms. The original form means a server in the chain is short on storage or resources. The second, with enhanced code 4.5.3, is a policy limit dressed in the same number: the message has more recipients than the server accepts in one transaction, common when sending to large distribution lists through a provider with per-message caps.
The fix, in order
- Check for the 4.5.3 recipients variant first. If the bounce text mentions recipients or the failure happened on a message addressed to many people, split the send into batches under the provider's per-message recipient limit. Mailing software calls this chunking, and it fully resolves this variant.
- If the text mentions storage or space: the receiving side (or an intermediate) is resource-short. As a sender there is nothing to repair; the message queues and retries, and delivery usually succeeds once the receiving server frees space. Repeated days of it mean the receiving mailbox or server genuinely needs its operator.
- Distinguish mailbox-full at the recipient. A single full mailbox more often draws 552, but some servers answer 452 while a mailbox is over quota or being processed. If only one recipient at a domain fails this way and others succeed, that mailbox's quota is the likely story and only its owner or their admin can clear it.
- If sending from a client: reduce the recipient count per message and shrink very large attachments before resending. Clients sometimes surface 452 during the initial send to many recipients; a smaller transaction is accepted where the large one was deferred.
- If you run the sending server: confirm queue retries are functioning so storage-variant 452s deliver when the far side recovers, and configure per-destination recipient chunking if you serve bulk senders.
- If you run the receiving server: check actual disk and quota state, queue partition space especially. 452 generated honestly means something is full; generated spuriously, it can follow mis-set quota checks after migrations.
If it still happens
Most senders meet 452 as the recipient-limit variant, which is sender-fixable by batching, or as a transient storage deferral, which fixes itself. The genuinely concerning 452 is the one a server operator sees their own server emitting continuously, since storage exhaustion only trends one way until addressed.
Common questions
Is 452 permanent? No, it is a 4xx temporary failure, and sending servers retry. The recipient-limit variant will keep failing identically until the message is split, because the condition is in the message, not the moment.
How many recipients are too many? There is no universal number; each provider sets its own per-message cap, from a few dozen on consumer accounts to hundreds on business services. The provider's published sending limits give the exact figure to batch under.
Related errors