Email supports sending two renderings of the same message in one envelope—multipart/alternative, with a text/plain part alongside the text/html part. The client picks what it can display best. The question is whether the plain half is worth bothering with.
The honest stakes
Skipping it will not, by itself, send you to spam—plenty of large senders ship HTML-only mail and deliver fine. That’s exactly why the verdict is ideally rather than a hard yes: the text part costs approximately nothing (most frameworks and platforms generate it from your HTML automatically) and buys you a stack of small, real wins.
What the text part quietly handles
- Constrained clients. Watches, notification previews, terminal mail readers, and some corporate gateways lean on the text part—it’s often what generates the preview snippet you see before opening.
- Accessibility. Screen readers handle a clean text alternative more predictably than whatever your HTML template’s table-soup renders down to.
- Recipient settings. Some people and some security-conscious organizations read mail with HTML disabled. HTML-only mail shows them nothing—or a wall of raw markup.
- Filter completeness. A well-formed multipart message is one more small signal of a legitimate sender. Historically, HTML-only correlated with spam; the correlation is weaker now, but completeness never hurts.
The gotchas
- Don’t ship a garbage text part. An empty part, or one containing only “View this email in your browser,” is worse than useful—and a text part that wildly diverges from the HTML content looks deceptive to filters.
- Check what your tooling generates. Auto-generated text from HTML is usually fine, but templates heavy on images and buttons can reduce to gibberish. Read it once.
- Links belong in both parts. The text version should carry the same essential URLs—including the unsubscribe link.
Two minutes of setup, one read-through of the output, and you’ve covered every inbox from a terminal to a wristwatch. That’s the trade.