Plain Text vs HTML Email: Which Lands in the Inbox?

There's a stubborn myth in cold email that "HTML kills deliverability." It's close enough to be useful and wrong enough to be misleading. The format tag on your message isn't the problem. What you stuff inside the HTML is.

This guide stays on one narrow axis: message format and HTML weight, and how filters score it. If you want the full set of spam-filter tactics, read the canon guide on how to avoid spam filters. If you want to know how Gmail and Outlook's machine-learning classifiers think, that's covered in beating AI spam filters. Here we're answering the specific question: when it comes to plain text vs HTML email deliverability, which one actually lands?

The short answer

For cold outreach, send plain text or stripped-down HTML that reads like plain text. Reserve heavy HTML, columns, hero images, and button arrays for opt-in newsletters where recipients already know you.

That's not because filters hate HTML. It's because the things people put in HTML cold emails, images, tracking pixels, multiple links, styled buttons, and hidden formatting, are the same signals filters associate with bulk promotional mail. A first-touch message to a stranger should look like one human typed it to one person. Plain text gets you there by default. Minimal HTML can match it if you're disciplined.

Hunter analyzed 2.2 million cold emails its users sent in 2025 and found HTML messages bounced far more than plain text ones. They were upfront that it wasn't a controlled A/B test, so confounding variables are in play. Still, the direction is consistent with everything filters are built to detect.

Plain text vs HTML email deliverability: what filters actually score

Let's look at the mechanism instead of the folklore. SpamAssassin is open source, and its rule definitions are public, which makes it the clearest window into how content-based filters assign points. Commercial filters at Gmail and Microsoft are proprietary and ML-driven, but they react to the same underlying signals.

Here's the first thing that surprises people. The rule that simply detects HTML in a message, HTML_MESSAGE, carries a default score of about 0.001 points in Apache SpamAssassin's published rule set. That's effectively zero. HTML on its own is a non-event. A spam verdict typically needs a total score of 5.0 or higher, so 0.001 is noise.

The points come from what the HTML contains. These are the rules that matter for cold senders:

Read that list again. Not one of those rules punishes formatting like bold text or a hyperlink. Every one of them punishes a specific abuse: HTML with no text fallback, layouts that are mostly image, or text hidden by making it the same color as the background. Spammers do all three to dodge text-based filtering. When you do them too, even innocently, you collect the same penalty.

MIME_HTML_ONLY alone can score north of 2 points in some of SpamAssassin's scoresets. That's a meaningful chunk of a 5.0 spam threshold, and it triggers for one reason: you sent HTML without a plain-text version. We'll fix that in the multipart section below.

So the honest framing isn't "plain text good, HTML bad." It's this: plain text is penalty-proof because it has nothing to score. HTML is fine until its contents start matching the patterns filters were trained to catch.

It isn't that HTML is banned. It's weight and intent.

Two cold emails can both be "HTML" and land in completely different folders.

The first is a single paragraph of text with one hyperlink, sent as HTML with a matching plain-text part. To a filter, that's indistinguishable from plain text. It carries no images, no tracking pixel, no color tricks, no MIME_HTML_ONLY penalty. It reads like a person wrote it.

The second is a 600-pixel-wide template with a logo header, a hero image, a colored call-to-action button, a footer with social icons, and a tracking pixel. Every one of those elements is a signal that this came from a sending platform, not a colleague. Filters notice, and so do recipients. People delete designed cold emails faster because the design itself announces "this is a pitch."

Intent leaks through structure. A real one-to-one email almost never contains a banner image. When yours does, you've told the filter what kind of mail this is before it reads a single word. That's the core of plain text vs HTML email deliverability: the format is a proxy for intent, and intent is what gets scored.

Do images hurt cold email deliverability?

Mostly yes, for cold first touches. Not because an image is inherently spammy, but because of three knock-on effects.

Image-only and image-heavy layouts trigger real rules. As the table above shows, SpamAssassin has a whole family of HTML_IMAGE_ONLY and HTML_IMAGE_RATIO rules that fire when there's lots of image and little text. A cold email built mostly from a graphic is exactly the shape those rules hunt for.

Remote images get blocked or hidden, which breaks your message and your tracking. Around mid-2024, Gmail started showing more recipients a banner reading that images in the message are hidden and the message might be suspicious. When that fires, your visuals don't load until the recipient manually clicks to show them, and most won't. Your carefully placed image becomes a broken gap.

Tracking pixels are images too, and they're the riskiest image of all. An open-tracking pixel is a tiny remote image whose only job is to phone home. Privacy systems have made it nearly useless and occasionally harmful. Apple's Mail Privacy Protection downloads remote content in the background when the message arrives and hides the recipient's IP address, so opens register whether or not anyone read the email. Gmail proxies and caches images through its own servers. The data you get is noise, and the pixel itself is one more remote-content flag on a message that should have none.

The practical rule: no images and no open tracking on the first cold email. If you need a logo for brand recognition, save it for later replies in a warm thread, or put it in your signature as a small, hosted, single image, not a banner. Measure replies and booked meetings instead of opens. Open rate as a metric is already unreliable, which is why the metrics that actually matter lean on responses, not pixel fires.

Text-to-image ratio and spam filters

People love to repeat a magic number here, usually "60 percent text, 40 percent image." Treat that as a rough guardrail, not a law. SpamAssassin doesn't have a rule called "you violated 60/40." It has graduated rules, HTML_IMAGE_RATIO_02, _04, _06 and the rest, that add points as the proportion of image area to text area climbs. There's no single cliff. The score builds as your message gets more image and less text.

For cold email, the useful version of the rule is simpler: get the ratio as close to "all text" as you reasonably can. You're not balancing a newsletter's aesthetics against a ratio threshold. You're sending a personal note. A personal note is words. If your text-to-image ratio is a concern at all, you already have too many images for a first touch.

One more trap lives in this neighborhood. Don't try to game the ratio by padding your HTML with white-on-white text or a wall of invisible characters to "balance out" an image. That's exactly what HTML_FONT_LOW_CONTRAST catches, and Google's sender guidelines explicitly warn against using HTML or CSS to hide content. Hidden text is a classic spam tactic, so filters score it hard. The fix for a bad ratio is fewer images, never more hidden text.

Minimal HTML cold email formatting that's safe

You don't have to send raw, unstyled plain text to be safe. You have to keep HTML light enough that none of the penalty rules fire. Here's what's fine and what isn't for a cold first touch.

Safe to use:

• Short paragraphs with normal line breaks
• One hyperlink, with visible, sensible anchor text (Google's guidelines ask that links be easy to understand)
• Occasional bold for a single key phrase, used sparingly
• A simple text signature with name, title, and company
• A plain-text alternative part attached to the message

Skip on the first email:

• Hero images, logos, and banners
• Styled buttons and colored call-to-action blocks
• Background colors and custom fonts
• Multiple links and social-icon footers
• Open-tracking pixels
• Columns, tables for layout, and anything that needs a template builder

The mental test: would this exact message look weird if a coworker sent it to you? A bold word is fine. A purple button is not. Your goal is a message that's technically HTML but visually and structurally indistinguishable from something a human typed in their own client.

This is also where the right tooling helps. MailBeast keeps cold sends in a lightweight format and sends a proper multipart message by default, so you get the safety of plain text without hand-editing MIME parts. The point isn't the tool, though. It's the discipline: strip the message down until there's nothing left for a filter to score.

The multipart/alternative structure, and why you send both

Here's the part most "just send plain text" advice skips. The best-practice format isn't text-only. It's a multipart/alternative message that carries both a plain-text part and an HTML part. The receiving client picks one.

This is defined in RFC 2046, section 5.1.4. The sender places the body parts "in increasing order of preference, that is, with the preferred format last," and "receiving user agents should pick and display the last format they are capable of displaying." In plain terms: put text/plain first, text/html last. A modern client renders the HTML. A stripped-down or legacy client falls back to text. Nobody gets a broken message.

Why bother sending HTML at all if it's minimal? Two reasons. First, sending HTML-only with no text part is what triggers MIME_HTML_ONLY, the 2-point penalty we flagged earlier. A plain-text alternative makes that rule moot. Second, deliverability practitioners at Word to the Wise point out that almost every client today supports HTML, so in practice the recipient sees your HTML part anyway. The text part is insurance and a filter-friendly signal, not the version most people read.

So the durable answer to plain text vs HTML email deliverability is a small twist on the popular advice. Don't send HTML-only. Don't send a heavy template. Send a multipart message whose HTML half is so light it's basically plain text with a hyperlink, backed by a real text part. You get clean rendering everywhere and no format penalties.

A quick format decision table

The pattern is consistent. The colder and earlier the contact, the closer to plain text you stay. As the relationship warms, you earn room to add formatting. You never start with the template.

How to confirm your format actually lands

Don't guess. Test the exact message you plan to send. The cleanest way is a seed-list placement test across Gmail, Outlook, and Yahoo, which shows you inbox-versus-spam placement for that specific content before you mail real prospects. The full method is in our guide to inbox placement testing with a seed list.

Two more checks worth building into your routine:

• Run the message through a SpamAssassin scorer and read which rules fired. If you see anything in the HTML_IMAGE or MIME_HTML_ONLY family, you know exactly what to cut.
• Watch your Gmail-side reputation over time in Google Postmaster Tools. Format problems show up as rising spam rates and falling reputation, not as a single bounce.

If placement is already poor, format is only one suspect. Work through the full email deliverability audit before you blame the HTML, because authentication, list quality, and spam traps sink more campaigns than formatting ever does.

Common questions

Is plain text always better than HTML for cold email?

For the first touch, effectively yes, because plain text has nothing for a content filter to score and it reads like a personal note. But "plain text" and "lightweight multipart HTML with a text part" are nearly identical to a filter. The thing to avoid is heavy, image-laden, template-built HTML, not the HTML format itself.

Does adding a single image really send me to spam?

One small image won't single-handedly spam you, but it nudges several risk signals at once: it lowers your text-to-image ratio, adds remote content that Gmail may hide, and looks less personal. On a cold first email the upside is tiny and the downside is real, so the safe default is no images until the recipient has engaged.

Should I turn off open tracking?

On cold first touches, yes. The tracking pixel is a remote image that adds a spam signal, and the data is unreliable because Apple Mail Privacy Protection and Gmail's image proxy register opens that never happened. Track replies and meetings instead. Link-click tracking through a custom tracking domain is a lower-risk signal if you need any tracking at all.

What's the ideal text-to-image ratio?

There's no exact threshold that flips a message to spam. SpamAssassin scores the image-to-text ratio on a sliding scale, so more image equals more points, gradually. For cold email, aim for all text or as close to it as possible. If you're calculating a ratio, you already have more images than a first-touch email should carry.

Will sending plain-text-only hurt me anywhere?

No. Plain-text-only is safe everywhere and renders in every client. The only reason to wrap it as multipart/alternative is to avoid the HTML-only penalty if you do include an HTML part, and to keep formatting options open for warmer replies. Text-only is a perfectly valid, filter-proof choice.

The bottom line

Stop blaming the format tag. HTML scores almost nothing on its own. What gets cold email filtered is the payload people pack into HTML: images, tracking pixels, hidden text, styled buttons, and a low text-to-image ratio that all read as bulk mail. Send a multipart message whose HTML half is as plain as the text half, drop the images and open tracking on first contact, and test the exact message before you scale. Do that and "plain text vs HTML" stops being a deliverability worry and goes back to being a styling preference.

For where format fits into the larger picture, the complete guide to cold email outreach ties content, infrastructure, and reputation together.

Sources

• Apache SpamAssassin, Tests Performed: v3.3.x
• IETF, RFC 2046 (MIME Part Two): Multipart/Alternative
• Google, Email sender guidelines
• Apple, If you see 'Unable to load remote content privately'
• Word to the Wise, There's text and then there's text