You approved your campaign in your sending tool and the preview was perfect. Yet part of your recipients get a colourless button, columns stacked on top of each other, or an email entirely in black text on a white background. The HTML is the same for everyone. What changes is what each mail client does with it before displaying it.
An email is not a web page
A web page is displayed by a browser that applies your code as is. An email, on the other hand, is displayed inside someone else’s interface: the Gmail page, the iPhone Mail app, the Orange webmail. These services cannot let a message alter their own interface or run arbitrary code. So they clean up your HTML before inserting it into their page.
That clean-up follows three broad logics, and each client applies them its own way.
1. Isolating your email from their page
Your email must not be able to restyle the webmail interface. Most webmails therefore replace your <body> tag with a plain block, and limit the scope of your CSS rules to that block. Direct consequence: anything you set on the <body> is lost, starting with the background colour.
2. Filtering the CSS
Each client keeps its own list of accepted properties, values and selectors. Anything not on it is silently removed: absolute positioning, a negative margin, an attribute selector, a web font loaded with @font-face.
3. Sometimes, removing everything
Some webmails keep no <style> block at all. Only styles written directly on the elements, in their style attribute, survive. An email whose styling relies on a stylesheet then arrives completely bare.
On top of that comes a special case: Outlook for Windows, in its classic version, does not display emails with a browser engine but with Microsoft Word’s. Flexbox, CSS grids, most image backgrounds and rounded corners are foreign to it.
Client by client: what breaks most often
| Client | What most often goes wrong |
|---|---|
| Apple Mail (iOS, macOS) | Very permissive. sticky and fixed positioning are ignored, and an email that is too wide is shrunk to fit the iPhone screen. |
| Gmail | <body> replaced, so the background is lost. No positioning, no web fonts, no negative margins. The <style> block is ignored when placed in the <body> or larger than 16 KB. |
| Outlook.com and new Outlook | <body> replaced. relative and absolute positioning refused, negative margins removed, some selectors limited. |
| Yahoo Mail | <body> replaced. Media queries limited to width and height, attribute selectors restricted, absolute positioning refused. |
| Orange | display: flex and display: grid ignored: modern column layouts stack up. |
| SFR and La Poste | <style> blocks removed: only inline styles survive. |
| Outlook for Windows | Word engine: no flexbox or grid, partial max-width, backgrounds and rounded buttons to rebuild in VML. |
These behaviours are publicly documented, feature by feature, by the caniemail.com project, the email coding community’s reference.
Designing a template that holds up everywhere
There is no need to aim for the lowest common denominator. Build a solid base version and add refinements on top.
- Structure with tables. It is the only layout understood everywhere, Outlook for Windows included. Keep flexbox and grids for enhancements that can disappear without breaking the email.
- Inline your styles. Most sending tools convert the stylesheet into
styleattributes automatically before sending. Turn that option on: it is what saves your emails at SFR and La Poste. - Set nothing on the
<body>. Put your background colour on a table wrapping the whole email. - Forget positioning. A badge in
position: absoluteends up top left, or in the middle of the text, in a good half of clients. - Keep media queries as an enhancement. Your email must be readable without them, on mobile as on desktop.
- Handle Outlook for Windows separately, with
<!--[if mso]>conditional comments serving it a table structure and VML buttons. - Prefer PNG and JPG. SVG and WebP do not display everywhere.
- Always give your web fonts a fallback: most webmails will not load them.
Checking before you send
Reading compatibility tables is no substitute for seeing the result. That is why Sender Audit includes, in every test report, a Rendering tab:
- a preview of your email as Apple Mail, Gmail, Outlook.com, Yahoo, Orange, SFR, La Poste and Free should display it;
- the modified areas highlighted, with, for each client, the list of what it reworked and why;
- a compatibility analysis that also covers Outlook for Windows and the mobile apps.
All it takes is a free account: log in, send your email to the address shown on the home page, then open the report’s Rendering tab. The documentation guide explains how to read each screen.