HTML Email Best Practices That Actually Render
Email clients are not browsers. Here are the HTML email rules that keep your design intact from Gmail to Outlook — and the traps that break it.
Overview
HTML email is not web development. Email clients — especially Outlook, which renders with Word's engine — support a fraction of modern CSS, strip out what they don't like, and disagree with each other constantly. The result is a set of rules that look ancient: table-based layouts, inline CSS, and defensive image handling. They're not legacy habits; they're what keeps your email looking right in the inbox that matters.
The rules that keep email rendering
HTML email is not web development — clients support a fraction of modern CSS, strip what they dislike, and disagree constantly, with Outlook (which renders using Microsoft Word's engine) the worst offender. So the core rules look ancient on purpose. Build layout with nested tables, not flexbox or grid; put CSS inline on elements (many clients strip <style> blocks); keep the body ~600px wide; use web-safe fonts with fallbacks (custom fonts often won't load); and set explicit widths/heights on images. Always add alt text, because many clients block images by default and your alt text is the first thing the reader sees.
Then design for the two states people actually see. Images-off: keep a high text-to-image ratio, a meaningful preheader, and bulletproof buttons (built from a table cell with a background colour, not a background-image), so the email still communicates and is still clickable with images blocked. Dark mode: many clients invert or shift your colours, so avoid pure-black text on transparent, give logos a safe background, and test it — dark mode breakage is now one of the most common rendering complaints.
- Table-based layout, ~600px width
- Inline CSS on elements, not just <style> blocks
- Alt text on every image (images are often blocked by default)
- Bulletproof table-cell buttons; web-safe fonts with fallbacks
- Design for images-off AND dark mode — test both
Test everywhere, or (better) use a framework
There's no "it works in my browser" in email — the only truth is testing in real clients. At minimum cover the big three: Gmail (web and app), Outlook (desktop is the harsh one — check it specifically), and Apple Mail, which together account for most opens. A quick send-test to a few personal accounts catches the worst breakage; dedicated preview tools (Litmus, Email on Acid) render dozens of client/device combos at once if you send at scale.
Better still, don't hand-code bulletproof tables at all. MJML is the most popular framework: you write clean, semantic markup and it compiles to the messy, responsive, Outlook-safe HTML for you. Mailbase uses MJML for its campaigns and templates, so you get cross-client output without writing a single nested table — which removes most of the rules above as things you personally have to remember.
- Send-test in Gmail, Outlook (desktop), and Apple Mail before launch
- Outlook desktop is the strictest — check it specifically
- Preview tools (Litmus / Email on Acid) for scale
- Use a framework (MJML) so you don't hand-code tables at all
Common Mistakes
- Using modern CSS layout that Outlook silently breaks (use tables).
- Shipping HTML-only emails with no plain-text part — a spam signal.
- Forgetting alt text and a fallback for when images are blocked.
- Not testing on a real phone and in Outlook before sending.
Sources & Further Reading
Official docs for current setup details, pricing, and API behavior — verify specifics there, since they change.
Related guides
More on html email best practices and the surrounding email design workflow:
FAQ
Why do I have to use tables for HTML email?
Because major clients — Outlook above all — don't support modern CSS layout like flexbox or grid. Tables render consistently across clients, so they remain the reliable way to lay out email even though the web moved on years ago.
Why is my email broken in Outlook?
Outlook's desktop app renders with Microsoft Word's engine, which ignores much modern CSS. Use table layouts, inline CSS, explicit dimensions, and VML or framework output for backgrounds and buttons. Always test in Outlook specifically.
Should I code HTML email by hand or use a framework?
A framework like MJML saves you from hand-writing bulletproof tables and handles cross-client quirks automatically. Hand-coding is fine for tiny tweaks, but for real templates a framework is faster and far less error-prone.