Plain Text Email: What It Is, What It Is Not, and Where It Breaks
A plain text email carries an unformatted body with no markup, images or tracking pixel. Most email is actually multipart/alternative, carrying a text part and an HTML part together and letting the client choose, so a message can be plain text to you and HTML to the person reading it.
Key takeaways
- A message is only plain text if the HTML part is absent, which the Content-Type header shows.
- No pixel means no open rate, so the metric disappears rather than getting worse.
- Filtering weighs reputation and sending pattern far above content type.
- The real argument is congruence: a message claiming to be personal should look like one.
A plain text email is a message whose body is sent as unformatted text, with a MIME content type of text/plain, carrying no HTML markup, no styling, no embedded images and no tracking pixel. What the recipient's mail client displays is what the sending system wrote, character for character, with the client supplying its own font and spacing.
The contrast is with text/html, and with the arrangement most email actually uses: a multipart/alternative message carrying both versions, defined in RFC 2046, which lets the receiving client pick whichever it prefers. That third option is where most of the confusion in this topic lives, because a message that renders as plain text at one recipient may be an HTML message at another.
What is actually being chosen
Three shapes are possible, and they are genuinely different objects.
A text/plain message carries one body, unformatted. There is no way to bold a word, no way to attach a stylesheet, and no way to embed an invisible image, which means no open tracking. Links appear as their literal URLs unless the client detects and linkifies them.
A text/html message carries markup. It supports layout, images and a tracking pixel, and it is what almost all marketing email is.
A multipart/alternative message carries both bodies and lets the client choose. This is the default in most sending platforms, and it is why "we send plain text" is frequently untrue: the platform generated an HTML part as well, and most clients display that one. A message is only plain text if the HTML part is absent.
The practical way to know which you are sending is to look at a delivered message's source rather than at the composer. A Content-Type: multipart/alternative line means both parts went out.
- Step 1Compose
The sending platform builds one or both body parts, often without saying which.
- Step 2Send
A multipart/alternative message carries a plain text part and an HTML part together.
- Step 3Choose
The receiving client picks the part it prefers, which is usually HTML where one exists.
- Step 4Render
The recipient sees the chosen part. The sender's intent about which is not consulted.
Where the received wisdom misleads
Plain text is not a deliverability setting. The belief that plain text reaches the inbox and HTML does not is durable and mostly wrong. Filtering weighs sender reputation, authentication, sending pattern, list quality and recipient behaviour far more heavily than content type. A plain text message from a domain with a poor reputation is filtered; an HTML message from a strong one is not. The format is not the lever people hope it is.
The parts of it that do help are specific, and they are not about the format itself. A plain text message cannot carry a tracking pixel, so it does not generate the image load that some filters treat as a signal. It cannot carry heavy nested markup, image-to-text ratios or code that a scanner has to unpack. It usually carries fewer links. Those are properties an HTML message can also have, by being written plainly, so what actually helps is restraint rather than the content type.
It costs you open tracking entirely. Open rates are measured by a one-pixel image, which requires HTML. Send genuinely plain text and open rate stops existing as a metric. That is not automatically a loss, given how unreliable open tracking has become since mail clients began prefetching images on the recipient's behalf, and it is a change worth making deliberately rather than discovering when a report comes back empty.
Click tracking survives, and it brings its own trade. Tracking clicks means rewriting links through a redirect domain, which is possible in plain text and visible to the reader, since the URL is displayed literally. A message that claims to be a personal note and contains a long redirect URL is telling the recipient something the copy does not intend. Sending unrewritten links means giving up click measurement in exchange for looking like what it claims to be.
It looks like what a person writes, which is the real argument. One person writing to another does not send a layout. A plain message in a cold outbound context is congruent with its own premise, and that congruence is worth more than any filtering effect. It is an argument about credibility rather than about spam scores, and it is the honest reason to prefer it.
- Matches the premise of a personal message
- No tracking pixel, so no open-rate metric
- Links are visible as literal URLs
- Nothing for a scanner to unpack
- Supports layout, images and branding
- Open tracking is available, with known accuracy problems
- Rewritten links can be hidden behind anchor text
- Correct for newsletters and announcements
- Carries both and lets the client choose
- The default in most platforms, often unnoticed
- You do not control which one a recipient sees
- A message can look plain to you and not to them
What this means when you are running outbound
Find out what you are actually sending. Send a message to a mailbox you control, open the source, and read the Content-Type. A surprising number of teams describing their outbound as plain text are sending multipart messages with a full HTML part. It is a thirty-second check and it settles a question that otherwise gets argued from memory of a settings screen.
Check it at more than one recipient. Because the client chooses the part, the same message can render differently at a Gmail address, an Outlook desktop client and a phone. If the format is load-bearing in your thinking, look at it in the places your list actually reads mail rather than in the one client you happen to use.
Decide about tracking before you decide about format. The two are entangled. If open rate is load-bearing in your reporting, going genuinely plain text removes it, and something else has to carry the measurement. Replies and meetings are better measures anyway, and they are unaffected either way.
Match the format to the claim the message makes. A message written as one person to another should look like one. A newsletter, a product announcement or an event invitation is honestly a designed communication, and pretending otherwise helps nobody. The mismatch is what readers notice, not the markup.
Watch the signature. It is the most common place a supposedly plain message stops being one, because signature blocks are generated by the platform and arrive with a logo, social icons and a banner. A message with three lines of text and a two-hundred-pixel image beneath it is an HTML message that starts by claiming otherwise, and the reader sees the image first.
What plain text does to the writing
There is a second-order effect that is easy to miss and probably matters more than the format decision itself. Removing the ability to style anything removes a set of habits. There is no bold to lean on, no button to carry the ask, no header image to do the introduction, and no layout to disguise a message that has not decided what it is about.
What is left is sentences. A weak opening is obvious when nothing decorates it, and a paragraph of throat-clearing before the point is visible in a way it is not when it sits under a masthead. Teams that switch to plain text frequently report that their copy improved, and the honest explanation is usually that the format stopped hiding the copy rather than that the format did anything.
Length behaves the same way. HTML makes a long message look organised, so long messages survive review. In plain text a long message looks long, which is a useful pressure in a context where the reader owes you nothing and decides in seconds.
The thing worth measuring instead
If you want to know whether format matters for your audience, the way to find out is a controlled comparison rather than an argument, and it has to be a fair one. Same list quality, same sending inventory, same offer, same period, with only the format differing, and the outcome read as replies rather than opens, since opens are the metric the plain-text arm cannot report.
Be careful what a difference would prove. Format changes usually arrive alongside other changes, shorter copy, fewer links, no images, and any of those could carry the result on its own. Attributing the outcome to the content type when the actual variable was length is a conclusion that then gets applied everywhere and quietly stops working. If the arms differ in more than one respect, the honest reading is that something in the bundle helped, and the next test isolates which.
- Yes: The Content-Type of a delivered message has been read and understood
- Yes: You know whether an HTML part is being generated alongside the text part
- Yes: The reporting does not depend on a metric the chosen format cannot produce
- Yes: Link rewriting is a conscious choice, given it is visible in plain text
- Yes: The format matches what the message claims to be
- No: Switching to plain text as a remedy for a placement problem
The short version
Plain text is a MIME content type, not a deliverability strategy. It carries no markup, no images and no tracking pixel, and in a cold outbound context its real value is congruence: a message that claims to be from a person looks like one.
The filtering benefit people attribute to it is mostly the benefit of restraint, which an HTML message gets by being written plainly. The real trade is measurement, since no pixel means no open rate, and that is a decision to make on purpose. If placement is the actual problem, the format is not where the answer is; authentication, list quality, sending history and what actually moves deliverability are, and an audit will find the cause faster than a rewrite.
RevenueFlow runs cold email and LinkedIn outreach for B2B teams, one message per campaign, written to look like what it is. See how the campaigns work.
Specification behaviour verified as of August 2026 against RFC 2046. Verify current specifications with the source before relying on them.
Frequently asked questions.
Frequently asked questions- Does plain text email improve deliverability?
- Mostly no. Filtering weighs sender reputation, authentication, sending pattern and list quality far more heavily than content type. The parts that do help are specific: no tracking pixel, no heavy markup, fewer links. An HTML message written plainly gets the same benefits, so what helps is restraint rather than the format.
- How do I know whether I am actually sending plain text?
- Send a message to a mailbox you control and read the source. A Content-Type of multipart/alternative means both a text part and an HTML part went out, and most clients will display the HTML one. A surprising number of teams describing their outbound as plain text are sending multipart messages.
- Can I still track opens and clicks in a plain text email?
- Opens require an embedded image, so genuine plain text removes that metric entirely. Click tracking still works, by rewriting links through a redirect domain, and in plain text that rewritten URL is visible to the reader. A message claiming to be a personal note with a long redirect URL is telling the recipient something.
- When should I use HTML instead?
- When the message honestly is a designed communication: a newsletter, a product announcement, an event invitation. Those are supposed to look composed, and pretending otherwise helps nobody. Match the format to the claim the message makes; readers notice the mismatch rather than the markup.