HTML Email Best Practices 2026: Templates That Work in Every Client
HTML email development is the one area of front-end where CSS Grid doesn't exist, <div> layout is unreliable, and a Microsoft product from 2007 still dictates how you write markup. The good news: the constraints haven't changed much, and once you know the patterns, they're consistent.
This guide covers the HTML email best practices that matter in 2026 — layout, responsive design, dark mode, typography, images, accessibility, and testing. Each section includes the pattern that works and why alternatives fail.
1. Use table-based layout
This is the one rule that hasn't changed since 2005. Use <table> for layout, not <div>.
Outlook (2016, 2019, 2021) uses Microsoft Word's rendering engine, which has no support for CSS Flexbox, Grid, or most modern layout properties. Tables render consistently across all clients.
The correct pattern:
<table width="600" cellpadding="0" cellspacing="0" border="0" align="center">
<tr>
<td>
<!-- content here -->
</td>
</tr>
</table>
Why align="center" and not margin: 0 auto?
Older Outlook versions don't respect margin: auto on tables. Use both — align="center" for Outlook, margin: 0 auto in a CSS rule for everything else.
Max width: 600–700px This is the safe range for desktop rendering in webmail clients. Gmail clips emails wider than 102KB of HTML, and wider tables cause horizontal scrolling in smaller Outlook windows.
2. Inline critical CSS, use <style> for responsive rules
Webmail clients like Gmail strip <link> stylesheets entirely. The safe approach:
- Inline styles for all layout-critical and visual properties (background, padding, font-size, color)
<style>block in<head>for media queries and responsive overrides
<head>
<style>
@media only screen and (max-width: 600px) {
.column { width: 100% !important; display: block !important; }
}
</style>
</head>
<body>
<td style="padding: 24px; font-size: 16px; color: #333333;">
<!-- inline styles are safe everywhere -->
</td>
</body>
Gmail on Android and iOS does support <style> blocks, but Outlook.com strips class selectors. For Outlook.com-safe responsive behavior, use width attributes directly on <td> elements rather than relying on class overrides.
3. Build for mobile first
More than 60% of emails are opened on mobile. The responsive pattern for HTML email is the opposite of web CSS — you design for desktop (600px fixed width) and use media queries to override for mobile.
The column-collapse pattern:
<table width="600">
<tr>
<td class="column" width="280" style="width: 280px;">Left column</td>
<td class="column" width="280" style="width: 280px;">Right column</td>
</tr>
</table>
@media only screen and (max-width: 600px) {
.column {
width: 100% !important;
display: block !important;
}
}
On mobile, both columns stack to full-width blocks. The !important is needed to override the inline width attribute.
If you design in Figma: Marka Email Generator handles this automatically. Build your layout with Auto Layout in Figma — columns defined with Auto Layout export as responsive tables that collapse to single-column on mobile without any manual CSS.
4. Set explicit widths on all table cells
Never rely on content to determine cell width. Set width on every <td> — both as an attribute (width="200") and as an inline style (style="width: 200px;"). Outlook reads the attribute; modern clients read the style.
<td width="200" style="width: 200px; padding: 0;">
If you're nesting tables (required for multi-column layouts), set width="100%" on inner tables so they fill the parent cell.
5. Images: always set width, height, alt, and display
The safe image declaration:
<img
src="https://cdn.example.com/image.jpg"
width="600"
height="300"
alt="Product launch announcement"
style="display: block; width: 100%; max-width: 600px; height: auto; border: 0;"
/>
Why each attribute matters:
widthandheightattributes prevent layout shift when images are blockedalttext is displayed by Outlook and many corporate clients that block images by default — it's often the first thing a recipient readsdisplay: blockremoves the 2–3px gap Outlook adds under inline imagesborder: 0prevents blue borders in older Outlook versionsmax-width: 600pxwithwidth: 100%makes the image scale down on mobile
Use absolute URLs — email clients can't resolve relative paths. Host all images on a publicly accessible CDN before exporting.
6. Typography: web-safe fonts with system fallbacks
Custom fonts via @font-face are supported in Apple Mail, iOS Mail, Samsung Mail, and some Android clients — but not in Outlook or Gmail. Always declare a web-safe fallback stack:
font-family: 'Inter', Arial, Helvetica, sans-serif;
font-family: 'Playfair Display', Georgia, 'Times New Roman', serif;
Minimum readable font sizes:
- Body text: 16px (14px minimum)
- Mobile body: 16px (prevents iOS auto-zoom on inputs)
- Headlines: 24px+
- Footer/legal: 12px minimum
Line height: Set line-height as a unitless multiplier (e.g. 1.5) rather than pixels. Some clients multiply it differently when font sizes are overridden.
7. Dark mode support
Dark mode is now the default for a significant share of email opens — Apple Mail, iOS Mail, and Outlook 2019+ all support it. There are two levels of support to implement:
Level 1 — Prevent forced inversion (required)
Add color-scheme meta and CSS to prevent email clients from auto-inverting your colors in unintended ways:
<meta name="color-scheme" content="light dark" />
<meta name="supported-color-schemes" content="light dark" />
:root { color-scheme: light dark; }
Level 2 — Custom dark mode styles (recommended)
Use the prefers-color-scheme media query to define your own dark palette:
@media (prefers-color-scheme: dark) {
body { background-color: #1a1a1a !important; }
.email-body { background-color: #1a1a1a !important; }
.text-primary { color: #ffffff !important; }
.text-secondary { color: #a0a0a0 !important; }
.cta-button { background-color: #ffffff !important; color: #000000 !important; }
}
Logo and images in dark mode:
Use PNG with a transparent background for your logo — it works on both light and dark backgrounds. For images with white backgrounds that will look wrong in dark mode, use the [data-ogsc] targeting trick or provide a dark-mode-specific image.
8. Buttons: use table-based CTAs, not <a> tags alone
A plain <a> styled as a button will lose its styles in many Outlook versions. The bulletproof button pattern:
<table cellpadding="0" cellspacing="0" border="0">
<tr>
<td style="border-radius: 6px; background-color: #000000;">
<a
href="https://example.com"
target="_blank"
style="
display: inline-block;
padding: 14px 28px;
font-size: 16px;
font-weight: 600;
color: #ffffff;
text-decoration: none;
"
>Get started</a>
</td>
</tr>
</table>
The background color is on the <td>, not the <a> — this is the key. Outlook ignores background colors on inline elements but respects them on table cells.
9. Preheader text
The preheader is the preview text that appears after the subject line in most email clients. If you don't set it, the client will show the first text in your email body — often navigation links or an "If you can't see this email" message.
<div style="display: none; max-height: 0; overflow: hidden;">
Your preheader text here — keep it under 90 characters.
‌ ‌ ‌ ‌ ‌
</div>
The ‌ characters pad the hidden div to prevent the email client from pulling in body text to fill the preview space.
Keep preheader text under 90 characters — anything longer gets cut off. Make it complement the subject line, not repeat it.
10. Accessibility basics
Accessible HTML emails also tend to render better in corporate environments where images are blocked:
- Alt text on all images — descriptive for content images, empty (
alt="") for decorative ones role="presentation"on layout tables — tells screen readers to skip table structure announcements- Sufficient color contrast — WCAG AA requires 4.5:1 for body text, 3:1 for large text
- Logical heading order — use
<h1>once (the email headline),<h2>for section headings langattribute on<html>— helps screen readers choose the correct voice
<html lang="en">
...
<table role="presentation" width="600">
11. Testing before you send
No amount of careful coding replaces testing in real clients. The minimum test matrix for 2026:
| Client | Why it matters |
|---|---|
| Outlook 2019/2021 | Word rendering engine — most likely to break |
| Gmail (web) | Strips <style> tags, CSS class names in some cases |
| Apple Mail | Best rendering + dark mode reference |
| iOS Mail | Mobile rendering baseline |
| Gmail (iOS/Android) | Different from Gmail web — test separately |
| Outlook.com | Strips many CSS properties |
Testing tools:
- Litmus — screenshot testing across 90+ clients
- Email on Acid — similar coverage, different pricing
- Marka's built-in test send — send to your own inbox directly from Figma before exporting
Send a real test to your own inbox, not just the preview. Real rendering differs from previews in ways that matter.
12. HTML size limit
Gmail clips emails larger than 102KB of HTML. If your email gets clipped, recipients see a "Message clipped" notice and miss your CTA.
To stay under the limit:
- Remove whitespace and comments before sending (most ESPs do this automatically)
- Avoid inlining large amounts of CSS
- Don't repeat large inline style blocks — use
<style>for repeated rules - Keep image src URLs short
Designing HTML emails in Figma
If you're starting from a design rather than raw HTML, Figma is the fastest path to a production-ready email. The Marka Email Generator plugin converts Figma frames into email-safe HTML — table-based layout, inlined styles, responsive columns from Auto Layout, and preheader support — without writing any of the patterns above by hand.
Browse free Figma email templates → or start with the email design system → to skip straight to customization.
