Tailwind CSS between Outlook, Gmail, and Apple Mail
An email template built with Tailwind CSS can look completely different in Outlook on Windows than in Gmail, because both clients use different rendering engines with their own restrictions. Anyone taking email client compatibility seriously needs to know these differences and address them with targeted fallbacks.
Table of Contents
- 1. The fragmented rendering landscape of email clients
- 2. Outlook on Windows: Word as the rendering engine
- 3. Gmail: server-side CSS stripping and lost classes
- 4. MSO conditional comments for Outlook-specific markup
- 5. VML fallbacks for background images and rounded buttons
- 6. Gmail-safe selectors and the head problem
- 7. Dark mode in email clients
- 8. A testing workflow without an expensive testing tool
- 9. Client quirks compared directly
- 10. Summary
- 11. FAQ
1. The fragmented rendering landscape of email clients
In web frontend work today, it's largely enough to develop against the Chrome and Firefox rendering engines, because both support a very similar, modern CSS feature set. For email client compatibility, the exact opposite is true: Outlook on Windows, Gmail on the web, Gmail in the app, Apple Mail, Outlook on iOS, and various other clients each use their own, sometimes decades-old rendering engines with completely different CSS restrictions. A Tailwind CSS template that looks flawless in the browser can break completely in one of these clients.
The reason for this fragmentation is historically rooted in security concerns: email providers want to prevent HTML emails from enabling tracking, phishing, or layout manipulation through CSS or JavaScript. That's why many clients aggressively filter what they pick up from the <head> and from <style> blocks. Email client compatibility therefore doesn't mean finding the smallest common denominator, but building targeted special handling for the most problematic clients, while the rest of the template is developed normally with Tailwind classes.
2. Outlook on Windows: Word as the rendering engine
The single biggest factor for poor email client compatibility is Outlook on Windows in versions 2007 through 2021 as well as Microsoft 365. These versions don't use a web rendering engine but rather Microsoft Word's layout engine to display HTML emails. Word doesn't support flexbox, doesn't support CSS grid, has no border-radius property for rounded corners, and no background-image property on arbitrary elements. A template built with modern Tailwind utility classes like flex or rounded-xl collapses in this Outlook down to a base structure without these effects.
The practical consequence for email client compatibility: layout must necessarily be built with nested HTML <table> elements, because tables are reliably supported by Word, while flexbox and grid are ignored. Tailwind classes for padding and colors can be applied to table cells without issue, as long as they ultimately arrive as classic CSS properties like padding and background-color, instead of relying on modern layout mechanisms.
/* Word's rendering resets many defaults — reset spacing explicitly */
table, td { border-collapse: collapse; mso-table-lspace: 0pt; mso-table-rspace: 0pt; }
p, td { margin: 0; }
<!-- Table-based layout survives Outlook's Word rendering engine -->
<table role="presentation" width="100%" cellpadding="0" cellspacing="0">
<tr>
<td class="px-6 py-8 bg-sky-600" align="center">
<!-- Simple utility classes for padding and color work fine here -->
<p class="text-white font-bold text-lg m-0">Welcome to Mironsoft</p>
</td>
</tr>
</table>
3. Gmail: server-side CSS stripping and lost classes
Gmail behaves fundamentally differently from Outlook, but causes equally serious problems for email client compatibility. When displaying an email, Gmail server-side generates its own, renamed CSS classes from a <style> block and rewrites them into its own, encapsulated stylesheet. This works well for simple selectors, but fails for more complex selectors like child combinators, attribute selectors, or certain pseudo classes, which Gmail partially drops during rewriting.
An additional problem: the Gmail app on Android and iOS doesn't support <style> blocks in the head section at all in older versions, and requires fully inline styles for reliable display. For maximum email client compatibility, it's therefore recommended to also set critical Tailwind rules like background color, text color, and padding as inline styles by default, even when a <style> block exists in the head, because inline styles work across virtually all Gmail variants, while the style block only takes effect in some of them.
4. MSO conditional comments for Outlook-specific markup
Microsoft Office applications understand a special comment dialect, known as MSO conditional comments, which allows HTML fragments to be shown exclusively for Outlook, without other clients ever seeing them. The syntax <!--[if mso]>...<![endif]--> is only interpreted by Outlook; all other clients treat the entire block as a normal HTML comment and ignore it completely. This makes MSO conditional comments the most important tool for targeted Outlook-specific handling, without affecting rendering in modern clients.
In practice these comments are used to insert an additional fixed-width table structure for Outlook, while modern clients see the more flexible, more responsive Tailwind structure directly. They can also be used to inject Outlook-specific font size corrections, because Word sometimes computes different line heights during text rendering than WebKit-based clients, which without correction leads to inconsistent line spacing.
<!-- MSO-only block: fixed-width table wrapper visible only in Outlook -->
<!--[if mso]>
<table role="presentation" width="600" align="center"><tr><td>
<![endif]-->
<div class="max-w-[600px] mx-auto">
<!-- Modern clients render this responsive div directly -->
<p class="px-6 py-4">Thank you for your order</p>
</div>
<!--[if mso]>
</td></tr></table>
<![endif]-->
5. VML fallbacks for background images and rounded buttons
Because Outlook's Word engine doesn't support background-image on arbitrary elements, hero sections with a background image, as commonly used in Tailwind layouts with bg-cover, can't be carried over directly. The solution is VML, Vector Markup Language, an old Microsoft graphics standard supported by Word, with which a background image can be placed behind text as its own graphic element via an MSO conditional comment. This requires additional markup effort but is the only reliable method for background images that actually become visible in Outlook.
Rounded buttons behave similarly: a button link styled with the Tailwind class rounded-lg shows square corners in Outlook because border-radius is ignored. The common workaround combines a VML roundrect as an Outlook fallback with a normal, CSS-styled <a> element for all other clients, with MSO conditional comments deciding which variant gets rendered in each case.
<!-- VML fallback for a rounded button, visible only in Outlook -->
<!--[if mso]>
<v:roundrect xmlns:v="urn:schemas-microsoft-com:vml" href="https://mironsoft.de"
style="height:44px;v-text-anchor:middle;width:220px;" arcsize="15%" fillcolor="#0284c7">
<center style="color:#ffffff;font-weight:bold;">Order now</center>
</v:roundrect>
<![endif]-->
<!--[if !mso]><!-->
<a class="inline-block bg-sky-600 text-white font-bold py-3 px-6 rounded-lg"
href="https://mironsoft.de">Order now</a>
<!--<![endif]-->
6. Gmail-safe selectors and the head problem
For reliable email client compatibility with Gmail, CSS selectors in the remaining <style> block should be kept as simple as possible. Single class selectors like .button work reliably, while combinators like .card > .button or attribute selectors like [data-variant="primary"] are sometimes not correctly carried over by Gmail's rewriting mechanism. Media queries inside the style block work in Gmail on the web and in the desktop app, but inconsistently in the mobile Gmail app, depending on the operating system version.
Another detail: some Gmail versions strip the entire <head> section when an email is processed through certain forwards or auto-replies. In this case, all style block rules are lost, regardless of how simple the selectors were. This is why the most robust strategy for high email client compatibility remains setting all layout-critical properties additionally inline and using the style block only for progressive enhancements like hover effects or media queries.
/* Gmail-safe: simple single-class selectors survive the rewriting step */
.button { background-color: #0284c7; padding: 12px 24px; }
/* Risky in Gmail: combinators and attribute selectors are often dropped */
.card > .button { margin-top: 8px; }
[data-variant="primary"] { font-weight: 700; }
7. Dark mode in email clients
More and more email clients offer a system-wide dark mode that automatically inverts an email's background and text colors, sometimes without regard for the original design. Apple Mail and Outlook.com invert aggressively, which can lead to unexpected color combinations in a Tailwind-built template with a light background and dark text if no explicit dark mode rules are present. For email client compatibility with dark mode, there are the meta tags <meta name="color-scheme" content="light dark"> and <meta name="supported-color-schemes" content="light dark">, which signal to the client that the template itself brings its own dark theme.
Inside an @media (prefers-color-scheme: dark) block in the remaining style tag, custom colors for dark mode can then be defined, which are respected by clients that support this media query. For clients without this support, aggressive automatic inversion remains a residual risk, best mitigated through deliberately neutral base colors and sufficient contrast in both variants.
<!-- Signal that this template ships its own dark theme -->
<meta name="color-scheme" content="light dark">
<meta name="supported-color-schemes" content="light dark">
<style>
@media (prefers-color-scheme: dark) {
.bg-white { background-color: #1e293b !important; }
.text-slate-900 { color: #f1f5f9 !important; }
}
</style>
8. A testing workflow without an expensive testing tool
Commercial services like Litmus or Email on Acid render an email template in dozens of real client versions and return screenshots, which is the most reliable way to systematically check email client compatibility. For smaller projects or a limited budget, a scaled-down workflow can be built: a virtual machine with an older Outlook version for the most critical Word rendering tests, a real Gmail account for sending test emails to yourself, and an iOS as well as an Android device for the mobile variants of Gmail and Apple Mail.
A checklist approach helps additionally: after every change to the Tailwind template, the known problem areas are specifically re-checked, rounded corners, background images, media query behavior, and dark mode display. This focused test covers most email client compatibility problems without having to run a full multi-client test for every small change.
9. Client quirks compared directly
The following overview summarizes the most important differences that most strongly influence the email client compatibility of a Tailwind-based template.
| Client | Rendering engine | Critical limitation | Recommended fallback |
|---|---|---|---|
| Outlook Windows | Microsoft Word | No flexbox, grid, border-radius | Table layout, VML for images/buttons |
| Gmail (web/app) | Custom CSS rewriter | Complex selectors get lost | Inline styles for critical rules |
| Apple Mail | WebKit | Very good CSS support | Little special handling needed |
| Outlook.com | Custom web engine | Aggressive dark mode enforcement | Set color-scheme meta tags |
This table shows that real email client compatibility is not a random outcome, but the result of targeted fallbacks for exactly the clients furthest from modern CSS. Anyone who explicitly addresses Outlook and Gmail covers the vast majority of all compatibility problems in practice, because Apple Mail and most other clients already support modern CSS well.
# Manual pre-send checklist, run after every template change
echo "1. Rounded corners visible in Outlook VML fallback?"
echo "2. Background image visible in Outlook via VML?"
echo "3. Media query behavior consistent across Gmail variants?"
echo "4. Dark mode colors readable in Apple Mail and Outlook.com?"
echo "5. Inline styles present for every layout-critical property?"
Mironsoft
Tailwind CSS, HTML email, and client compatibility for Magento stores
Emails that look equally good in Outlook and Gmail?
We build Tailwind-based email templates with MSO conditional comments, VML fallbacks, and Gmail-safe inline styles, tested in the most critical real clients.
Outlook fallbacks
MSO conditional comments and VML for buttons and background images
Gmail hardening
Inline styles for all critical rules, independent of the style block
Multi-client testing
Checking in real Outlook, Gmail, and Apple Mail environments
10. Summary
Email client compatibility for Tailwind CSS based templates mostly means specifically addressing the two most problematic extremes: Outlook on Windows with its restrictive Word rendering engine, and Gmail with its server-side CSS rewriter. Table layouts instead of flexbox, MSO conditional comments for Outlook-specific markup, VML fallbacks for background images and rounded buttons, and consistent inline styles for critical rules together form the basis for reliable display.
Apple Mail and most other modern clients already support the majority of the CSS generated by Tailwind without special handling. Anyone who applies the techniques described in this article specifically for Outlook and Gmail, and then tests the template in real client environments, achieves email client compatibility that in practice works reliably for the vast majority of inboxes.
<!-- Minimal skeleton combining the most important compatibility fixes -->
<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<meta name="color-scheme" content="light dark">
<meta name="supported-color-schemes" content="light dark">
<!--[if mso]>
<noscript><xml><o:OfficeDocumentSettings><o:PixelsPerInch>96</o:PixelsPerInch></o:OfficeDocumentSettings></xml></noscript>
<![endif]-->
</head>
<body>
<!-- table-based content with inline styles goes here -->
</body>
</html>
Email Client Compatibility with Tailwind CSS — Key Takeaways
Outlook Windows
Word rendering engine without flexbox, grid, and border-radius. Table layout and VML fallbacks are mandatory.
Gmail
Server-side CSS rewriting drops complex selectors. Set critical rules additionally inline.
MSO and VML
Conditional comments show Outlook-specific markup selectively, without affecting other clients.
Testing
Check real Outlook, Gmail, and Apple Mail environments, supplemented by a focused problem-area checklist.