Plain text or HTML in cold email? Pick by message type

For one-to-one cold outreach, send plain text. For newsletters and transactional mail people asked for, send HTML with a matching plain-text alternative. That is the whole answer, and the reason is not the folklore one.

Spam filters do not score HTML as suspicious. Gmail delivers enormous volumes of HTML every day. What HTML does is tell the truth about your message: a designed template with a hero image, a button and tracked links is a bulk-mail signal, because that is what bulk mail looks like. When the claim in your copy is "I noticed you're hiring two SDRs and thought I'd reach out personally", a template contradicts it in the first pixel. Recipients notice that contradiction faster than any filter does, and recipients are the ones who press the spam button.

What you are actually choosing between

A modern email is usually a multipart/alternative MIME message: one body in text/plain, one in text/html, and the client picks. So the real options are three, not two.

That last row is the actual problem case. An HTML-only message, or one whose plain-text part is a stub saying "view this email in your browser", is a sloppiness signal and it degrades rendering in text-only clients and some accessibility tooling. If you send HTML, send a genuine text alternative that says the same thing.

Why plain text performs for cold email

• It matches the claim. A short text email from a person is consistent with a short text email from a person.
• It cannot clip. Gmail clips messages once the HTML exceeds roughly 102 KB, and it clips from the bottom — taking your signature, your postal address and your unsubscribe link with it.
• It has no images to block. Nothing breaks when the recipient's client blocks remote content, which many corporate clients do by default.
• It survives every gateway. Security gateways rewrite, strip and sandbox HTML and links. Plain text arrives as written.
• It renders identically everywhere, including on a watch, in a terminal client, and in the notification preview that often decides whether the message gets opened at all.
• Fewer link domains. Each tracked link introduces a redirect domain whose reputation is not yours. A plain-text email with one bare link introduces none.

When HTML is the right call

Use it when the reader opted in and the content genuinely needs structure: a newsletter with sections, a receipt with a line-item table, a product announcement with one image that carries real information. In those cases, HTML is not a bulk-mail tell because the message *is* bulk mail and the reader knows it.

If you do send HTML, the deliverability-relevant rules are dull and short:

1. Keep the HTML under 100 KB so it cannot clip.
2. Write a real plain-text part with the same content and the same links.
3. Never send a single-image email. Real text is what a screen reader reads and what an image-blocking client shows.
4. Set width and height on every image and write alt text.
5. Keep the link count low and the link domains few.
6. Do not embed base64 images; they count against the HTML size and many clients will not render them.
7. Include the physical postal address and opt-out that CAN-SPAM requires, and at bulk volumes add List-Unsubscribe with an HTTPS URL and a mailto plus List-Unsubscribe-Post: List-Unsubscribe=One-Click, so the client offers one-click opt-out in its own interface.

The middle ground that usually goes wrong

People reach for "lightly styled HTML" — plain text with bold, a coloured link and a small logo — believing they get both benefits. Mostly they get neither. The logo is still an image fetch, the styled link is usually still tracked, and the email no longer renders identically. If the design is doing no work, send text. If it is doing work, commit to HTML and follow the rules above.

The one genuinely useful exception: a plain-looking multipart message with *no* images and *no* styling beyond what a mail client would produce itself. That is effectively plain text with an HTML part, and it is fine. Most sequencers can be configured to produce it.

What not to do

Do not send a designed template as cold outreach. The template is a stronger signal than anything in your copy, and it is a signal that contradicts you.

Do not send HTML with no plain-text part, or with a stub text part. This is the single most common HTML mistake and the one most likely to be read as carelessness.

Do not add a tracking pixel to a one-to-one email and then rely on the number. Apple's Mail Privacy Protection pre-fetches images for Apple Mail users and corporate proxies do the same, so recorded opens include machines. You are adding a remote image, and a domain, to buy a number you cannot trust.

Do not attach anything on first contact. Attachments get stripped by gateways, inflate the message, and rarely get opened by someone who does not know you.

Do not use a word-level "spam checker" to choose a format. The decision is about rendering and signals, not vocabulary.

Do not switch formats mid-sequence while you are also changing volume or copy. You will not be able to attribute the change, and if your placement is unstable the format comparison is noise anyway.

Where MailPilot fits

Format only matters once the message is in the inbox, and your sequencer cannot tell you whether it is — "delivered" only means a receiving server returned a 250. MailPilot measures real inbox placement per provider through a seed-inbox network, including whether Gmail is filing you under Promotions rather than the inbox, warms each mailbox over OAuth on Gmail and Outlook or over SMTP/IMAP for SendGrid, Amazon SES, Mailgun, Postmark and custom SMTP, checks SPF, DKIM and DMARC on your sending domains, and tracks per-mailbox reputation daily.