Attachment Size Limits: Where They Come From and Why They Vary

Every administrator gets this ticket eventually. A user attached a file, the client accepted it, the progress bar completed — and some minutes later a baffling robot-worded message arrived announcing that delivery failed. The user's questions are entirely fair: what is the limit, who set it, and why did a file that seemed to fit still bounce?

The honest answers are more interesting than the folklore. There is no such thing as "the" attachment limit — there is a chain of independent limits enforced by different systems along the message's path, and the smallest one wins. Worse, the file that travels is not the file on disk: email encoding inflates it by roughly a third, so users are always playing against a limit both smaller and less visible than they think.

This article, part of our Email Attachments series, maps every place a size limit can live, explains the encoding growth in plain terms, and teaches you to read a bounce message the way a mechanic reads an engine noise. By the end, "it bounced" tickets should take you minutes, and you will know exactly what advice to give users before they hit Send.

There Is No Single Limit — There Is a Chain of Them

A message with an attachment passes through a series of systems, and each one is entitled to its own opinion about how big is too big. Walking the path from sender to recipient, the checkpoints are:

• The sending client. Mail programs and webmail interfaces often enforce their own attachment cap before anything touches the network. This is the friendliest limit, because it fails instantly, at the moment of attaching, with a clear message.
• The sending mail server. Your own mail system enforces a maximum message size on everything it accepts for delivery. Exceed it and the message is refused at submission — another fast, local failure.
• Security gateways and relays. Many organizations route mail through one or more gateways — servers that scan messages for malware and policy violations before passing them on. Each gateway has its own size ceiling, partly because scanning a message means holding and unpacking the whole thing in memory. There may be gateways on the sending side, the receiving side, or both.
• The receiving mail server. The recipient's system enforces its own maximum on what it will accept from the outside world. This is usually the limit that produces the classic delayed bounce, because it is the first checkpoint the sender's organization does not control.
• The recipient's mailbox. Even an accepted message can fail at the last step if the recipient's mailbox has a per-message cap or is simply out of storage quota.

The rule that falls out of this chain is worth engraving somewhere: the smallest limit along the path wins, and you can only see your own. Your organization might allow generously sized messages while a partner's gateway allows far less; nothing warns the sender in advance, because no system in the chain knows the limits of the others. The diagram below shows the chain as a row of gates, each with its own opening.

Where do the actual numbers sit? Publicly reachable mail systems commonly enforce ceilings somewhere around the tens of megabytes, with internal systems sometimes configured more generously. Resist the urge to memorize specific numbers: they are configuration choices, they differ between organizations, and they change. What does not change is the chain structure and the arithmetic below.

Why the File Grows in Transit

Here is the part that turns a merely annoying system into a genuinely confusing one. Email was designed, from its earliest days, to carry plain text. Everything that travels in a message — including your spreadsheet, your PDF, your zip file — must first be translated into safe, ordinary text characters. The standard translation is called base64, and the idea is simple: take the file three bytes at a time, and represent each three-byte group as four text characters. Three becomes four. Every part of the file gets one third bigger, before it has traveled anywhere.

On top of that four-thirds growth, the encoded text is broken into short lines (mail systems expect lines of modest length), and the message carries structural headers describing the attachment. Together these add a little more. A practical rule of thumb: the message form of a file is about 1.35 to 1.4 times the size of the file on disk. The arithmetic looks like this:

file on disk:                18.0 MB
after base64 (x 4/3):        24.0 MB
line breaks + headers:       ~0.4 MB
message size on the wire:    ~24.4 MB   --> fits through a 25 MB gate, barely

same math for a 19 MB file:  ~25.8 MB   --> bounces at the same gate

safe-file-size rule of thumb:  limit / 1.4
  (a 25 MB message limit means files up to ~17-18 MB are safe)

One related trap deserves its own sentence: limits apply to the whole message, not to each attachment. Three 8 MB documents attached to the same email make one 24 MB payload — call it 33 MB after encoding — and the message bounces even though every individual file looks modest. Users who have learned "keep attachments under about 15 MB" get caught by this constantly, because the rule they memorized is per file and the gate measures per message.

This is also why users swear, truthfully, that their file was under the limit. It was — on disk. The gates along the path never see the file on disk; they see the encoded message, and the encoded message is the one that must fit. When you explain the one-third growth to users, the mystery bounces of the past suddenly make sense to them, and the explanation costs you two sentences: email converts files to text for the trip, and the text version is about a third bigger.

What "It Bounced" Really Means

A bounce is formally a non-delivery report (NDR): an automatic message from a mail server explaining that it could not deliver what you sent. Users forward these to the help desk with the subject line "???", but an NDR is not noise — it is a diagnostic, written by the exact machine that refused the message, usually stating its reason. Reading it carefully is the fastest troubleshooting step available. A typical size-related bounce contains a fragment like this:

Delivery has failed to these recipients or groups:

  pat@partner.example

  Remote server returned:
  552 5.3.4 Message size exceeds fixed maximum message size

Three details in that fragment repay attention:

• Who said no. "Remote server returned" tells you the refusal came from the recipient's side, not yours. If your own server refuses, the failure typically happens immediately at Send, and the wording says so.
• The number 552. Mail servers answer every request with a three-digit reply code; codes starting with 5 mean "permanent failure — do not retry." A 552 specifically signals that the message exceeded a storage or size allocation. Retrying the identical message is pointless, which is precisely what the code is telling you.
• The enhanced code. The dotted number after it refines the story: 5.3.4 means the message is too big for the receiving system — a hard ceiling an administrator configured. If you see 5.2.3 instead, the message exceeded a limit on the individual mailbox — the recipient's own cap or quota. Same symptom for the user, different fix for you.

Timing carries information too. An immediate failure, at the moment of sending, means a local checkpoint refused — client or your own server. A bounce within minutes means a remote gate refused on first contact. A bounce hours later, often mentioning that delivery was retried, means the message sat in a queue while a temporary problem (a full mailbox, an unreachable server) failed to clear. Where the failure happened in time tells you where it happened in the chain — and the chain's full geography, including the scanning stops, is mapped in our companion article on the journey of an attachment.

Why Limits Vary So Much Between Organizations

Users reasonably ask why these limits exist at all, and why one partner accepts a file another refuses. The variation is not arbitrary; each organization is balancing real costs, and different organizations weigh them differently.

Storage multiplies. As we showed in why email is a poor file transfer system, one attachment becomes a copy in every recipient mailbox, on every synced device, and in every backup of all of the above. A mail administrator who raises the message limit is really multiplying the growth rate of the most expensive storage in the building. Conservative limits are how mail systems defend their disks.

Scanning is heavy. Security gateways do not glance at messages; they buffer the entire message, decode the attachments, unpack archives, and inspect what they find. Memory and processing scale with message size, and a gateway that cheerfully accepted enormous messages would need to be sized — and paid for — accordingly. Capping size keeps scanning fast for the overwhelming majority of normal mail.

Queues must stay healthy. Mail servers move thousands of small messages efficiently. A handful of huge messages occupy disproportionate bandwidth and queue time, and a retry storm involving large messages can degrade delivery for everyone. Limits protect the many small messages from the few large ones.

History lingers. Some limits were set years ago, under older constraints, and survive because nothing forced a review. When a partner's limit seems inexplicably tight, it may simply be old. There is rarely malice in a message size limit — only accumulated caution.

The practical consequence: never design a business process around the assumption that a given file size will fit. The partner's limit is invisible, subject to change without notice, and enforced by machines with no sense of urgency about your Friday deadline.

Finding and Setting the Limits You Control

On your own side of the fence, size limits are ordinary configuration, and it is worth knowing all the places one can hide, because they interact. A quick inventory:

Two habits make this inventory useful. First, keep your own limits consistent: if the client allows more than the server accepts, users get late failures instead of early ones, which is the worst experience available. Second, keep them documented where users look — the help desk portal, the new-starter guide — phrased in file terms, not message terms: "attachments up to about X are reliable" after you have done the divide-by-1.4 arithmetic for them.

Finally, verify rather than assume. Limits accumulate in mail systems the way firewall rules accumulate everywhere else, and the documented value is not always the enforced value. Ten minutes with a test mailbox and a set of graduated dummy files — comfortably under, just under, just over your believed limit — tells you what your own chain actually does, including whether the failure arrives early and clearly or late and cryptically. Do the same test toward any partner your business depends on, once, before a deadline depends on it.

What to Tell Users Before They Hit Send

Users do not want a lecture on reply codes; they want a rule that works. This is the guidance that holds up, phrased for a help page:

• Small files — up to a few megabytes: attach freely. This is what email is for, and our companion piece on when attachments are fine says so without embarrassment.
• Medium files — roughly five to fifteen megabytes: usually fine, occasionally bouncy, especially to external partners whose limits you cannot see. Expect the occasional failure and do not build deadlines on top of it.
• Large files — beyond that: stop fighting the medium. Somewhere in the tens of megabytes, some gate on some path will refuse, and the failure will arrive after the user believes the file was sent. Use a transfer link instead.

Notice what compression does and does not buy in each band. Zipping helps text-heavy files — logs, exports, old-format documents — sometimes dramatically. It does almost nothing for photos, video, audio, and modern office formats, which are already compressed internally. And no amount of zipping changes the one-third encoding growth, because encoding happens after compression. Splitting an archive into numbered parts technically works and practically generates a help desk ticket per part; the recipient needs every piece, in order, intact, and one bounce ruins the set.

When the File Is Simply Too Big, Send a Link Instead

Every path through this article converges on the same exit: past a certain size, the answer is not a cleverer attachment — it is not an attachment. The file stays on a server; the recipient gets a short message containing a link; the download happens over HTTPS, the same encrypted web connection used for banking, in the browser the recipient already has. Size ceilings vanish, the one-third growth becomes irrelevant, and the transfer gains properties email never had: one copy, an access log, and the ability to revoke.

Standing up that capability is less work than it sounds. A Windows file transfer server such as Sysax Multi Server serves files over HTTPS through a web interface — recipients click, authenticate, and download with nothing to install — alongside SFTP and FTPS for partners who prefer those protocols. Our HTTP and HTTPS file transfer series covers how browser-based transfer works under the hood, and the human side — getting users to reach for the link instead of the paperclip — is the subject of weaning users off attachments.

The Version to Keep in Your Head

Attachment size limits are a chain, not a number. Client, sending server, gateways, receiving server, and mailbox each enforce their own ceiling; the smallest one wins; and you can only ever see your own links in the chain. The file grows by roughly a third in transit because email converts it to text, so the real file budget is the limit divided by 1.4. A bounce is a diagnostic worth reading: who refused, the reply code, and the timing locate the failure precisely. And when a file will not fit — or will not fit reliably — the durable fix is a link to a managed server, not a heavier attachment.

From here, follow the message through its scanning stops in the journey of an attachment, or step back to the structural argument in why email falls short as a file transfer system.

Frequently Asked Questions