Mail is not freight

Every so often a customer contacts us frustrated because they cannot send a large file by email. The message bounces back with an unhelpful error about size limits. They try compressing the file, splitting it across multiple emails, or attaching it to a different message hoping it will work this time. It does not. They want to know why email cannot just accept the file they are trying to send.

The honest answer is that email was never designed for what they are trying to do, and the way to think about it is with an analogy that makes the whole picture obvious once you see it.

The envelope

Email is mail. Mail is designed to fit in envelopes. Envelopes are designed for letters. A letter is a small amount of text on a standard piece of paper, folded to fit inside a standard envelope, weighed at the post office, and delivered by whatever mail carrier is handling that route. The whole system, from the sender’s writing paper through the postbox and the sorting office and the delivery van to the recipient’s mailbox, is built around the physical constraint of what fits in an envelope.

You can put a small photograph in an envelope. You can put a folded document in an envelope. You can put a birthday card in an envelope. Each of these fits within the physical assumption the system was designed around.

You cannot put a book in an envelope. You cannot put a laptop in an envelope. You cannot put a filing cabinet’s worth of documents in an envelope. When you try, the envelope either does not close, or it rips open in transit, or it gets refused by the post office because it exceeds the weight limit for envelope handling, or it does eventually arrive but only because it got redirected through a completely different system.

For anything larger than what fits in an envelope, the answer is not to buy a bigger envelope. The answer is to use freight.

Freight uses a different set of infrastructure: courier services, trucks, shipping containers, tracking numbers, delivery scheduling. It is designed for exactly what it does, which is moving physical things that are too large or too heavy for the mail system.

Email works the same way. The envelope is metaphorical, but the constraint is real. Email was designed in an era when a few kilobytes was a substantial amount of data, and the underlying protocols were built around the assumption that messages would be small. Every mail server in the delivery chain still operates on that assumption, which is why every mail server has a size limit. The limit is different at different servers, but there is always a limit somewhere, and the moment your message exceeds the smallest limit in the chain, it bounces.

If you are trying to send a large file by email, you are trying to freight a package inside an envelope. The system was not built for this. There is no envelope large enough to change that.

Why the limit is unpredictable

The frustrating thing about email size limits is that you often do not know what they are until you hit them. Your own mail server might accept a 50 megabyte message and send it out fine. The message then travels through internet infrastructure to the recipient’s mail server, which might have a 25 megabyte limit and rejects the message with a bounce. From your perspective, you sent the email successfully. From the recipient’s perspective, they never received it. The bounce message you get back is often terse and unhelpful, mentioning size but not being specific about what the limit was or where in the chain it was hit.

This is because email is a two-party system with intermediaries, and every party in the chain enforces their own limits. The sender’s server has a limit. The recipient’s server has a limit. In corporate environments, there is often an additional mail filter or security appliance in front of the recipient’s server that has its own limit and its own rules. Any of these can reject the message, and the sender has no way to know the limits in advance.

There is also a technical detail that makes the size problem worse than it looks. Email attachments are not sent as raw binary data. They are encoded as text using a system called MIME, which turns each byte of the file into approximately 1.33 bytes of text. A 20 megabyte file becomes a 27 megabyte email attachment. When your mail client tells you the file is 20 megabytes, the message travelling across the network is actually larger than that, and it is the encoded size that gets measured against the mail server limits. This is why files that look like they should fit under a 25 megabyte limit sometimes bounce anyway.

Even when large emails succeed, they cause problems

The size limits exist for good reasons beyond legacy protocol design. Even when a large email does make it through, it creates operational problems at both ends, and the storage impact is much larger than most people realise.

When you send an email with a large attachment, the file is not just sent. It is also kept. The message goes into your sent folder on your own mail server the moment you press send, and it stays there. Unless you deliberately go back and delete it, the copy is permanent, and it is invisible to you in day-to-day work: you send the email, you assume the file has gone somewhere, and you get on with your life. Meanwhile the copy in your sent folder quietly accumulates in your mailbox for years, along with every other large attachment you have sent throughout your career. This is the specific reason why mail administrators periodically discover that a customer’s mailbox is enormous, and why the customer is always surprised.

The multiplication is worse when you consider the recipients. If you send a message with a 30 megabyte attachment to five recipients, there are now six copies of it: one in your sent folder, and one in each recipient’s inbox. If any of those recipients uses IMAP and accesses their mail from multiple devices, additional copies are downloaded and stored on each device. If any recipient forwards the message, the whole attachment travels again and gets stored in more places.

The other operational costs are real too. The sender’s mail server has to hold the entire message in memory or on disk during transmission, which uses resources that could be handling other messages. The recipient’s mail server has to accept the message and store it. The recipient’s mailbox has a storage quota, and a single large attachment can push a mailbox over its quota, at which point the recipient stops receiving all mail until they clear space. Your own sent folder has a quota too, and enough large sent messages will eventually cause the same problem for you.

Email was designed for messages that are small enough to make all of this negligible, and the moment attachments get large, none of it is negligible any more.

The right answer: use freight

The correct approach for anything that would not comfortably fit as an email attachment is to use a proper file transfer service and send an email with a link to it. This is exactly like sending a courier: the freight travels in the appropriate infrastructure, and the paperwork travels in an envelope.

The specific tools depend on your situation. For small businesses, several patterns work:

A dedicated file transfer service. WeTransfer, Smash, or Filemail are designed specifically for sending large files by link. You upload the file to their service, get a link, and email the link to the recipient. The service handles the actual file transfer through infrastructure built for large files. This works well for one-off transfers to external recipients.

Cloud storage sharing. If you already use Google Drive, Dropbox, OneDrive, or Nextcloud, most of these support sharing individual files or folders with a link. Upload the file, get a share link, and email that. This is generally better than a dedicated transfer service for files you might want to share again or reference later, because the file lives somewhere you can access.

Sensitive files should use a properly secured channel. For anything containing personal information, financial details, or confidential business content, do not use the general-purpose transfer services. Use a service designed for secure transfer with end-to-end encryption. We wrote about this in more detail in the piece on email security for legal work, and the same principle applies to any sensitive file: the right channel is not an email attachment or a generic cloud share, it is a properly encrypted transfer that authenticates the recipient.

For frequent large-file transfers with specific parties, set up a proper sharing arrangement. If you regularly exchange large files with a specific customer or supplier, a shared folder in Nextcloud, a shared drive in one of the cloud storage platforms, or a dedicated file transfer arrangement is much better than emailing links each time. The file appears in the shared space, both parties can access it whenever they need to, and there is a clear record of what has been shared.

The pattern in every case is the same: the file lives somewhere designed to handle it, and the email carries only the notification and the link.

The size of the limit is not the point

Customers sometimes ask us whether we can raise the attachment size limit on their mailbox. We can, within reason, and if there is a specific business need we will discuss it. But raising the limit does not solve the underlying problem. Even if we accept a 100 megabyte attachment leaving our server, the recipient’s server might still reject it, and the customer’s message still fails to deliver. Raising the limit on the sending side just moves the failure point further along the chain without changing the fundamental fact that email was not designed for freight.

The better answer, almost always, is to use the appropriate tool. Email for messages. File transfer services or shared drives for files. This separation is not a limitation of the modern internet; it is the correct architectural choice. Email is good at what it does specifically because it stays small and reliable. File transfer services are good at what they do specifically because they are built for the job.

If you have been fighting with attachment size limits and losing, the answer is not a bigger envelope. It is freight.

When to talk to us

If you are hitting attachment size limits regularly and it is genuinely getting in the way of how you work, there are things we can help with. Setting up a shared Nextcloud folder for your regular file exchange partners. Configuring a proper secure file transfer arrangement for sensitive materials. Reviewing whether your current mail setup is well-matched to your actual file transfer patterns. None of this is difficult, and all of it is more sustainable than trying to make email do what email was never designed for.

Send us a message. The email itself will be small.