Why email attachments over 25 MB fail and what to send instead
A 20 MB file can fail a 25 MB limit. Why base64 inflates attachments, what a bounce for size looks like, and better ways to share large files by email.
On this page(8 sections)
A customer sends you a 22 MB video, the sender's mail app says the limit is 25 MB, and the message bounces anyway. Or your app attaches a 24 MB export, your sending provider accepts it, and the recipient's server rejects it an hour later. Nobody did anything wrong. The numbers just do not mean what they seem to mean.
This guide explains where the size limits come from, why a file smaller than the limit can still fail, what the failure looks like, and what to do instead of attaching a big file. It is written for developers who send mail from an app and for anyone who has to explain to a customer why their file did not arrive.
The limit is on the message, not the file
Email limits apply to the whole message as it travels between servers, not to the file you picked from your disk. A message is made of headers, a text body, often an HTML body, and the attachments. Everything counts.
Attachments are the big part, and they get bigger on the way. Email was designed for text. To carry binary data such as a PDF or a video, the file is encoded as text, usually with base64. Base64 turns every three bytes into four characters and then adds line breaks, so the encoded file is about a third larger, sometimes a little more. A 20 MB file becomes roughly 27 MB on the wire. That is over a 25 MB limit even though the file looked fine.
A practical rule: divide the stated limit by about 1.37 to find the largest file that will fit. For a 25 MB limit, aim for files under roughly 18 MB, and leave room for the message body and any other attachments. If you want safety rather than a calculation, stay far below that.
Whose limit is it?
There is no single email size limit. Every hop can have its own.
- Your own mail app or provider may limit what you can send.
- Your sending service or SMTP relay may limit what it accepts from your app.
- The recipient's mail server sets the limit that matters most, and you rarely know it in advance.
- Gateways and filters in the middle, such as a company's security appliance, may add stricter rules for attachments.
Large providers have published limits of around 20 to 25 MB for sending, and some receive more than they send, but these numbers differ by provider and plan and they change, so check the current documentation before you rely on one. Companies that run their own mail servers often set much lower limits, and some set higher ones. The lowest limit on the path decides.
That is why "it worked last time" proves little. The same file can pass to one recipient and fail to another.
What a size failure looks like
When a message is too large, the receiving server usually refuses it with a permanent error. In the SMTP language, that is a 5xx reply, often with text such as "message size exceeds fixed limit" or "message too large". The sender then gets a bounce message, sometimes called a non-delivery report.
Some details to know:
- The error can come at different moments. Some servers refuse the message right at the start of the conversation when they see its declared size. Others accept the data and reject it at the end. The second case wastes the sender's bandwidth and time.
- It is a permanent failure. Retrying the same message will not help. Your system should treat it like a hard bounce for that message, but not as a reason to stop sending to that address. For the difference, see hard versus soft bounces and what Gmail's 4xx and 5xx rejections mean.
- Bounce text is inconsistent. Do not match on one phrase. Look at the reply code and the enhanced status code, and keep the raw text for a person to read.
- Silent failures exist too. A security gateway may quarantine a large or unusual attachment without telling anyone. If a customer insists they never got it, ask them to check their quarantine or spam folder.
If you run an app that sends attachments, wire bounces into your logs so you can see size failures as their own category. The patterns in a bounce and complaint webhook pipeline apply directly.
Why big attachments hurt even when they arrive
Passing the limit is not the only issue.
Delivery is slower. A big message takes longer to transfer, and long transfers fail more often on slow or busy connections.
Mailboxes fill up. Recipients with small storage quotas may find their inbox full after a few big messages, and then your next message bounces for a different reason.
Filters get suspicious. Large messages with unusual file types are more likely to be scanned deeply, delayed or blocked.
What to send instead
For anything bigger than a few megabytes, send a link. The most common patterns:
- A shared file link from a storage service. Upload to a drive or storage service, then paste the link. Simple for people, and every mail provider handles links well.
- A signed, expiring download link from your own app. If your system sends the file, store it in object storage and email a link that stops working after a period. Your app controls who can open it and for how long. This also lets you revoke access later. Keep the expiry short for anything sensitive, and make the link specific to one file.
- A page in a customer portal. For recurring documents such as invoices or reports, notify by email and keep the file behind a login. The email stays small and the document stays access-controlled.
- Compression or a smaller version. Often a PDF is huge only because of images, and a lower-resolution export is fine. Check this first because it costs nothing.
- Splitting. Sending three smaller messages works in a pinch, but it clutters inboxes and the parts may be delayed separately. Treat it as a last resort.
A few cautions on links:
- Do not attach, and also link, the same file. Pick one.
- Make the link text honest. "Download the report (PDF, 18 MB, link expires in 7 days)" tells the reader what they get and how long they have.
- Avoid links that expire too fast. A reader who opens mail two days later should still be able to get the file. A week is a common starting point for non-sensitive files; adjust to your own risk.
- Mind phishing habits. A message that says "download the attached document here" with a link from an unknown host looks like a classic scam. Use your own domain for file links, so the address matches who you are, and say in the body what the file is and why you are sending it. See spoofing and display-name tricks for what readers have learned to distrust.
- Think about privacy. Anyone with the link can usually open the file. Do not use a public link for sensitive material. For rules on handling personal data in mail, see personal data in email: plain rules for small teams.
For developers sending from an app
If your app attaches files, build in a few guards:
- Check size before you send. Compute the encoded size, not the file size, and compare it to a conservative limit of your own. Fail early with a clear message to your user.
- Set a policy. For example: attach files under a small threshold, link anything above it. Document the threshold and make it a setting, not a constant buried in the code.
- Handle the bounce. Mark the message failed, tell the person who triggered it, and offer the link version.
- Test with a large message. Send one to a few real providers before you rely on the feature. The transactional attachments guide covers types and safety in more depth, and parsing inbound email is useful if you also receive attachments and need to cap what you accept.
For people reading your own inbox
When a customer sends something huge to your shared mailbox and you cannot open it, or it never arrives, a short reply helps:
"Thanks for sending this. The file was too large for our mail system to receive. Could you share it through a download link instead? If that is not possible, tell us and we will suggest another way."
It is polite, specific and does not blame them. For tone and structure in support replies, see writing the first support reply.
A short checklist
- The real limit is the lowest limit on the path, and you rarely know it.
- Encoded size is about 37 percent more than the file size, so a 20 MB file may not fit under a 25 MB limit.
- A size bounce is permanent for that message. Do not retry it, and do not treat it as a bad address.
- Prefer links for anything over a few megabytes, and keep link expiry and access in your own hands.
- Tell the reader what the file is, how big it is, and how long the link works.
Attachments feel like the simplest way to share a file, and for small files they are. Past a few megabytes the message itself becomes the problem, and a clear link is both kinder to the recipient's mailbox and more likely to arrive.
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.
