The short answer

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.

Quick fix

Reduce attachment size; if the mailbox is full, reach the recipient another way.

5 - Permanent. The server will not try again. Fix the cause before you resend.

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

• 552 5.3.4 message too big for system

  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.

• 552 5.2.2 mailbox full

  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.

• 552 5.2.3 message length exceeds administrative limit

  A per-mailbox size cap, stricter than the system-wide limit, was exceeded.

• Base64 encoding overhead

  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

1. Measure the encoded size, not the file size
   Multiply attachment bytes by about 1.37 to estimate the wire size before you send.

2. 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).

3. Compress attachments
   Zip them, or re-export images and PDFs at a lower resolution.

4. Trim HTML bloat
   Large inline data-URI images in signatures and embedded base64 images add up fast. Cut them down.

5. Split the content if it cannot be reduced
   Send it across several smaller messages when there is no way to shrink it.

6. 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:

• X.2.2Mailbox full

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.

Related codes

• 523Message length exceeds administrative limit — enhanced 5.2.3 flattened.

• 522Mailbox full — a non-standard label for 552 / 5.2.2.

• 550Mailbox unavailable / address rejected.

• 553Mailbox name not allowed / invalid address.

• 431Server out of memory or disk (temporary).

• All SMTP error codes

Most rejections come back to sender reputation.

Blocklists, auth failures, and policy blocks are what warmup prevents. Warm up your domain so your mail is trusted before you hit send.