5.3.4: your message exceeds the receiving system's size limit

What the bounce means

5.3.4 is the enhanced status code RFC 3463 defines for a message that is too big for the receiving system. Not one mailbox, not one recipient: the mail system you were delivering to enforces a ceiling on message size, your message was over it, and the server refused to take it at all. Because this is a generic code that any server can emit, the three-digit reply in front of it varies; it often appears as 552 5.3.4 or 554 5.3.4, and the enhanced code is the reliable part.

The leading 5 makes it permanent. Your server has already given up on this message, and resending it unchanged will produce the same rejection. Nothing about your domain's reputation or authentication is being judged here: the message is simply larger than this system accepts, and only a smaller message changes the outcome.

Why the limit is smaller than it looks

Two things routinely surprise senders. The first is where the ceilings sit. Limits vary by receiver and the bounce you got is the authoritative statement for the system you hit, but as rough orientation: the big consumer providers commonly allow around 25 MB per message, while corporate gateways are often configured to 10 MB or lower. Assume less headroom than the consumer number whenever you are mailing a business domain.

The second is that receivers measure the encoded message, not the file on your disk. Attachments travel base64-encoded, which inflates them by roughly a third, plus headers and body text on top. A system with a 20 MB ceiling therefore fits an attachment of roughly 14 to 15 MB, and a file that looked safely under the published limit can still bounce. When a “small enough” attachment triggers 5.3.4, encoding overhead is almost always the explanation.

How to get the content delivered

• Send a link, not the file. Upload to a file-sharing service or shared drive and mail the link. This is the fix that works everywhere: it clears this system's ceiling and every stricter gateway after it, and it is the right default for anything above a few megabytes.
• Shrink the message. Compress the attachment, export at lower resolution, or send only the part the recipient needs. Leave real margin under the limit to absorb the encoding overhead.
• Do not retry unchanged. A permanent rejection does not soften with repetition. Repeated identical attempts just burn queue time, and a pattern of them can make your sending look careless to the receiving system.
• Check which system said no. The bounce names the server that refused the message. If it is a gateway in front of the recipient's real mailbox, its limit governs, and the recipient may not even know the ceiling exists. Point them at the bounce text if you need the limit raised.

Frequently asked

What does 5.3.4 mean?

The message is larger than the receiving mail system accepts, for any recipient. It is a permanent failure: the server compared the message length against a system-wide ceiling and refused it. The same message will bounce the same way every time until it gets smaller.

How is 5.3.4 different from 5.2.3?

5.3.4 is the system-wide size limit: the receiving mail system refuses the message no matter which mailbox it is addressed to. 5.2.3 is the per-recipient version: one specific mailbox's limit rejected it while others on the same system might accept it.

What size limit do most mail providers enforce?

It varies, and the bounce itself is the authoritative answer for the system you hit. As rough orientation, the big consumer providers commonly sit around 25 MB, while corporate gateways are often set to 10 MB or lower. Remember these limits apply to the encoded message, which runs roughly a third larger than the attached file.

Should I retry a 5.3.4 bounce?

No. It is a 5.x.x permanent rejection, so retrying the identical message wastes time and can look like abusive sending. Make the message smaller, or replace the attachment with a download link, and send that instead.