The missing plain-text part is real — and smaller than you think.

/ TL;DR

/ 01

What MIME and multipart are

Plain email was originally just ASCII text. MIME — Multipurpose Internet Mail Extensions — is the standard that extended it to carry everything else: other character sets, formatting, images, attachments, and multiple versions of a message in one envelope. Nearly every email you send today is a MIME message, whether or not you ever think about it.

The piece that matters for marketing and transactional mail is multipart/alternative. It lets a single email contain more than one rendering of the same content — in practice a text/plain version and a text/html version — and leaves it to the receiving client to choose which to show. A client that can render HTML displays the HTML; one that can't, or a user who prefers text, sees the plain version instead. Both are present; the recipient only ever sees one.

The idea was practical from the start: guarantee a readable message regardless of what the recipient's software could do. That original rationale — some clients simply couldn't display HTML — matters less now that almost everything can. What survives is a set of smaller reasons the text part still earns its place, and a set of much larger content factors that decide placement no matter how your parts are arranged.

/ 02

Anatomy of a message

A multipart/alternative message is simpler than it looks. An outer header declares the type and a boundary string, then each version appears as a part introduced by that boundary, with its own content type and encoding:

A few details in there carry weight. The order is significant: the standard says parts go in increasing order of preference, so the plain-text part comes first and the HTML part last, and a capable client renders the last part it understands. The boundary can be any unique string — random or a UUID is conventional — and the same string marks every part, with a trailing -- closing the block.

The Content-Transfer-Encoding — usually quoted-printable or base64 — describes how each part's bytes are packaged so they survive transport intact, and the charset declares the character encoding. You rarely write this by hand — your platform assembles it — but recognizing the shape lets you read a raw message and see whether both parts are present and sensible. Our email header analyzer lays this structure out for a real message so you don't have to parse it by eye.

/ 03

Alternative, mixed, related

"Multipart" isn't one thing — there are several multipart types, and confusing them is behind a lot of "why does my attachment render inside the body" head-scratching. Three matter for email:

multipart/alternative holds different versions of the same content, and the client picks one to show — this is the text-plus-HTML case above. multipart/mixed holds different, independent parts that are all meant to be presented together, most often a message body plus attachments. multipart/related holds an HTML part together with resources it references — inline images embedded in the message and pulled in by a content ID rather than downloaded from a URL.

Real messages nest these. An email with both text and HTML bodies and a PDF attached is typically an outer multipart/mixed wrapping a multipart/alternative — the alternative holding the two body versions, the mixed adding the attachment beside it. Add inline images and a multipart/related joins the nesting. You don't assemble this tree yourself, but understanding it explains a great deal: why an inline logo shows in one client and appears as an attachment in another, or why a raw message looks so deeply structured. The one to get right deliberately is the alternative layer — the text-and-HTML pairing filters and clients care about most.

/ 04

What HTML-only costs

Let's be precise about the actual penalty, because it's both real and frequently overstated. An HTML-only message — HTML part, no text part — trips a specific SpamAssassin rule, MIME_HTML_ONLY, which adds a small fixed amount to the message's spam score. That contribution is minor on its own; it matters only when you're already close to the threshold from other problems, at which point a small addition can tip you over.

There's a companion trap worth naming. If you "add a text part" that only says something like this email is best viewed in HTML, filters treat it as no text part at all — a separate rule scores the placeholder the same as an absence. So a token text part earns you nothing; the part has to be a genuine, readable rendering of the message to count. Half-measures here are indistinguishable from doing nothing.

Beyond the score, HTML-only forfeits the practical fallbacks: the readers on text-only or older clients, the security configurations that strip HTML, the screen readers and mobile notification previews that reach for the text. None of those is large by itself, and together they still don't add up to a make-or-break factor. The honest summary: HTML-only is a minor negative that accumulates with others rather than a standalone cause of the spam folder — the point most guides skip.

/ 05

Not a magic bullet

Here's the part a lot of advice won't tell you plainly: the plain-text part is nowhere near as decisive as its reputation suggests, and its influence has faded further every year. The rule that HTML-only mail is penalized dates from an era when spam filtering leaned heavily on parsing message structure. Filtering has moved on. In 2026 the major receivers run machine-learning systems weighing dozens of signals at once, and a clean, well-coded HTML email from a sender with good standing lands in the inbox with or without a text part.

What decides placement is the same short list it always comes back to: sender reputation, authentication with SPF, DKIM, and DMARC, recipient engagement, and the quality of your list. Those factors dwarf the format question. A sender with a strong reputation and clean authentication has enormous latitude in how they format mail; a sender with a poor reputation won't be saved by a perfectly-formed text part. The format is a rounding error next to who you are and how people respond to you.

This isn't an argument for dropping the text part — it's an argument for right-sizing it. Include it, because it's cheap and it does help at the margins. But if you're chasing an inbox-placement problem, the plain-text part is close to the last place to look. Spend the time on your reputation, your authentication, and your list hygiene first, and treat MIME structure as hygiene you fix once and forget.

/ 06

What actually hurts

If the text part is a rounding error, the content problems that share its neighborhood are not — and they're the ones worth your attention. The biggest is the image-only email: a message that's one big image with almost no real text. Filters can't read what's inside an image the way they read text, so an image-only message denies them the content they need to judge it, and they treat that opacity as suspicious. The close relative is a poor image-to-text ratio — lots of images, little text — which raises the same flag to a lesser degree.

Then there's the HTML itself. Broken or sloppy markup — unclosed tags, tangled nesting, bloated inline CSS — reads as low-quality or machine-generated and can nudge filtering the wrong way, quite apart from rendering badly across clients. Too many links, especially to many different domains, is another content-level trigger. These are all things a text part does nothing to offset; they live in the HTML and the design.

And there's the failure that hides inside the fix itself: a divergent or garbage plain-text part. When the text version is auto-generated badly — bold text flattened to ALL CAPS, which some filters read as shouting, or content stripped into disjointed fragments — it can read as low quality, and when it says something materially different from the HTML, that mismatch between the two halves is itself a signal filters learned to distrust. A careless text part can be marginally worse than none — the irony of treating it as a box to tick.

/ 07

What to actually do

The practical routine is short and mostly one-time. Send multipart/alternative with a real text part and an HTML part — nearly every sending platform does this by default, so the job is usually to confirm it's happening rather than to build it. Then, because auto-generation is where it goes wrong, read the generated text part once for a representative template: check that it's a coherent rendering of the HTML, not fragments or shouting, that it carries the same content and offer, and that its links are the same HTTPS destinations as the HTML.

On the HTML side, keep the markup clean, keep a healthy amount of real text alongside your images rather than shipping a single graphic, and keep your link count and destinations reasonable. That handful of habits clears essentially all of the structure-and-content risk. Everything past it is reputation, authentication, and list quality — the factors that actually decide placement, and where any remaining effort belongs.

When you want to see what a receiver sees, inspect a real message: our email header analyzer shows the MIME structure, whether both parts are present, and how the message is put together, and the why emails go to spam guide covers the content signals that outrank format. Getting structure right once and then keeping the factors that matter healthy as you scale is the standing operation we run.

/ 08 — FAQ