Email Client Targeting CSS: Gmail u + .body, MSO, and Hacks That Still Work
Client targeting is how you apply a rule to Gmail without Outlook seeing it, or to Word-engine Outlook without Gmail seeing it. Used well, it is progressive enhancement with a scalpel. Used as a compatibility score, it is how your Outlook grade goes to 40 for CSS Outlook never loaded.
Target Gmail web with u + .body and Gmail Android with div > u + .body. Target Outlook Classic with <!--[if mso]> conditional comments, not a CSS hack. Prefer documented wrappers (Outlook [data-ogsc], Samsung #MessageWebViewDiv) over parser bugs. A checker that flags Gmail-only CSS as an Outlook failure does not understand targeting.
Why email CSS targeting exists
Gmail, Outlook, and Apple Mail are not three skins on one HTML engine. Gmail web is a sanitizer in front of Blink. Outlook on Windows Classic is Microsoft Word. Apple Mail is WebKit. Samsung Mail, Proton, and Superhuman wrap your markup in their own containers. A property that is legal CSS still only runs if that engine kept the selector and the declaration.
Universal email is still a table, inline color, and a system font stack. That is the baseline covered in the HTML email from-scratch guide. Targeting is the exception: a rule that should fire in one client and must not fire in another. The community catalog for those exceptions lives at howtotarget.email. Most of those snippets are provenance. Only a handful change what Gmail, Outlook, or a wrap-body client actually paints.
A compatibility score that ignores targeting is lying
Support matrices (Can I Email, every linter that copies them) answer: does client X support property Y? That is the right question for unscoped CSS. It is the wrong question for a declaration that only exists inside u + .body .cta.
Outlook never matches that selector. Word never loads that border-radius. If the report still subtracts Outlook points, you are looking at a stylesheet audit, not a render audit. The author did the correct thing: they hid a Gmail-only polish from Word. The tool punished them for it.
That false positive is why Emailens treats targeting as a separate pass. Progressive policy (the default) suppresses compatibility warnings for clients excluded by a targeted selector. Deprecated or dangerous hacks still get flagged. Live Gmail u + .body does not score as css-hack. Paste the email into a free preview and the Client Targeting report lists what matched.
How to target Gmail with CSS: u + .body
Gmail web rewrites the doctype and inserts an empty <u></u> immediately before the node that inherited your body class. Put class="body" on <body>. The adjacent-sibling selector u + .body then matches only in Gmail. Apple Mail and Outlook do not inject that underline, so they skip the rule.
Gmail Android wraps the message. The selector that still fires there is the longer div > u + .body. Keep both if you care about web and Android. Keep the Android selector first if they overlap: the more specific pattern has to win. Gmail iOS is a different app and does not honor this pair the same way. Details of what Gmail strips versus inlines are in the Gmail HTML email guide.
<body class="body">
<style>
/* Gmail web: empty <u></u> sits immediately before .body */
u + .body .cta {
background-color: #111111 !important;
}
/* Gmail Android wraps the message; keep this longer selector */
div > u + .body .cta {
padding: 16px 24px !important;
}
</style>
<table role="presentation" width="100%">
<tr>
<td class="cta" style="background-color:#2563eb;padding:12px 20px;">
<a href="https://example.com" style="color:#ffffff;">Shop now</a>
</td>
</tr>
</table>
</body>The declarations still have to be properties Gmail allows. Targeting does not resurrect display: flex inside Gmail. It only stops Outlook from being blamed for a Gmail-only rule.
Outlook Classic: MSO conditionals, not a CSS hack
Outlook on Windows Classic renders with Word. Word does not implement Gmail's wrapper, does not keep most modern selectors, and does not care about u + .body. The targeting that actually works is a conditional comment Word understands and every other client treats as a comment:
<!--[if mso]>
<table role="presentation" width="600"><tr><td>
<![endif]-->
<div style="max-width:600px;margin:0 auto;">
<!-- everyone else -->
</div>
<!--[if mso]>
</td></tr></table>
<![endif]-->That is a second HTML document for Word, not a selector. Nested <v:rect> inside those comments is VML, which is its own failure mode (a nested shape can blank every button after it). See the Outlook CSS guide and ghost tables. A linter that treats <!--[if mso]> as a smell is grading the wrong engine.
Outlook.com dark mode: [data-ogsc]
Outlook on the web strips @media (prefers-color-scheme: dark). When the user is in dark mode, Outlook injects [data-ogsc] and [data-ogsb] on nodes. Duplicate the dark colors on those attributes. That is documented targeting, not a parser bug. The full color-inversion picture is in the dark mode email CSS guide.
<style>
@media (prefers-color-scheme: dark) {
.card { background-color: #141519 !important; color: #f4f4f5 !important; }
}
[data-ogsc] .card,
[data-ogsb] .card {
background-color: #141519 !important;
color: #f4f4f5 !important;
}
</style>Wrap-body clients: Samsung, Proton, Superhuman
Some clients wrap your body contents in an id or class you can hang a selector on. Samsung Mail uses #MessageWebViewDiv. Proton uses #proton-root. Superhuman uses a Shadow DOM class on the wrapper. A rule that starts with those ids only runs after the wrap exists. Everyone else never matches.
These are useful for a padding or font fix in one app. They are a poor substitute for a table layout. If the wrap id changes in a client update, the override vanishes and you will not see it in Gmail.
Which targeting hacks are deprecated
Webmail ships continuously. A selector that exploited invalid CSS (an unescaped comment, a bogus media query, a star in an id) often matched one sanitizer in 2018 and nothing in 2026. Two that still show up in copied snippets:
_:-webkit-full-screencombinators aimed at old WebKit webmail. They are not how you target Gmail today.- Yahoo / AOL star ids and related attribute tricks that one of the two now strips. Yahoo still has working wrap selectors. The star id is not the one to copy.
Generate current snippets from the client targeting generator, then paste the compiled email into a preview. If a hack is deprecated, the report should say so. If it is live and scoped, Outlook should not lose points for it.
What to do instead of collecting hacks
- Layout in tables so Word has something to paint. Targeting does not replace ghost tables.
- Inline the CSS Gmail must keep, and keep a
<style>block for media queries and targeting selectors. See CSS inlining for email. - MSO comments for Outlook Classic, VML only where a background or button actually needs it.
- One documented override when a single client still mis-paints: Gmail
u + .body, Outlook[data-ogsc], Samsung wrap id. Not a pile of 2016 snippets.
Frequently Asked Questions
How do you target Gmail with CSS?
Gmail web injects an empty <u></u> immediately before the element that inherited your body class. Put class="body" on <body> and write u + .body .your-class in a <style> block. Gmail Android uses the more specific div > u + .body. Other clients do not inject that <u>, so they ignore the rule.
How do you target Outlook desktop (Word engine)?
Do not use a CSS selector hack for Outlook Classic. Word does not run the same CSS as Gmail. Use MSO conditional comments: <!--[if mso]> for Outlook-only markup and <!--[if !mso]><!--> to hide modern CSS from Word. That is a compile-time branch, not a CSS trick.
Why does my Outlook compatibility score tank when I only styled Gmail?
Most support matrices grade every property against every client. border-radius inside u + .body is Gmail-only CSS. Outlook never sees it. A checker that still counts it as an Outlook failure is scoring the stylesheet, not the render. Targeting-aware analysis suppresses those false positives.
Which email CSS targeting hacks are deprecated in 2026?
Hacks that depended on a parser bug usually die when the client ships a sanitizer update. _:-webkit-full-screen combinators and the old Yahoo star id are the usual examples: they used to match one webmail, then they matched nothing or the wrong thing. Prefer documented wrappers (Gmail's <u>, Outlook [data-ogsc], MSO comments) over invalid CSS.
Is client targeting the same as progressive enhancement?
No. Progressive enhancement ships a table layout everyone can render, then adds CSS for clients that support it. Targeting writes a rule that only one client will apply. Use targeting for a stubborn override (Gmail Android padding, Outlook dark-mode color). Do not use it as the layout.
See which targeting you already shipped
Paste HTML, MJML, or React Email. The Client Targeting report lists live techniques, flags deprecated ones, and stops Outlook from eating the score for Gmail-only CSS.
Preview your emailFree, no account. Generator: /tools/client-targeting
- •HowToTarget (Parcel / Customer.io): How to Target Email Clients
- •Google Workspace Developers: CSS Support in Gmail
- •Microsoft Learn: Word HTML and CSS Rendering in Outlook
- •Can I Email: CSS and HTML Support in Email Clients
Reviewed by Philippe KAM · Last updated: Sep 22, 2026
Building next-generation email preview and QA infrastructure for developers. Focused on reverse-engineering rendering engines across Outlook (Word MSO & New Outlook), Gmail, and Apple Mail to eliminate email rendering bugs before dispatch.