How to Design HTML Emails That Work Everywhere

HTML email is the last place on the web where you write code like it's 2003 and mean it. While browsers have spent two decades converging on standards, email clients have gone the opposite direction, splintering into over 100 rendering environments that each have their own opinions about which CSS properties deserve to exist.

We've built email templates for clients running Pardot, Salesforce Marketing Cloud, Mailchimp, and custom transactional systems. The templates that survive contact with real inboxes all share one thing: they were built with a deep understanding of what breaks and where.

The Rendering Engine Problem

The root cause of email's compatibility mess is that email clients don't agree on how to render HTML. Web browsers all use one of three engines (Blink, Gecko, WebKit) that broadly support the same standards. Email clients use whatever their developers felt like, and some of those choices were made fifteen years ago.

According to Litmus's email client market share data from January 2026, the three environments that matter most are Apple Mail (51.52% of opens), Gmail (26.72%), and Outlook. Each handles your HTML differently.

Apple Mail uses WebKit, the same engine behind Safari, and it's by far the most standards-compliant email client. Media queries, prefers-color-scheme, web fonts, flexbox, CSS animations: Apple Mail supports nearly all of it. If your email only needed to work in Apple Mail, you could write it like a web page and call it a day.

Gmail renders your HTML inside its own DOM and aggressively strips your CSS. It keeps display: flex but removes flex sub-properties like align-items, justify-content, and flex-direction. CSS Grid gets stripped entirely. If any single rule in your <style> block contains background-image: url(...), Gmail strips the entire style block, not just that rule. And Gmail's desktop web client doesn't support media queries at all, so your responsive breakpoints won't fire for a significant chunk of your audience.

Outlook desktop (2007 through 2021) uses Microsoft Word's HTML rendering engine. Not a browser engine. Word. It supports a subset of HTML 4 and CSS 2, and that's where it stops. No border-radius. No flexbox. No CSS background images without VML fallbacks. It silently strips margin and padding on <div> tags. This is the client that forces the entire industry to keep writing table-based layouts.

The new Outlook uses a Chromium-based rendering engine and supports modern CSS. But 2025–2026 is the transition period — both versions are actively in use, and they handle CSS in opposite ways. Microsoft ends support for the classic desktop version in October 2026, but enterprise adoption of the new client is slow.

Every decision in email development comes down to one question: will Outlook break this? The answer is usually yes.

Tables Are Still the Answer (And That's Fine)

Developers who've spent their careers building responsive web layouts with flexbox and grid often balk at the idea of using <table> elements for layout. It feels wrong. For the web, it is wrong. But email isn't the web.

Table-based layouts remain the only reliable way to achieve multi-column designs across all major email clients. Outlook ignores widths and padding on <div> tags but respects them on <td> elements. Gmail strips grid properties. The lowest common denominator across all rendering engines is the HTML table, and fighting that reality wastes time. Here's what a basic two-column structure looks like:

<table role="presentation" width="100%" cellpadding="0" cellspacing="0" border="0">
  <tr>
    <td align="center" style="padding: 0;">
      <table role="presentation" width="600" cellpadding="0" cellspacing="0" border="0">
        <tr>
          <td width="290" valign="top" style="padding: 10px;">
            <!-- Left column content -->
          </td>
          <td width="290" valign="top" style="padding: 10px;">
            <!-- Right column content -->
          </td>
        </tr>
      </table>
    </td>
  </tr>
</table>

The role="presentation" attribute tells screen readers these tables are for layout, not data — critical for accessibility. The outer table centres the email. The inner table constrains it to 600 pixels, the standard width that avoids horizontal scrolling. Every <td> carries its own inline styles because some clients strip <style> blocks entirely.

The hybrid coding approach takes this further with max-width on a wrapper <div> and conditional comments to target Outlook:

<!--[if mso]>
<table role="presentation" width="600" cellpadding="0" cellspacing="0"><tr><td>
<![endif]-->
<div style="max-width: 600px; margin: 0 auto;">
  <!-- Your content here -->
</div>
<!--[if mso]>
</td></tr></table>
<![endif]-->

The <!--[if mso]--> conditional comments are only understood by Outlook's Word engine. Every other client ignores them. You serve a fixed-width table to Outlook and a fluid <div> to modern clients. It's ugly. It works.

Inline Styles, Head Styles, and the Inlining Workflow

Email CSS lives in three places, and which one actually works depends on the client.

Inline styles (the style attribute on individual elements) have the broadest support. Every email client respects them. They're also tedious to maintain, which is why no one writes them by hand.

Embedded styles (a <style> tag in the <head>) work in most modern clients: Apple Mail, the Gmail mobile apps, Yahoo Mail, the new Outlook. But Gmail's desktop web client strips <style> blocks under certain conditions. Embedded styles are where your media queries and responsive rules live, since you can't put a @media query inline.

External stylesheets (a <link> tag) are stripped by almost every email client. Don't use them.

The practical workflow, and what Campaign Monitor's CSS guide recommends, is to develop your email using <style> blocks in the <head> just like building a web page. Use classes, keep your code organised, iterate on the design. Then run your final HTML through a CSS inliner tool (Juice, Premailer, or the built-in inlining in most ESPs) that applies every rule as an inline style on the matching elements.

Keep your <style> block in the final output too. Don't remove it after inlining. Clients that support embedded styles will use them (including your media queries), and clients that don't will fall back to the inline versions. Belt and suspenders.

Dark Mode: The New Compatibility Headache

Dark mode has introduced a whole new layer of email rendering inconsistency. When a user enables dark mode on their device or email client, the client may do one of three things to your email: nothing, partial colour inversion, or full colour rewriting. The behaviour varies by client, and there's no way to opt out.

Apple Mail gives developers the most control. It honours the prefers-color-scheme: dark media query, so you can define a separate colour palette for dark mode, swapping backgrounds, text colours, and image sources. It's also only available in Apple Mail and a handful of other clients.

Gmail on iOS and Android applies its own dark mode transformation, inverting light backgrounds to dark and adjusting text colours automatically. You can't override this with CSS. Classic Outlook desktop has partial dark mode support that can produce strange results: partially inverted headers, unreadable text on buttons where the background changed but the text colour didn't.

What works across the most clients:

• Use transparent PNGs for logos and icons. Solid-background images look jarring when the surrounding background gets inverted.
• Add subtle dark borders or outlines to images with transparent or white backgrounds, so they don't disappear in dark mode.
• Include prefers-color-scheme styles in your <style> block for clients that support it. For clients that don't, make sure your default design degrades acceptably when colours get inverted.

Litmus's research found that roughly 35% of email opens now occur in dark mode. That's too large a segment to ignore and too inconsistent to control perfectly. The goal is not pixel-perfect dark mode rendering. It's making sure nothing becomes unreadable.

Frameworks and Tools That Save Time

Writing table-based HTML with inline styles from scratch is slow and error-prone. Several tools exist to make email development less painful.

MJML is a markup language that compiles to email-safe HTML. You write components like <mj-section>, <mj-column>, and <mj-image>, and MJML's compiler generates the nested tables, conditional comments, and inline styles. It handles most Outlook quirks automatically. If you're building email templates regularly, MJML cuts development time significantly.

Maizzle takes a different approach — utility-first CSS (similar to Tailwind) compiled into email-safe HTML. More flexible than MJML but with a steeper learning curve.

For testing, Litmus and Email on Acid remain the industry standards. Both preview your email across dozens of client/device combinations without requiring a test lab. Email on Acid also offers a Broken Email Validator that flags CSS properties unsupported by specific clients. If your campaigns aren't getting the results you expect, testing is the first thing to investigate. We wrote about the broader diagnostic process in our guide to email campaigns that aren't converting.

Can I Email (caniemail.com) is the email equivalent of Can I Use. It tracks CSS and HTML feature support across email clients with clear yes/no/partial ratings. As of 2026, it covers 303 HTML and CSS features across 35+ clients.

Accessibility in Email Is Not Optional

The same accessibility principles that apply to websites apply to email, but with fewer tools at your disposal. Most ARIA roles get stripped by email clients (except role="presentation"). JavaScript doesn't execute. CSS support is limited. That makes semantic HTML and thoughtful structure even more important.

Use proper heading hierarchy: a single <h1> for the email's main topic, <h2> for sections. Screen readers like NVDA and VoiceOver use headings to build a navigable document outline, and email is no exception. Add lang="en" to your outermost wrapper element so screen readers pronounce words correctly.

Every image needs an alt attribute. Decorative images get alt="" (empty, not missing). Informational images get descriptive alt text. If an image contains text, the alt text must include that text verbatim. With images blocked by default in many corporate Outlook installations, alt text is often the first thing a recipient sees.

Colour contrast matters just as much in email as on the web. WCAG's 4.5:1 ratio for normal text applies. Dark mode can wreck your contrast ratios, which is another reason to test dark mode rendering seriously. Set a minimum font size of 14px for body text. Mobile clients may auto-resize smaller text, which can break your layout. Use line-height values of at least 1.5 for body copy.

For links and buttons, make the tap target at least 44x44 pixels. Text links should be distinguishable by more than colour alone (underlines remain the reliable solution). Buttons built with <table> and <td> elements are more Outlook-compatible than those using <a> tags with heavy padding.

The European Accessibility Act (EAA), which took effect in June 2025, extends accessibility requirements to digital communications including commercial email. If you send marketing emails to EU recipients, accessibility is a legal requirement. Even outside the EU, accessible emails reach more people and perform better.

We build email templates as part of our email marketing and development services, and every one starts with understanding which clients your audience actually uses. Litmus and most ESPs can tell you this from your existing send data. There's no reason to fix rendering in Yahoo Mail Japan if none of your subscribers use it.

Your email template isn't a one-time deliverable. It's infrastructure that every campaign runs through. Getting the foundation right — with proper authentication alongside the template (see our guide to SPF, DKIM, and DMARC) — means every email you send renders correctly and reaches the inbox regardless of client, device, or accessibility needs. Readable, functional, and professional in every one of them.

Sources

• Can I Email: HTML and CSS Support Tables for Email -- Feature-by-feature support data across 35+ email clients and 303 HTML/CSS features
• Litmus: Email Client Market Share -- Monthly market share data from 1.1 billion email opens (January 2026 data)
• Campaign Monitor: CSS Support Guide for Email Clients -- Reference for 278 CSS properties tested across 35 email clients
• Email on Acid: How to Code Emails for Outlook -- Outlook-specific rendering issues and fixes, including the Word rendering engine
• Litmus: Outlook Rendering Differences Guide -- Detailed breakdown of rendering differences across Outlook versions
• Litmus: The Ultimate Guide to Dark Mode for Email -- Dark mode behaviour across email clients with CSS strategies
• MJML: The Responsive Email Framework -- Open-source email markup language with hybrid coding approach
• Litmus: The Ultimate Guide to Email Accessibility -- WCAG compliance in email, screen reader testing, and semantic structure
• Campaign Monitor: The Developer's Guide to Dark Mode in Email -- CSS techniques for dark mode support across email clients