Why every transactional email needs a plain-text part

The plain-text part of an email is the one almost nobody looks at, which is why it is so often broken. Many transactional messages ship with a text alternative that is empty, a wall of stripped markup, or a single line saying "View this email in a browser." That is a missed opportunity, and occasionally a real problem.

What the text part is#

A typical HTML email is sent as a MIME multipart/alternative message with two versions of the same content:

Content-Type: multipart/alternative; boundary="b1"

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

Your password reset code is 482913. It expires in 15 minutes.

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

<html>...</html>
--b1--

The order matters: RFC 2046 says alternatives are listed from least to most preferred, so the plain-text part comes first and the HTML part last. A client displays the richest version it can handle and falls back to the others.

Who actually reads the text part#

More people and systems than you would expect:

• Users who disable HTML. Some security-conscious users and organizations configure clients to display plain text only, to avoid tracking pixels and rendering exploits.
• Screen reader users, some of whom find plain text easier to navigate than complex HTML layouts.
• Smartwatches and notification previews, which often draw from the text content.
• Terminal and lightweight clients used by developers and system administrators.
• Automated systems, such as ticketing tools and forwarding scripts that only parse text.
• Spam filters, which may compare the two parts. A text part that bears no resemblance to the HTML, or is missing entirely, is a mild negative signal in some filters. It is rarely decisive on its own, but there is no reason to give filters anything to wonder about.

For transactional mail, the case is even stronger. A password reset code or an order confirmation needs to be usable in every context, including a watch face.

What bad text parts look like#

Missing entirely#

An HTML-only message works in most clients, but loses everything above. Some sending libraries make the text part optional and developers never fill it in.

Auto-stripped HTML#

Removing tags from HTML produces something like:

Your order Order number A-10293 Item Qty Price Annual plan 1 $120.00 Total $120.00 View receipt Questions? Contact support Unsubscribe 123 Example St

Table cells run together, links vanish, and the structure that made the HTML readable is gone.

The browser redirect#

"This email requires an HTML-capable client. View it online at..." helps nobody who chose plain text on purpose, and it moves sensitive content, like a reset link, onto a web page.

What a good text part looks like#

A good text part is written, or at least generated thoughtfully, as its own format:

Your order has shipped

Order: A-10293
Shipped: September 14, 2026
Carrier: Example Post, tracking 9400 1000 0000 0000

Track your package:
https://example.com/orders/A-10293/track

Items
- Annual plan x1 ........ $120.00

Total: $120.00

Questions? Reply to this email or visit https://example.com/help

Example Inc., 123 Example Street, Springfield

Notice the conventions:

• A clear first line that states what happened.
• Key facts as labeled lines, easy to scan.
• Full URLs on their own lines, so they are clickable in clients that auto-link and copyable everywhere else.
• Simple lists with hyphens instead of tables.
• Short lines, ideally under about 78 characters, which RFC 5322 recommends, and certainly under the hard limit of 998.
• The same essential content as the HTML version, not a summary of it.