Plain text vs HTML email: the real answer is both

Every campaign we send is one message with two bodies: a multipart/alternative envelope carrying a full HTML part and a real plain-text part. That is the honest answer to "plain text vs HTML email," and it has been the correct answer since MIME standardized the mechanism in 1996. The interesting questions are why HTML-only mail gets punished, why most "plain text" newsletters are secretly HTML, and where genuinely plain mail still wins.

You have three options

The versus framing hides an option, and the hidden option is the right one.

This piece is about what the message is made of. If you are still building the list and the domain it comes from, that is the newsletter-on-your-own-domain guide; come back when something is ready to send.

Why HTML-only mail is a spam signal

SpamAssassin, the open-source filter that a lot of commercial filtering descends from, ships a rule literally named MIME_HTML_ONLY: the message has an HTML part and no plain-text alternative. The rule exists because it separates populations. Real mailing software emits both parts by default, so a missing text part correlates with hand-rolled spam scripts and rushed tooling. The score is small on its own, but spam filtering is cumulative, and this particular point is free to not concede.

The text part has to be real to help. A text/plain part that says "Please view this email in an HTML-capable client" hands back everything the fix bought, because filters read that part too. Generate it from the same content as the HTML: same words, same links, no markup. Our composer does exactly this on every campaign, alongside the rest of the content hygiene our playbook enforces: a text-to-image ratio of at least 60:40, never image-only mail, no link shorteners, links kept on the sending domain. None of these alone decides your fate; they stack, in both directions, with everything else covered in why emails go to spam.

The fake plain text pattern

Here is the part the versus articles skip: the famous "plain text" newsletters mostly are not plain text. They are HTML dressed as plain text, and email developers have a name for the pattern: fake plain text. The anatomy is consistent. A single column capped around 600 pixels. A system font stack. No images, or one small logo. Underneath: fully tracked links rewritten through a click domain, and a styled footer holding the unsubscribe link.

Senders build this because it keeps the two things HTML is genuinely for, click measurement and typographic control, while borrowing the intimacy of a personal note. You can verify the pattern yourself in about ten seconds: open the next minimal newsletter you receive in Gmail, choose Show original from the three-dot menu, and search the source for text/html. It is almost always there.

We think fake plain text is the right call for most newsletters, and it is what a minimal LetterDuck template is: quiet HTML with a true plain part sitting beside it in the same message. The label is the only dishonest thing about the pattern.

Where actually-plain still wins

Cold outreach. A 90-word text/plain message is structurally identical to mail one human writes to another, which is the entire game when nobody asked to hear from you. A designed HTML template arriving from an unknown domain announces "campaign" before the first word is read. If outreach is your problem, start with what cold email actually is, and keep it off your newsletter domain entirely.

Short transactional mail. A password reset is one sentence and a link. It has to survive every client, every screen reader, and every corporate filter, and there is nothing in it to design. Plain, or a near-plain multipart, is the right weight.

Replies. When we answer a reader from the workspace, the reply goes out as ordinary mail with In-Reply-To and References headers so it threads correctly in their client. No template, no tracking. A conversation is not a campaign.

The multipart mechanics, literally

This is the entire structure, trimmed to its skeleton:

From: The Print Room <hello@yourdomain.com>
To: reader@example.com
Subject: Issue 12: the letterpress that would not die
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="b1"

--b1
Content-Type: text/plain; charset=utf-8

Issue 12: the letterpress that would not die.
Read the illustrated version: https://yourdomain.com/12

--b1
Content-Type: text/html; charset=utf-8

<html><body>
  <h1>Issue 12</h1>
  <p>The letterpress that would not die.</p>
</body></html>

--b1--

Three details carry all the weight. The boundary string separates the parts and closes the message with a trailing double hyphen. Each part is a complete, standalone rendering of the same message. And the order is a rule, not a habit: RFC 2046 (1996) says the parts appear in increasing order of preference and the client renders the best one it supports, which in practice means the last one it can display. Plain first, HTML last. Reverse them and text-capable clients that follow the spec show your readers the plain part.

We live on both sides of this structure. Outbound, the composer emits it. Inbound, every message that reaches a LetterDuck workspace is parsed from the raw RFC822 stream by postal-mime, both parts stored, so malformed multipart is not an abstraction to us; it is a Tuesday.

One practical ceiling while you are in the HTML part: Gmail clips messages above roughly 102KB, a threshold Litmus has documented for years, and a clipped message hides everything below the fold, your unsubscribe link included. Keep the HTML lean and the design restrained; restraint is also what makes the plain part easy to generate.

What to do

For a newsletter: multipart/alternative, always. Generate the text part from the same content and actually read it once before the first send; a stray markdown artifact or a wall of raw URLs tells you the generator needs work.

For cold outreach and one-sentence transactional mail: plain or near-plain.

HTML-only: never. There is no case for it, and one named rule against it.

Before your next send, look at the raw message your tool actually emits. If there is no text/plain part inside it, fix the tool or change tools.