552 5.3.4 message size exceeds limit: why a 19 MB file bounces
552 5.3.4 means a mail server refused your message because its encoded size is over its limit. A 19 MB file can fail a 25 MB cap. How to confirm and fix it.
On this page(8 sections)
A message that bounces with "552 5.3.4 message size exceeds limit" was refused because it is larger than the limit of one server on its path, measured after the attachment was encoded for email. The file on your disk can be well under the stated limit and still fail, because encoding makes it about a third bigger.
This post is about reading that one error: what each part of it means, how to work out which server said it, how to check a limit before you send, and what to do instead. For the wider topic of big files, see why email attachments over 25 MB fail. This one is the troubleshooting view of the exact bounce text.
What does 552 5.3.4 mean?
It is two codes in one line. The first number, 552, is the SMTP reply code. The second, 5.3.4, is the enhanced status code from RFC 3463, where class 5 is a permanent failure, subject 3 is "mail system", and detail 4 is "message too big for system". The 5 at the front of both numbers tells your sender not to retry. If you want the full decoder, see SMTP enhanced status codes, decoded.
The human-readable text after the codes varies by server: "message size exceeds fixed maximum message size", "message size exceeds limit", "message too large". Match on the codes and keep the text for a person to read.
Why does a 19 MB file fail a 25 MB limit?
Because email limits count the encoded message, not your file. Attachments travel as text, usually base64, which turns every 3 bytes into 4 characters and adds a line break every 76 characters. The result is roughly 37 percent larger than the original. Google says the same in its Workspace documentation: receiving limits are measured after encoding, and encoding adds about 37 percent.
| File on disk | Approx. size on the wire | Fits a 25 MB limit? |
|---|---|---|
| 10 MB | 13.7 MB | Yes |
| 18 MB | 24.7 MB | Barely, and the body counts too |
| 19 MB | 26.0 MB | No |
| 24 MB | 32.9 MB | No |
The rule of thumb: divide the stated limit by 1.37 and then leave room for the body, the signature images and any second attachment. For a 25 MB limit, treat about 18 MB as the ceiling, and less if the message has other weight.
Which server sent the bounce?
Several servers on the path can refuse a large message, and the bounce does not always say which one. Read the whole bounce, not just the subject line.
- Find the reporting host. In a bounce, look for lines such as "Reporting-MTA", "Remote-MTA" or a "Diagnostic-Code". The remote host named there is the server that refused the message. If the host is your own provider or relay, the limit is yours. If it is the recipient's provider, the limit is theirs.
- Check the timing. If the refusal came within seconds, the server probably saw the declared size and refused it up front. If it came after a long transfer, it accepted the data and refused at the end.
- Check who produced the text. A bounce generated by your own sending service, before the message ever left, usually names your service. One generated by the recipient's server names their domain.
- Compare with another recipient. If the same message reaches one address and fails for another, the limit is on the recipient's side.
Do not assume the first guess is right. Different tools phrase this error differently, and a message can pass your relay and fail at a gateway in front of the recipient.
How can you check a limit before sending?
Servers can announce their maximum message size. This is the SMTP SIZE extension, defined in RFC 1870. In the reply to EHLO, a server lists SIZE and may follow it with a number of bytes. A number of 0 means no fixed limit, and no number means the server does not say. The sending side can then put its estimated size in MAIL FROM, and a server that cannot accept it replies 552 right then, before the data is sent.
You can see this yourself with the technique in testing SMTP by hand with swaks and openssl:
$ openssl s_client -starttls smtp -connect mx.example.com:25 -crlf -quiet
EHLO test.example.org
250-mx.example.com
250-SIZE 36700160
250-STARTTLS
...Here the server advertises 36,700,160 bytes, about 35 MiB. That is the figure for the whole encoded message. Some servers advertise no limit and still enforce one, and gateways in front of a mailbox may apply a stricter rule, so treat the advertised number as an upper bound, not a promise.
What are the fixes?
Pick the one that matches who owns the limit.
| Situation | Fix |
|---|---|
| The file is a little too big | Compress it (zip, or re-export the PDF with smaller images) until the encoded size is comfortably under the limit |
| One big file | Upload to cloud storage and send a link with an expiry |
| Several files | Split across messages, or bundle into a link to one folder |
| Your own provider or relay refused it | Check its documented limit and raise it if the plan allows; otherwise use a link |
| The recipient's server refused it | You cannot change it. Ask them for another channel or send a link |
| Your app attaches files automatically | Check the size before sending and swap to a link above a threshold you choose |
Google's own documentation takes the same approach for personal accounts: the Gmail attachment limit is 25 MB, and larger files are replaced by a Google Drive link. For an application that sends mail, attachments in transactional email covers the options in more detail.
A link is not free of cost. It adds a click, it can expire, and some recipients' security tools scan or block unfamiliar links, so use a domain people recognize and say in the message what the link is.
How should your app treat this bounce?
A 552 5.3.4 is a permanent failure of this message, not of the address. Retrying the same message will fail the same way. But it does not mean the address is bad, so do not add it to a suppression list because of it. The difference is explained in hard versus soft bounces.
A reasonable handling plan:
- Record the codes and the raw diagnostic text.
- Mark the single message as failed, with the reason "too large".
- Tell the person or system that sent it, with the size in the message.
- Offer to resend as a link.
- Keep sending other messages to that address normally.
Compare that to a 452, which RFC 1870 describes as a temporary shortage of storage at the server and which a sender should retry later.
Where does Koltrix fit?
Koltrix is AI-first email for SaaS teams, with a transactional email API and an SMTP relay. Whatever you send through any relay, check its documented attachment and message limits at docs.koltrix.com rather than relying on a number in a blog post, including the ones here. If an AI assistant reads your mailbox through the Koltrix MCP server, a size bounce is just another message it can summarize for you.
Bottom line
- 552 5.3.4 means a message is too big for one server on its path, measured after encoding.
- Encoded size is about 37 percent more than the file, so divide a stated limit by about 1.37.
- Read the full bounce to find which host refused it, then fix the limit you own or switch to a link.
- Do not retry the same message, and do not suppress the address because of it.
Start with Koltrix
Your domain, one inbox, and an API that sends.
A team inbox where AI sorts and drafts (nothing is sent without your click), plus the transactional API and SMTP relay your product sends with. 7 days free, no card.
