SMTP error 552
Storage allocation exceeded / message too large.
Updated Jul 1, 2026
SMTP 552 is a permanent rejection meaning "requested mail action aborted: exceeded storage allocation" (RFC 5321). The receiving server refused the message because it is too large or the recipient mailbox is over quota. Fix a too-large message by cutting total size (compress attachments, link instead of attach, and account for the roughly 37% Base64 overhead). For a full mailbox, the recipient has to clear space.
Reduce attachment size; if the mailbox is full, reach the recipient another way.
What it means
552 is a permanent 5xx reply defined in RFC 5321 section 4.2.3 as "requested mail action aborted: exceeded storage allocation". In practice it means the receiving server refused the message because it would break a storage or size limit, so either the message is too big or the recipient mailbox is over quota. Because it is a 5xx code it is a permanent failure, and retrying the identical message fails again. The accompanying RFC 3463 enhanced status code tells you which case you hit, so read the full reply line rather than the bare 552.
Common causes
The total message, meaning headers plus body plus every attachment after encoding, is larger than the per-message limit the receiver accepts. This is the most common 552. Gmail and Google Workspace return "552-5.3.4 Your message exceeded Google's message size limits" against a 25 MB ceiling.
Many servers pair 552 with 5.2.2 to report an over-quota recipient, even though RFC 3463 assigns X.2.2 to the transient class-4 code, which makes 452 4.2.2 the RFC-correct pairing. Expect both in the wild: 452 4.2.2 for a temporarily full mailbox and 552 5.2.2 as a widespread hard-cap variant.
A per-mailbox size cap, stricter than the system-wide limit, was exceeded.
Attachments are MIME-encoded with Base64, which inflates size by about 37%. A 19 MB file becomes roughly 26 MB on the wire, over the 25 MB Gmail limit, so a file that looks under the cap still bounces. Size the message after encoding, not before.
How to fix it
- Measure the encoded size, not the file size
Multiply attachment bytes by about 1.37 to estimate the wire size before you send.
- Link large files instead of attaching them
Upload to Drive, S3, or Dropbox and send a URL. This is the most reliable fix for big files (5.3.4 and 5.2.3).
- Compress attachments
Zip them, or re-export images and PDFs at a lower resolution.
- Trim HTML bloat
Large inline data-URI images in signatures and embedded base64 images add up fast. Cut them down.
- Split the content if it cannot be reduced
Send it across several smaller messages when there is no way to shrink it.
- For a full mailbox (5.2.2), the recipient acts
Nothing on the sending side changes this. Ask the recipient to delete mail or raise the quota. As a permanent failure, suppress the address and stop retrying until you have a signal the box was cleared.
Paired code
A real bounce often shows both a 3-digit code and an enhanced code together. This one commonly pairs with:
Common questions
Is SMTP 552 a permanent or temporary error?
Permanent. 552 is a 5xx reply per RFC 5321, so resending the same message fails again. The temporary counterpart is 452. RFC 3463 assigns the "mailbox full" enhanced code X.2.2 to the transient class, so the RFC-correct pairing is 452 4.2.2, which is why many servers send that for a temporarily full box even though 552 5.2.2 is also common as a hard-cap variant.
What is the difference between 552 5.3.4 and 552 5.2.2?
5.3.4 means the message is too big for the receiving system, which you fix by shrinking or linking the content. 5.2.2 means the recipient mailbox is full, which only the recipient can fix by freeing space.
Why does my attachment bounce with 552 even though it is under the size limit?
Base64 encoding adds about 37% to attachment size. A 19 MB file lands near 26 MB on the wire, past a 25 MB cap. Check the size after encoding.