Why Email Is a Terrible File Transfer System — and Why Everyone Uses It Anyway

Somewhere in your organization right now, somebody is attaching a file to an email. A spreadsheet for the accountant, a contract for a customer, a zipped folder of photos for the marketing agency. Multiply that by every organization on earth and you reach an awkward truth: email is the most widely used file transfer system ever built, and it is also one of the worst tools ever pressed into that job.

This is not because users are careless or lazy. People attach files to email for excellent reasons, and any administrator who wants to change the habit has to start by respecting those reasons. Email reaches everyone, requires no setup, and simply works. The problems only appear after the Send button — and they appear somewhere users never look.

This article, part of our Email Attachments series, walks through what actually happens when a file travels by email: how copies multiply across mailboxes and backups, why a sent file can never be taken back, why nobody can say who has it, and why size ceilings keep biting. By the end you will be able to explain the problem to users and leadership clearly, without a trace of blame — and you will know what a better default looks like.

Why Everyone Reaches for Email First

Before criticizing the habit, be honest about why it exists. Email has properties that almost no other transfer mechanism matches:

• Universal reach. Every business contact on earth has an email address. There is no other identifier you can rely on so completely.
• Zero setup for the recipient. No account to create, no password to invent, no software to install, no firewall exception to request. The file just appears.
• It carries its own context. The file arrives inside the conversation that explains it. Six months later, searching the thread finds both the discussion and the document.
• It is asynchronous. The recipient does not need to be online, ready, or even awake. The mail system holds the message until they collect it.
• It never says no. Nobody was ever refused permission to send an email. There is no request form, no ticket, no waiting.

Now look at what email often competes against inside an organization: a portal that requires a new account, a shared drive the external partner cannot reach, a transfer tool that needs a client installed and a firewall rule approved. If the sanctioned path takes nine steps and email takes two, users are not misbehaving when they choose email — they are optimizing, exactly the way you would. That insight matters so much that we devote a whole article to it: weaning users off attachments is about making the secure path the easy path, because nothing else works.

So the case against attachments cannot be "users should try harder." It has to rest on what email actually does to a file. Which brings us to the mechanics.

One Click of Send, a Dozen Durable Copies

Email moves messages by a method called store and forward: each mail server in the path receives the complete message, writes it down, and then passes a copy to the next server. Nothing "travels through" a mail system the way water travels through a pipe. The message — attachment included — is duplicated, whole, at every stop.

Follow one file through a perfectly ordinary send. You attach a 5 MB report and address it to one colleague, with two more people on CC. Count what exists within twenty-four hours:

• Your Sent folder keeps a full copy, and tonight your mailbox backup preserves it again.
• Your mail server held a copy in its queue, and depending on retention settings may keep it longer.
• Each of the three recipients gets a copy in their mailbox — three more.
• Each device that syncs those mailboxes — a laptop, a phone, maybe a tablet each — caches its own copy. Call it two devices per person: six more.
• Each recipient's mailbox backup captures the message tonight: three more.
• If either organization uses journaling — a compliance feature that archives a copy of every message passing through the mail system — add another permanent copy or two in an archive designed never to forget.

That is somewhere around fifteen durable copies of the file, created automatically, in under a day, from one click. Nobody decided to make fifteen copies. Nobody will ever decide to delete them. And if any recipient forwards the message, the entire multiplication starts again from their mailbox — invisibly to you. The diagram below shows the same story in one picture: a single send fanning out into copies on the sender's side, in every recipient's mailbox and devices, and in every backup behind them.

Compare that with what the word "transfer" is supposed to mean: one copy leaves a system you control and arrives in a system the recipient controls, on purpose, once. That deliberate, countable movement of data is the subject of our file transfer fundamentals series. An attachment is not a transfer in that sense at all. It is closer to publication.

There Is No Unsend

Every mail client eventually grew a "recall" or "undo send" feature, and every administrator eventually explains why it did not work. The honest version: undo send is usually just a short delay before the message really leaves, so it only works within that window. Recall features generally work only when both mailboxes live in the same mail system and the recipient has not opened the message. Across organizational boundaries — exactly where sensitive mistakes matter most — recall does nothing. The copy in the recipient's mailbox belongs to the recipient's mail system, and yours has no authority over it.

Picture the classic accident. A user types a first name, autocomplete offers two Sarahs, and the payroll summary goes to the wrong one — a supplier contact instead of the HR manager. With a link-based system, this is an incident with a fix: disable the link, and the file behind it becomes unreachable before most people's coffee cools. With an attachment, the file itself crossed the boundary at the moment of delivery. There is nothing left to disable. You can ask nicely for deletion, and you may even get it, but you can never verify it — not in the mailbox, not on the phone that synced it, not in the backup that ran overnight.

The difference is structural, not cosmetic. Link-based sharing keeps the file on a server you control and hands out only a pointer; revocation is built into the shape of the thing. Attachments hand out the payload itself; revocation is impossible in principle. No amount of policy or apology changes which shape you chose at the moment of sending.

No Audit Trail: Who Has This File Now?

Ask a simple question about any file that left by email six months ago: who has it today? With attachments, the honest answer is always the same — nobody knows, and nobody can find out.

Mail systems keep delivery logs: server A accepted message such-and-such and handed it to server B at a certain time. That is genuinely useful for troubleshooting, but it records the movement of messages, not the fate of files. Delivery logs cannot tell you whether the attachment was ever opened, whether it was saved to a laptop, whether it was forwarded to a personal address, or how many of those fifteen copies have since become fifty. Forwarding is the killer: every recipient is a potential new sender, and their sends do not appear in any log you can see.

Now put that answer in front of an auditor. Compliance regimes that deal in personal data, health records, or financial information tend to ask exactly this class of question: who accessed this data, when, and from where? A file distributed by attachment makes the question unanswerable. A file distributed from a managed transfer server makes it a report. This is one of the quiet, decisive advantages of running file distribution through a server you administer — a product like Sysax Multi Server, for example, writes an activity log of every login and every download, so "who retrieved this file" has an answer with timestamps on it. Email cannot offer that, because email was never designed to.

The Size Ceiling — and the Invisible Growth

Even users who cheerfully accept all of the above eventually collide with the limit. Mail systems cap message sizes, commonly somewhere around the tens of megabytes, and the cap that matters is whichever is smallest along the whole path — your client, your server, any security gateway, and the recipient's system each enforce their own. You can see your own limits; you cannot see theirs. The full story of stacked limits lives in our companion article on attachment size limits.

There is also a growth effect that surprises nearly everyone. Email was designed to carry text, so binary files are translated into text for the journey using an encoding called base64 — every three bytes of the real file become four characters of mail-safe text. The translation is perfectly reversible, but it makes the emailed form of a file roughly a third larger than the file itself. A 21 MB attachment becomes a 28 MB message. Users experience this as pure mystery: "the file is under the limit and it still bounced." It did not bounce at its size; it bounced at its size plus one third.

The workarounds users invent — zipping, splitting archives into parts, resending to one recipient at a time — each generate their own support tickets. Compression barely helps with the most common large files, because photos, videos, and modern office documents are already compressed. The ceiling is not a nuisance to be dodged; it is email politely telling everyone that it was built for messages, not payloads.

Version Chaos: Ten Copies, No Truth

There is a subtler cost that never produces a bounce message. The moment a document is attached and sent, it forks. Each recipient now holds an independent copy, and each copy begins its own life. One person edits and sends back. Another edits a stale copy and sends that back. A third forwards the original onward. Within a week the thread contains Budget_FINAL.xlsx, Budget_FINAL_v2.xlsx, and Budget_FINAL_v2_JMedits_USE_THIS.xlsx, and somebody is manually merging changes by eye on a Friday evening.

None of this is user error. It is the inevitable behavior of a system whose only operation is "make another copy." A file that lives in one shared, authoritative place has a current version by definition. A file distributed by attachment has as many current versions as it has recipients. When people complain about attachment culture, half the pain they are describing is really this: email cannot represent the idea of the document, only a copy of it.

The Costs You Only See at Scale

Individual users meet these problems one at a time. Administrators meet them multiplied, and it is worth naming the aggregate costs, because they justify the effort of changing the default:

• Storage multiplication. The same presentation stored in forty mailboxes, each backed up on its own schedule, is storage bought forty times over — and mailbox storage is among the most expensive kinds to expand and the slowest to migrate.
• Legal discovery. When a dispute requires producing every copy of a document, "it went out by email" turns a search of one server into a search of every mailbox, archive, and backup in scope.
• Scanning load. Every attachment is unpacked and inspected by security gateways on both sides — work that grows with every megabyte, and one reason large messages crawl. Our article on an attachment's journey follows that path hop by hop.
• Help desk volume. Bounces, missing attachments, quarantine releases, "can you resend as a zip" — a steady tax on support time that never appears under a single budget line.

What Better Looks Like (Without Making Life Harder)

The alternative to attachments is not a lecture; it is a mechanism that wins the convenience contest. From everything above, the requirements write themselves. A replacement must be as easy as attaching. It must work for external recipients with nothing to install and no account ceremony. It must keep one copy of the file on a system you control, so revocation and versioning are real. It must log access, so audit questions have answers. And it must shrug at file size.

Here is the comparison in one table — useful verbatim when you need to make the case to leadership:

The last row is the one that decides adoption. The mechanism most external recipients accept without friction is a plain HTTPS link — the same secure web connection they use for banking, opened in the browser they already have. That is why HTTPS-based file transfer, covered in depth in our HTTP and HTTPS file transfer series, is the natural landing place for former attachment traffic: a file transfer server with a web interface, such as Sysax Multi Server, lets a recipient click a link, authenticate, and download over HTTPS with no client software installed — while the file itself stays in one logged, revocable place.

Getting people to actually make that switch is a change-management craft of its own — pilot groups, honest friction-counting, empathy for holdouts — and it has its own article: weaning users off attachments.

The Bottom Line

If a colleague asks for the one-minute version, it is this. Email is a superb messaging system and a terrible file transfer system, and the difference is structural. Sending an attachment duplicates the file into every mailbox, device, and backup along the way; it can never be recalled; no log anywhere records who has it; and the whole arrangement fails outright somewhere around tens of megabytes. People use it anyway because it is universal and effortless, and they are right about that — so the fix is never to scold users, but to offer a path that is just as easy and structurally sound: one copy, on a managed server, behind a revocable, logged HTTPS link.

To keep going in this series, follow a file through the pipeline in the journey of an attachment, or jump straight to the honest counterpoint — when attachments are perfectly fine — because a policy that pretends email is never the right tool will be ignored, and will deserve it.

Frequently Asked Questions