SMTP Error 552

SMTP 552 is a permanent (5xx) reply defined in RFC 5321 §4.2.3 as:

552 Requested mail action aborted: exceeded storage allocation

In practice it means one thing: the receiving server refused the message because it would exceed a storage or size limit — either the message is too big, or the recipient's mailbox is over quota. Because it is a 5xx code, it is a permanent failure: retrying the identical message will fail again.

What causes SMTP Error 552?

The accompanying RFC 3463 enhanced status code tells you which case you hit. Read the full reply line, not just the 552:

• 552 5.3.4 — "Message too big for system." The total message (headers + body + all attachments, after encoding) is larger than the per-message limit the receiver accepts. This is the most common 552. Gmail/Google Workspace returns 552-5.3.4 Your message exceeded Google's message size limits for this, against its 25 MB ceiling.
• 552 5.2.2 — "Mailbox full." Many real-world mail servers pair the basic code 552 with the enhanced code 5.2.2 ("Mailbox full") to report an over-quota recipient — even though RFC 3463 designates X.2.2 for use only with the transient class-4 code, meaning the RFC-correct pairing is actually 452 4.2.2. In practice, expect to see both: 452 4.2.2 for a temporarily full mailbox, and 552 5.2.2 as a common (non-compliant but widespread) hard-cap variant.
• 552 5.2.3 — "Message length exceeds administrative limit." A per-mailbox size cap, stricter than the system-wide limit, was exceeded.

A frequent surprise: an attachment that looks under the limit still bounces. Email attachments are MIME-encoded with Base64, which inflates size by roughly 37%. A 19 MB file becomes ~26 MB on the wire — over Gmail's 25 MB limit. Always size your message post-encoding.

The original guidance that 552 is about disallowed attachment file types is inaccurate. Type/content rejections are usually expressed with 5.7.x policy codes (often on a 550/554); plain 552 is about size and storage, per the RFCs above.

How do I fix SMTP Error 552?

For a too-large message (5.3.4 / 5.2.3) — the sender's job:

1. Check the encoded size, not the file size. Multiply attachment bytes by ~1.37 to estimate the wire size.
2. Don't attach large files — link them. Upload to Drive/S3/Dropbox and send a URL. This is the most reliable fix for big files.
3. Compress attachments (zip, or re-export images/PDFs at lower resolution).
4. Trim HTML bloat — large inline (data-URI) images in signatures and embedded base64 images add up fast.
5. Split the content across multiple smaller messages if it cannot be reduced.

For a full mailbox (5.2.2) — the recipient must act: there is nothing the sender can change. Ask the recipient to delete messages or raise their quota. As a permanent failure, suppress the address and stop retrying until you have signal the box was cleared.

If you send through an ESP (SendGrid, SES, Mailgun) or via Courier, the 552 surfaces in your delivery/bounce logs as a hard bounce. Log the full enhanced status string so you can distinguish a size problem you can fix from a recipient-side quota problem you cannot. Treat 552 as a permanent bounce and remove the recipient from further retries to protect sender reputation.