Email size limits catch many teams out because the numbers they see are not the numbers that count. A 20 MB report looks acceptable until it is encoded, wrapped in headers and placed in a message with a body, and then it exceeds what the receiving server accepts. At the same time, correctly sized messages can still arrive broken if their structure or character encoding is wrong. This guide explains how messages are put together, how big they really are, and how to build them so that they arrive intact.
What an email message actually contains
An email is plain text in a defined format. A block of headers comes first, such as From, To, Subject and Date, followed by a blank line and then the body. The original standard allowed only a narrow set of characters. MIME, defined in the RFC 2045 series, extended it so that a message can hold several parts, binary files and other character sets, by encoding everything into safe text.
| Part | Purpose | Example |
|---|---|---|
| Headers | Describe the message and its structure | From, To, Subject, Content-Type, MIME-Version |
| Text part | Plain text version | Content-Type: text/plain; charset=UTF-8 |
| HTML part | Formatted version | Content-Type: text/html; charset=UTF-8 |
| Attachment | A file the reader can save | Content-Disposition: attachment; filename="invoice.pdf" |
| Inline resource | An image used within the HTML | Content-ID referenced from the HTML |
A typical structure
multipart/mixed
multipart/alternative
text/plain
multipart/related
text/html
image/png (inline, Content-ID)
application/pdf (attachment)The outer multipart/mixed holds the readable message and the attachments. Inside it, multipart/alternative gives the client a choice between plain text and HTML, and multipart/related ties the HTML to any inline images. Most platforms and libraries build this for you. Understanding it helps when something looks wrong.
How big is a message really?
Binary files cannot travel through the old text-based transport directly, so they are encoded, most often with base64. Base64 turns every three bytes into four characters, so the encoded data is about 33 percent larger, and line breaks add a little more. Headers and the message body add to that.
| File size | Approximate encoded size | Comment |
|---|---|---|
| 1 MB | About 1.35 MB | Small and normally fine |
| 5 MB | About 6.7 MB | Still acceptable to most providers |
| 10 MB | About 13.5 MB | Near the limits of some systems |
| 20 MB | About 27 MB | Likely to exceed common limits |
The figures are estimates from the base64 ratio. Real limits are set by each receiver and by your sending platform, so check the numbers for both. Receivers can accept or refuse a large message at the start of the SMTP conversation if they support the SIZE extension, defined in RFC 1870, which lets the sender announce the size first.
Think in the receiver's limit, not yours. Your platform may accept a large message and the recipient server may still refuse it. When that happens you will see a bounce with a size-related reply such as 552. See SMTP bounce codes explained.
Attach or link?
| Situation | Better choice | Reason |
|---|---|---|
| Small invoice or ticket as a PDF | Attach | Expected by the reader; useful offline |
| Large report, video or archive | Link | Avoids size limits and blocked types |
| Optional extra material | Link | Keeps the message light |
| File that must be controlled or expire | Link to an authenticated page | You can revoke access and track downloads |
| Legally important document | Attach and link | The reader gets a copy, and you keep a record |
Linking has trade-offs. The reader needs a connection, links can expire, and links in transactional mail must be safe, as discussed in authentication email best practices. For content considerations, see email content and spam filters.
Images
- Hosted images. Reference an HTTPS URL on a domain you control. This keeps messages small. Recipients whose apps block images by default will see blanks, so set alt text and dimensions.
- Embedded images. Attach the image as an inline part and reference it by Content-ID. The image displays without a download, but the message grows, and some clients show embedded images as attachments.
- Size. Compress images and serve them at the display size. A photograph straight from a camera can be many megabytes.
- Formats. Use common formats such as PNG, JPEG and GIF. Support for newer formats varies between mail apps.
Character encoding
Text outside basic ASCII, such as accented letters, Indian-language scripts, currency symbols and emoji, needs correct encoding. The safe default is UTF-8, declared in the Content-Type header of each text part, with a transfer encoding such as quoted-printable or base64 where needed.
| Problem | Cause | Fix |
|---|---|---|
| Accented letters appear as question marks or odd symbols | Wrong or missing charset | Declare charset=UTF-8 and encode the body in UTF-8 |
| Subject shows garbled text | Non-ASCII subject sent as raw bytes | Encode the header as defined in RFC 2047 (library functions do this) |
| Sender name with accents breaks | Display name not encoded | Encode the display name, keep the address ASCII or use a standards-based internationalised form |
| Lines cut or lost | Lines longer than allowed | Wrap lines; the standard limit is 998 characters, with 78 recommended |
| Emoji missing in a subject | Client or encoding limits | Test subjects in the main mail apps |
Use your language email library to build messages and avoid assembling headers by hand. Hand-built messages are the usual source of encoding errors, header injection mistakes and structural bugs.
File names and types
- Set the correct media type for each attachment, such as application/pdf, and a matching file extension.
- Use a simple file name with letters, digits, hyphens and a correct extension. Avoid unusual characters and very long names.
- Do not send executables, scripts or macro-enabled files. They are often blocked and raise suspicion.
- Avoid password-protected archives for routine mail. They hide content from scanners and look like malware delivery.
- Keep the number of attachments small.
Sending through SMTP or an API
How you pass attachments depends on your method. With SMTP your library assembles the MIME message and sends it. With an HTTP API you usually pass attachments as encoded data or references inside a JSON request, and the platform builds the message. In that case, request size limits apply to the JSON body as well, and the encoding may be applied twice, once for JSON and once for the email. Check your platform reference for how it accepts attachments and what its limits are, and read SMTP versus API if you are choosing between them.
A worked example: invoices that bounce for one customer
A company emails monthly invoices as PDFs. Most arrive, but one customer never receives theirs, and the bounce says the message is too large. The invoice file is 14 MB because it contains an uncompressed scan of a purchase order. After base64 encoding and headers, the message is about 19 MB, and the customer mail server limit is lower. Other customers use larger limits, so nobody noticed.
The team changes the process. The PDF generator compresses images and keeps invoices under 2 MB. For rare large documents, the email contains a link to an authenticated download page. The system also records the message size and warns when it passes a threshold. The company sees no more size bounces, and customers whose mail servers have strict limits get their invoices. The example is illustrative.
Testing checklist
- Check the full message size, not just the file size.
- View the message source and confirm the structure, charset and content types.
- Open the message in webmail and in a desktop client, on mobile as well.
- Test with and without images loaded.
- Send to accounts at the main providers your audience uses.
- Look at bounces for size-related replies, and handle them by reducing size or linking.
Seeing size or encoding errors you cannot explain? Send us the bounce text and the message source (without personal data) and we will take a look.
Further reading and sources
Frequently asked questions
What is the maximum size of an email?
There is no single limit. Each receiving provider sets its own, and your sending platform sets another. Large providers commonly accept messages in the tens of megabytes, with around 25 MB often seen, but you should check the current figures for the providers you care about and keep messages much smaller.
Why is my 20 MB file too big?
Attachments are encoded as text, usually with base64, which makes them about one third larger. A 20 MB file becomes roughly 27 MB on the wire, before headers and the message body are added.
What does error 552 mean?
It is the SMTP reply for exceeded storage allocation or message size. The receiving server refused the message because it is larger than it accepts or because the mailbox cannot hold it. Reduce the size or send a link.
What is MIME?
Multipurpose Internet Mail Extensions. It is the set of rules that lets an email carry more than plain ASCII text: multiple parts, attachments, images and other character sets. A modern message is almost always a MIME message.
Should I embed images or link to them?
Linking to images on your own HTTPS domain keeps messages small and is the common choice. Embedding with a content ID makes images appear without a download, but increases size and some clients handle it poorly. Small logos are the usual exception.
Why do accents and symbols turn into strange characters?
The text was encoded in one character set and read in another, or a header with non-ASCII characters was not encoded properly. Use UTF-8 for the body, declare it, and encode non-ASCII header values according to the standard.
Are some attachment types blocked?
Yes. Providers commonly block or quarantine executable files and some archive types, and may warn about macro-enabled documents. Avoid unusual types, and link to a download page where you can add checks.
Is there a limit on the number of recipients?
Yes, and it varies. Platforms and receivers limit recipients per message and messages per period. Check your platform documentation and prefer separate messages for bulk sends so each recipient receives only their own copy.
Why should I send both HTML and plain text?
Some readers, previews and accessibility tools use plain text, and filters may view a missing text part as unusual. A multipart/alternative message carries both so the client can choose.