SMTP error 552, what it means and what to do

RFC 5321 defines 552 as "Requested mail action aborted: storage allocation exceeded", and unlike its 452 cousin it is a permanent 5xx answer. Modern mail systems use it for two concrete situations: the message exceeds a size limit somewhere on the path (552 5.3.4 family), or the recipient's mailbox is full (552 5.2.2 family). The enhanced code and the text, which usually says plainly which limit was hit, choose the fix.

The fix, in order

  1. Read whether the limit is size or quota. "Message size exceeds fixed limit" and "552 5.3.4" mean the message is too big. "Mailbox full", "over quota", and "5.2.2" mean the recipient has no room. They are opposite problems: one is about your message, the other about their mailbox.
  2. For a size rejection: shrink the message. Compress attachments (photos and documents usually shrink dramatically as a zip or by resizing images), split a large set of files across several messages, or send a download link from a file-sharing service instead of the files themselves. Remember attachments grow about a third when encoded for email, so a 20 MB file becomes roughly 27 MB on the wire.
  3. Know the limits involved. Common caps are 20 to 25 MB at large consumer providers and whatever an organization sets on its own servers. The smallest limit on the path wins, so a message the sender's provider accepts can still be refused at the recipient's side.
  4. For a full mailbox: there is no sender-side fix. The recipient (or their administrator) must free space. Reach them by another channel and let them know; resending identical mail to a full mailbox fails identically, and the queue does not hold 5xx failures for retry.
  5. If you run the receiving server: check the mailbox's actual quota usage and the server's message-size settings. After mailbox migrations, quota values sometimes arrive wrong, and a 552 storm against one user usually means their quota was set to a fraction of what it should be.
  6. If you run the sending server: align the advertised maximum size with what you accept, so your own users get a clear local refusal instead of a confusing remote 552, and log the far side's stated limit from the bounce for support answers.

If it still happens

552 is permanent for that message in that form: change the message's size or wait for the mailbox to be emptied, then send again. It is not a reputation or content judgment, and mail to the same recipient flows normally the moment the storage condition clears.

Common questions

What is the difference between 452 and 552? Both concern storage, but 452 is temporary (retry later, or too many recipients) while 552 is permanent for the message as sent: it is too large, or the mailbox is full, and neither fact changes on a simple retry.

Why was my attachment rejected when it is under my provider's limit? Because the recipient's provider enforces its own, smaller limit, and the encoding overhead counts. The receiving side's number is the one that decides delivery.

Related errors

SMTP error 452 · SMTP error 550 · SMTP error 553