How does email file size and MIME types affect email deliverability?
Published 30 Apr 2025
Updated 9 Oct 2026
16 min read
Summarize with
Updated on 9 Oct 2026: We clarified email size limits, corrected AMP MIME ordering, and added checks for size-related delivery failures.
Email file size affects both message acceptance and recipient experience. Direct delivery failures occur when a message exceeds a provider size limit or contains blocked attachment types. Invalid MIME structure also creates parsing or security-scanning problems. Indirect risk happens when the email still reaches the inbox but loads slowly, gets clipped, hides the unsubscribe link or footer, breaks tracking, or reduces recipient engagement over time.
Keep the HTML body lean, keep each MIME part purposeful, avoid attachments in bulk marketing mail, and test the actual message that goes over the wire. An HTML body near 100 KB is a useful warning line because Gmail commonly clips sent HTML at about 102 KB, but this is not a universal spam-filter cutoff. Modern mailbox providers evaluate sender reputation, authentication, recipient engagement, content patterns, URLs, attachments, MIME structure, and user complaints together.
- Aim for sent HTML under 100 KB, and leave extra room for personalization and tracking additions in recurring campaigns.
- MIME parts: Filters can inspect individual parts and the combined message, so do not treat each part as a separate allowance.
- AMP: A 60 KB HTML part plus a 50 KB AMP part is not automatically blocked, but it increases total message weight and adds validation requirements.
- Attachments: Attached files increase message size and scrutiny. Link to hosted documents for marketing and lifecycle mail instead.
How size affects inbox placement
Email size does not work like a single pass-or-fail number. A small message can still go to spam if authentication is broken or the sending reputation is poor. A large message can still reach the inbox if it fits provider limits, the sender has strong reputation, and the content is wanted. Size matters because it affects whether the message fits delivery limits and how recipients experience the email once it lands.
A practical QA threshold is the sent HTML MIME part. Keep it comfortably under 100 KB because Gmail commonly clips HTML at about 102 KB, which can hide the bottom of the message. This is separate from total message size, which also includes headers, boundaries, encoded bodies, plain text, AMP, inline images, and attachments.
Do not treat 100 KB as a spam line
The 100 KB guideline is mainly useful for clipping and rendering risk. It is not a promise that 99 KB is safe or 101 KB fails. For deliverability, the complete signal set matters: sender reputation, authentication, complaint rate, engagement, URL reputation, MIME validity, attachments, and content history.
|
|
|
|---|---|---|
HTML | <100 KB sent | Clipping and slow rendering |
Plain text | Lean | Mismatch with HTML |
AMP | Under 200,000 bytes of AMP markup | Validation and support |
Remote images | Optimized | Load time and data use |
Attachments | Avoid in bulk marketing | Filtering and limits |
Practical size guidance for common email parts.
HTML size versus total message size
There are at least two size measurements that matter. The first is the size of the HTML source that the email client renders. The second is the message size on the wire, which includes headers, MIME boundaries, transfer encoding, text alternatives, AMP alternatives, inline content, and attachments. Remote images referenced by URL are fetched separately when the client loads them, so their file bytes do not travel inside the SMTP message. Base64 image data URIs add bytes inside the HTML itself, while CID images travel as separate MIME parts. Both increase the total message size.
This is why a campaign can appear fine in a builder but behave differently after sending. The ESP can add headers, tracking URLs, a tracking pixel, unsubscribe headers, link wrapping, analytics parameters, and MIME boundaries. Headers and MIME boundaries increase total message size. Tracking URLs, link wrapping, and pixels added inside the HTML also increase the body size that matters for clipping.
Five MIME layers that contribute to total email message size.
HTML source size
- Where it matters: Clipping, rendering, loading speed, and the visibility of footer content.
- Common bloat: Nested tables, unused CSS, repeated inline styles, hidden mobile blocks, and page-builder comments.
- Best fix: Minify carefully, remove unused modules, and simplify repeated components.
On-the-wire size
- Where it matters: SMTP transfer, provider limits, security scanning, and attachment handling.
- Common bloat: Base64 encoding, attachments, extra MIME alternatives, tracking headers, and embedded images.
- Best fix: Send the final message to a test inbox and inspect the downloaded raw MIME source instead of only the template preview.
How MIME types affect deliverability
MIME (Multipurpose Internet Mail Extensions) identifies each message part through a Content-Type header, such as text/html or application/pdf. A normal marketing email often uses multipart/alternative with a plain text part and an HTML part. Some messages add text/x-amp-html for AMP. Transactional mail can add calendar invites or attachments. Security filters inspect the MIME tree because malformed structure, odd nesting, missing boundaries, suspicious file types, and misleading content types are common in unwanted mail. Use registered media types from IANA's media type registry for known formats.
The mistake is thinking of MIME parts as independent size budgets. If a message has 60 KB of HTML and 50 KB of AMP, the recipient does not see both at once, but the receiving system receives both. The combined weight, plus headers and encoding, counts toward total message size. The HTML part can still clip in Gmail if that part crosses the clipping threshold, and the total message still has to fit sender and recipient message-size limits.
Multipart ordering example with body placeholderstext
MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="b1" --b1 Content-Type: text/plain; charset="UTF-8" [Plain text version of the message] --b1 Content-Type: text/x-amp-html; charset="UTF-8" [Complete, validated AMP document for the same message] --b1 Content-Type: text/html; charset="UTF-8" [HTML fallback for the same message] --b1--
Place the AMP part before the HTML part, with plain text first, following the AMP MIME structure guidance. This keeps HTML last for clients that select the final supported alternative. The example shows MIME ordering only; replace the body placeholders with complete content before sending.
AMP adds requirements beyond file size. The AMP for Email specification limits AMP markup to 200,000 bytes. Include at least one non-AMP fallback and keep a complete HTML version. Gmail requires production senders to register each sending address; its registration guidelines call for SPF, DKIM, and DMARC. Its AMP security requirements explicitly require passing SPF and DKIM, with the DKIM signing domain matching the visible From address at the organizational-domain level. A DMARC quarantine or reject policy is recommended there. A client that cannot display the AMP part falls back to a supported alternative, so test both render paths.
The safer AMP rule
Treat AMP as an extra experience layer, not a required part of every send. Include it only when it adds measurable value, keep a complete HTML fallback, meet the receiving provider's sender requirements, and validate the final MIME structure before production.
Build a valid MIME tree
Correct MIME nesting helps clients select the intended body and helps scanners classify every part. Use multipart/alternative for equivalent versions of the same content, usually plain text followed by HTML. Use multipart/related to group HTML with CID-referenced inline assets, and use multipart/mixed as the outer container when independent attachments are present. Each CID image needs a Content-ID matching its HTML cid: reference.
Common MIME nesting with inline images and an attachmenttext
multipart/mixed ├── multipart/alternative │ ├── text/plain │ └── multipart/related │ ├── text/html │ └── image/png (Content-ID matching the HTML cid: reference) └── application/pdf Content-Disposition: attachment; filename="receipt.pdf" Content-Transfer-Encoding: base64
- Keep alternatives equivalent: The plain text, HTML, and AMP parts should communicate the same message rather than hide unrelated content.
- Declare every part accurately: Match Content-Type to the real file format and set Content-Disposition to inline or attachment when the intended handling matters. Include a descriptive attachment filename. Use application/octet-stream for unidentified binary content rather than for known formats.
- Validate boundaries and closing markers: Use a different boundary for each nested multipart container and preserve its final closing marker. Boundary collisions can make later parts unreadable and create ambiguous scanner results.
- Inspect the delivered tree: Forwarding, gateways, and the sending platform can rewrite or remove parts after the template leaves the editor.
Clipping is not the same as spam
Gmail clipping is often confused with a deliverability failure. It is usually a rendering and measurement problem, not an inbox placement problem. The message can land in the inbox, but Gmail displays a clipped version and asks the recipient to view the full message. If the unsubscribe link, legal footer, discount terms, or open tracking pixel sits below the clipping point, the campaign can look worse than it performed.
This matters because many open pixels are injected near the end of the HTML. When the bottom of the email does not render, the pixel can fail to load. That makes opens look lower, which can be misread as spam placement. The right response is to check inbox placement, click behavior, complaint rate, and delivered source size before treating the issue as reputation damage.
Illustrative HTML size QA bands
Editorial QA targets for sent HTML, not documented provider limits. Leave room below Gmail's approximate 102 KB clipping point.
Lean
0-60 KB
Low clipping risk for most campaign templates.
Watch
>60 to <100 KB
Review repeated CSS, modules, and tracking additions.
Clip risk
100 to <150 KB
Gmail clipping becomes a practical concern.
Heavy
150 KB+
Prioritize size reduction and rendering tests; size alone does not determine spam placement.
Send the real campaign to a test inbox and inspect the message to investigate clipping. Suped's public email tester helps review authentication and received-message headers before a broader send. Confirm clipping in Gmail itself.
Email tester
Send a real email to this address. Suped shows a results button when the test is ready.
?/43tests passed
Attachments and risky content types
Attachments change the risk profile more than normal hosted images. They increase total size, require content scanning, and can trigger stricter handling when the file type is commonly abused. PDFs are common in transactional workflows, but avoid them in marketing campaigns unless the recipient explicitly expects the file.
File type also matters. A PDF invoice sent after a purchase has a different context than a cold email with a compressed archive. Recipient policies restrict executables and scripts, and apply additional checks to macro-enabled documents and encrypted archives. Gmail also blocks restricted file types inside compressed archives, as its blocked attachment policy explains. Renaming a file or changing its declared MIME type does not change its content. Even allowed files can hurt engagement if the message takes too long to load or creates suspicion. Some limits count the encoded message, while others specify attachment bytes before encoding; check the definition for the actual sending route.
|
|
|
|---|---|---|
text/html | Campaign body | HTML size and rendering |
text/plain | Text alternative | Meaningful content matching HTML |
text/x-amp-html | Interactive mail | Markup validation and provider support |
application/pdf | Expected receipt or document | Recipient policy and encoded size |
application/zip | Packaged files | Contained file types and inspection policy |
text/csv | Data export | Correct charset and recipient policy |
text/calendar | Calendar invitation | Valid calendar content and client support |
Common email MIME types and the checks they need.
Avoid bulk attachments
For promotional mail, hosted assets are usually safer than attachments. If a document is needed, link to a landing page that explains the document, uses HTTPS, and matches the brand domain. Keep the email focused on the action, not the file. Test the final tracked download URL and access permissions, because hosted links and downloaded files are also scanned.
Attachment size limits and delivery errors
Attachment size limits depend on the sending service, recipient server, and administrator policy. Personal Gmail accounts allow up to 25 MB of attachments; work and school accounts follow administrator settings. Google documents these distinctions in its Gmail attachment limits. This attachment allowance is separate from HTML clipping. A receiving server or corporate gateway can impose a lower maximum message size than the sending service.
- Check whether each limit covers raw attachments or the complete encoded message, including every MIME part and header.
- Measure the final .eml file in bytes after tracking rewrites and transfer encoding. Leave room for headers added by downstream gateways.
- Read the bounce or non-delivery report. A response such as 552 5.3.4 indicates a permanent message-size rejection; RFC 3463 defines 5.3.4 as a message too big for the receiving system.
- Reduce the message or replace the attachment with an accessible hosted download before resending. Repeating an unchanged oversized message does not resolve a permanent size rejection.
Check the final delivery result
A successful sending API response usually means the sending service accepted or queued the request. Check subsequent delivery events for recipient-server rejection or scanning delays. SMTP acceptance confirms server receipt, while inbox placement and attachment availability need separate checks.
Encoding and HTML quality
Encoding changes the size that receivers process. Base64 adds about 33% to the original binary payload before line wrapping and MIME headers, so a 7.5 MB file consumes roughly 10 MB before the remaining message parts are counted. Quoted-printable can also add overhead, especially when HTML has many long lines or special characters. UTF-8 is normal and safe when declared correctly, but the final wire size still needs to be measured. This 33% estimate excludes line wrapping, so a 7.5 MB attachment is already too large for a strict 10 MB total-message cap once the extra overhead is counted. Microsoft explains the encoding allowance in its attachment size guidance.
Use base64 for binary attachments and quoted-printable for mostly ASCII text. Content-Transfer-Encoding is a separate per-part header, not a Content-Type parameter. Both encodings require output lines no longer than 76 characters, excluding the line ending, under RFC 2045. Let a MIME library handle encoding and CRLF line endings; do not minify the raw encoded message into one long line.
HTML quality also matters. Malformed tags, broken conditional comments, unclosed tables, excessive hidden content, and CSS that changes tracking pixels or spacer images can cause inconsistent rendering. Size is often a symptom of this problem. Bloated templates usually have more code paths that can fail across clients. Image-heavy messages should also include meaningful live text rather than placing the entire offer inside images.
Problem patternhtml
<style> @media screen and (max-width:600px) { img { width:300px !important; height:auto !important; } } </style> <img src="open.gif" width="1" height="1" alt="">
That kind of broad CSS can accidentally resize a 1 by 1 tracking pixel or spacer image. When the pixel is placed at the top, the break is visible. When it is placed at the bottom, it is less likely to damage the first impression, but it can still affect measurement if clipping occurs.
If you are dealing with heavy image campaigns, this related guide on image file size is a useful next read because remote images affect load speed even though their file bytes are not part of the HTML source or SMTP payload.
A practical testing workflow
A reliable workflow starts with the final message, not the template. Build tools, ESP previews, and local HTML files do not include every header, MIME boundary, tracking rewrite, and encoding decision that appears in the real sent email.
- Send the final email: Use the same ESP, sender domain, suppression logic, personalization, and tracking settings planned for production.
- Inspect the delivered source: Download the raw MIME source using Gmail's "Show original" or the equivalent client command. Check decoded HTML bytes separately from the full .eml file, MIME boundaries, Content-Transfer-Encoding, and attachment handling.
- Check provider behavior: Review Gmail clipping, Outlook rendering, mobile rendering, and which fallback appears when AMP is unavailable.
- Confirm authentication: Check SPF and DKIM results, then confirm that at least one passing method has the required domain match with the visible From address for DMARC.
- Watch reputation signals: Monitor complaints, bounces, clicks, and domain reputation after changes. Treat open rates as supporting data rather than proof of inbox placement.
Suped DMARC dashboard showing email volume, authentication health, and source breakdown
Suped fits this workflow when the question moves beyond one message and into sender authentication. Its DMARC monitoring connects reported SPF and DKIM results to sending sources, so teams can investigate DMARC failures or unauthorized sources alongside content testing.
For broad domain checks, Suped also has a domain health checker that reviews DMARC, SPF, and DKIM records before teams spend time debugging content. DNS checks do not establish whether a particular message passed authentication; inspect the received headers too.
?
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
How to reduce size without breaking the email
Reducing size requires more than minification. The best savings usually come from design and template discipline. Repeated modules, duplicated mobile and desktop sections, page-builder markup, verbose inline CSS, and unused conditional code are common sources of template weight.
Keep
- Core content: Copy, buttons, pricing, product details, and required legal content.
- Useful fallback: A plain text part that matches the message and does not include stale copy.
- Targeted AMP: AMP only where it adds measurable value and the sender meets provider requirements.
Remove
- Unused CSS: Rules left behind by old modules, abandoned layouts, or builder defaults.
- Duplicate sections: Separate desktop and mobile content blocks when responsive code can handle both.
- Bulk files: Attachments, embedded images, and base64 image data in campaign bodies.
Avoid aggressive HTML compression that makes QA harder or changes how email clients parse conditional comments. Preserve the code needed for rendering while reducing size. Test after each meaningful change and compare the final delivered source.
Best working rule
Remove sections that do not help the recipient understand the message or take action before using technical compression. A shorter HTML body reduces clipping risk; compare the final sent size and rendering after each change.
Where Suped fits
Suped is our DMARC reporting and email authentication platform. It helps teams investigate authentication failures and unfamiliar sending sources alongside blocklist (blacklist) checks. DMARC aggregate reports describe authentication results and policy handling; they do not contain HTML byte counts, MIME trees, or proof of inbox placement.
Test heavy campaigns before sending, then use Suped to review authentication across reported mail streams. Investigate SPF or DKIM failures after an ESP change and confirm whether new sending sources are authorized. Use message tests and sending logs to diagnose size-related failures.
Issue steps to fix dialog showing the issue overview, tailored fix steps, and verification action
- Automated issue detection: Flags reported authentication failures or unfamiliar sending sources for investigation alongside campaign tests.
- Hosted SPF and DMARC: Helpful when many senders or DNS handoffs make record management slow.
- Authentication alerts: Support investigation as receiver reports arrive. Use sending logs to establish the timing of delivery errors.
- Blocklist monitoring: Keeps domain and IP blacklist checks close to authentication data instead of scattering investigations.
Views from the trenches
Best practices
Measure final sent source, including MIME boundaries, headers, tracking, and encoding overhead.
Keep AMP targeted to cases where provider support and performance justify the added part.
Place required footer and unsubscribe content above likely clipping points in large templates.
Common pitfalls
Teams confuse Gmail clipping with spam placement and start fixing the wrong deliverability issue.
Tracking pixels near the bottom underreport opens when clipped messages do not load the footer.
Broad mobile CSS rules can resize small tracking pixels or spacer images into visible artifacts.
Expert tips
Compare opens within the same ESP and sender, but use clicks and complaints for stronger signals.
Keep the AMP MIME part before HTML, and test the complete fallback in clients without AMP support.
Use 100 KB as an HTML QA warning; investigate encoded-message limits and authentication separately.
Marketer view
Marketer from Email Geeks says messages over 100 KB are often clipped in Gmail, which affects rendering and analytics more than inbox placement.
2024-09-17 - Email Geeks
Marketer view
Marketer from Email Geeks says clipped messages can hide the open tracking pixel, so lower open rates can be misread as a delivery issue.
2024-09-17 - Email Geeks
