# 552 5.3.4 Bounce: Message Too Big (Size Limit)

URL: https://email-validation.org/bounce-codes/552-5-3-4/
Updated: 2026-11-06

> Documentation index: https://email-validation.org/llms.txt

**At a glance**

- **Type:** permanent failure (class 5, RFC 3463 §2). The sending server does not retry; sending the same message again fails the same way until the cause is fixed.
- **Basic code 552:** “Requested mail action aborted: exceeded storage allocation” (RFC 5321 §4.2.3).
- **Enhanced code 5.3.4:** “Message too big for system” in the IANA registry (RFC 3463), in the group mail system status (RFC 3463 §3.4).

Your message is larger than the receiving system accepts. Sending the same message again will fail the same way; it has to be made smaller.

## What it means
[RFC 3463 §3.4](https://www.rfc-editor.org/rfc/rfc3463) defines X.3.4 as "message too big for system": the message is larger than the per-message size limit, for physical or administrative reasons, and the code is only useful as a permanent error. The basic code 552 says the action was aborted because a storage allocation was exceeded ([RFC 5321 §4.2.3](https://www.rfc-editor.org/rfc/rfc5321)); RFC 5321 §4.5.3.1.9 gives "552 Too much mail data" as an example reply for an exceeded limit.

The standard sets a floor, not a ceiling. [RFC 5321 §4.5.3.1.7](https://www.rfc-editor.org/rfc/rfc5321) says every server must accept message content of at least 64K octets, headers included, and that servers which impose a limit should announce it with the SIZE extension. Your server can see that limit in the receiving server's EHLO reply, as a line of the form `250-SIZE <octets>`, which gives the maximum message size.

A related code, X.2.3, covers a lower limit set for one mailbox rather than the whole system.

## Common causes
- Large attachments: photos, videos, scans, presentations.
- Several attachments that are each small but large together.
- Attachments grow when they are encoded for email, so a file just under the limit on disk can be over it in transit.
- Very large header sections, for example from long recipient lists or headers added by many systems.
- Embedded images in an HTML message that were inserted at full resolution.

## How providers use it
**Gmail** returns 552 5.3.4 when a message is over its limits, and lists several separate limits: total message size, number of attachments, size of the header section, size of a single header, length of a header name, and the subject ([Google's SMTP error reference](https://support.google.com/a/answer/3726730)). So a message can be refused for its headers even when it has no attachment at all. **Yahoo** lists oversized headers among its 550 policy rejections ([Yahoo SMTP error codes](https://senders.yahooinc.com/smtp-error-codes/)).

## How to fix it
1. Look at the bounce text: it often says which limit was hit and how large the message was.
2. Replace large attachments with a link to a shared file.
3. Compress files, or split them over several messages.
4. Resize embedded images before inserting them.
5. If headers are the problem, find the system adding them. Long chains of forwarding and scanning services each add header lines.
6. If you send from an application, check the receiving server's SIZE value and refuse to send over it, so users get a clear error instead of a bounce.

## Related codes

- [552 5.2.2](https://email-validation.org/bounce-codes/552-5-2-2/): The mailbox is full (or, in Microsoft 365, the sender is over quota)
- [554 5.6.0](https://email-validation.org/bounce-codes/554-5-6-0/): The message is malformed
- [452 4.5.3](https://email-validation.org/bounce-codes/452-4-5-3/): Too many recipients in one message

See [every bounce code](https://email-validation.org/bounce-codes/) in the dictionary.

Many bounces from addresses that do not exist can be avoided: check an address with our [free email checker](https://email-validation.org/email-checker/), or [clean a whole list](https://email-validation.org/bulk-email-verification/) before you send.