You build a clean, responsive email with flexbox, send a test, and it looks perfect in Apple Mail. Then someone opens it in Outlook on Windows and your layout is a single sad column with mystery gaps, your buttons are unclickable rectangles, and your custom font is Times New Roman. Nothing is wrong with your CSS. What is wrong is the assumption that email clients render HTML the way browsers do. They do not, and the worst offenders are also the ones your B2B audience uses most.
The rendering engine problem
A browser is one rendering target. Email is dozens, and they disagree with each other on fundamentals:
- Outlook for Windows (classic desktop) renders HTML with Microsoft Word. Not a browser engine, a word processor. Word's HTML support froze somewhere around 2006: no flexbox, no grid, no
max-widthon divs, noborder-radius, no background images on most elements, unreliable padding on<div>and<p>. - Gmail uses a real engine but aggressively sanitizes. It supports embedded
<style>blocks now, with caveats, but strips<link>stylesheets, strips<style>entirely in some clipped or forwarded contexts, and clips messages over 102 KB. - Apple Mail uses WebKit and renders almost everything correctly, which is exactly why testing only on a Mac or iPhone gives you false confidence.
- Older webmail and Android clients fall somewhere in between, each with its own strip list.
The design constraint that falls out of this: your email must survive the worst renderer it will meet, which usually means Word.
The rules that follow from the constraint
1. Inline your styles
Because <style> blocks get stripped in enough contexts to matter, every style that the email cannot live without goes in a style attribute on the element itself:
<td style="font-family: Arial, sans-serif; font-size: 16px;
line-height: 24px; color: #333333; padding: 0 24px;">
Body copy here.
</td>Keep a <style> block too, for the clients that honor it, and put progressive enhancements there: media queries, hover states, dark mode tweaks. The inline styles are the floor; the style block is the ceiling.
2. Tables are your layout system
Floats are unreliable, flexbox does not exist in Word, and div widths are ignored. Tables, however, render consistently everywhere because they have for twenty years. The skeleton of a bulletproof email:
<table role="presentation" width="100%" cellpadding="0" cellspacing="0" border="0">
<tr>
<td align="center" style="background-color: #f4f4f4;">
<table role="presentation" width="600" cellpadding="0" cellspacing="0" border="0">
<tr>
<td style="padding: 32px 24px; background-color: #ffffff;">
Content goes here.
</td>
</tr>
</table>
</td>
</tr>
</table>Three details that matter: role="presentation" stops screen readers from announcing layout tables as data tables; the width is set with the HTML width attribute because Outlook ignores CSS widths on tables in many cases; and padding lives on <td> elements, the one place Word applies it reliably.
3. The 600 pixel convention
Desktop email reading panes are narrow, and Outlook does not support max-width. A fixed 600 to 640 pixel outer table is the standard compromise: narrow enough for every preview pane, wide enough for real layout. For mobile, a media query in the style block (honored by the good clients) scales it down, while the bad clients show the fixed width, which mobile Outlook at least zooms sensibly.
4. Outlook conditional comments
Microsoft gave us an escape hatch: HTML comments that only Outlook parses.
<!--[if mso]>
<table role="presentation" width="600"><tr><td>
<![endif]-->
<div style="max-width: 600px;">
Modern clients get the div, Outlook gets the table.
</div>
<!--[if mso]>
</td></tr></table>
<![endif]-->This hybrid pattern, a fluid div for everyone wrapped in a ghost table for Outlook, is the foundation of responsive email that still works in Word. Note: if you minify your email HTML, make sure the minifier preserves conditional comments, or Outlook loses its entire layout.
5. Bulletproof buttons
A CSS-styled <a> with padding renders as a tiny text link in Outlook because Word ignores padding on anchors. The reliable pattern puts the button styles on a table cell:
<table role="presentation" cellpadding="0" cellspacing="0" border="0">
<tr>
<td style="background-color: #2563eb; border-radius: 6px;">
<a href="https://example.com" style="display: inline-block;
padding: 14px 32px; font-family: Arial, sans-serif;
font-size: 16px; color: #ffffff; text-decoration: none;">
Get started
</a>
</td>
</tr>
</table>Outlook will not round the corners, and that is fine. Square corners in one client beats a broken button in all of them. Design for graceful degradation, not pixel parity.
6. Images: assume they are off
Several clients block images until the reader opts in, and many readers never do. Consequences: every image needs meaningful alt text styled to be readable (alt text inherits the element's font styles in most clients), no critical information may live only in an image, and your layout must hold together with every image missing. Also set width and height attributes explicitly, or Outlook displays images at their native dimensions and a 1200 pixel retina image destroys your layout.
7. Fonts
Web fonts work in Apple Mail and partially elsewhere; Outlook falls back, and if you declare a web font carelessly, it falls back to Times New Roman rather than your stack. Always declare a full stack ending in a generic family: font-family: 'Inter', Helvetica, Arial, sans-serif;. For Outlook specifically, an mso conditional style forcing Arial saves you from Times.
Testing: non-negotiable
Send tests to real accounts in Gmail (web and app), Outlook desktop on Windows, and Apple Mail at minimum. Litmus or Email on Acid screenshots across the full client matrix are worth the cost for anything going to a large list. Check dark mode in both Gmail and Outlook, which invert colors differently and can make dark text on transparent PNGs vanish.
Two more pre-send checks: keep total HTML under 102 KB to avoid Gmail clipping (which also hides your unsubscribe link, a compliance problem), and validate that your markup survived your ESP's processing by viewing the source of a received test. Templating systems love to rewrite your carefully constructed conditionals. If you want a structural starting point for the tables themselves, our HTML Table Generator produces clean nested-table markup you can adapt.
Accessibility is not optional in email either
Email screen reader usage tracks the web's, and table-based layout makes accessibility easier to get wrong. The checklist: role="presentation" on every layout table, a lang attribute on the root element, real text instead of text-in-images for anything that matters, alt attributes on every image (empty alt="" for decorative ones), and a logical heading structure with at least one <h1>. Color contrast rules apply doubly because dark mode transformations can crush your carefully chosen palette. None of this costs rendering compatibility; it is purely additive.
The shortcut
Everything above is mechanical translation: modern CSS in, table-based inline-styled email HTML out. That is exactly what our AI Email HTML Converter does. Paste the HTML you wish you could send, and it produces the inlined, table-based, Outlook-conditional version that actually renders in inboxes, with the reasoning explained so you learn the patterns as you go. For the rest of your markup workflow, the same rules from our HTML minification guide apply to web pages, but leave your email HTML readable; you will be debugging it in a Word renderer soon enough.