Dark mode support in email splits three ways, and only one of them is the CSS most senders design for. Some clients honor @media (prefers-color-scheme: dark) exactly as written. Others silently rewrite it into syntax that can never match, then fall back to their own auto-inversion heuristics instead. A third group barely acknowledges the newer color-scheme meta tag at all. Designing for the first group alone means designing for less than half the inbox.
Group one: clients that honor the media query
Per caniemail.com, @media (prefers-color-scheme: dark) is fully supported in Gmail (all platforms) and Apple Mail (macOS 12.4+ / iOS 13.0+). Outlook is close behind across most of its surfaces — Windows (2016+), macOS (16.70+), Outlook.com (2019-07+), and mobile (2020-01+) all recognize the query, though macOS Outlook and Outlook.com additionally apply their own dark-mode data attributes alongside it. Samsung Email (Android 6.1+) also fully implements it. Combined, caniemail.com's tested panel puts overall support at 41.86% — a real majority of major clients, but far from all of them.
Group two: clients that rewrite the query into something that never matches
This is the group that actually produces the broken-looking dark-mode emails most senders have seen. Yahoo Mail, AOL, and Fastmail don't ignore prefers-color-scheme outright — they rewrite it into invalid syntax (@media ( _filtered_a )) that can never evaluate true, silently disabling every rule inside it. HEY does the equivalent by rewriting the query to @media (false). In both cases, the client then falls back to its own automatic color-inversion heuristics on the original light-mode design — which is exactly what produces washed-out logos and unreadable low-contrast text nobody explicitly designed for, because nothing the sender wrote is actually driving the result.
Group three: the color-scheme meta tag, barely adopted
<meta name="color-scheme" content="light dark"> (and its supported-color-schemes cousin) exists to tell a client which mode(s) an email is deliberately designed for, so the client can skip auto-inversion entirely rather than guess. It's the more surgical fix — but per caniemail.com, adoption sits at only 4.88% combined, with meaningful support limited to newer Apple Mail (macOS 16+ / iOS 12.4+) and Gmail desktop webmail (2023-09+). Most other clients ignore it outright.
What this means for design
No single CSS rule covers all three groups at once — that's the direct consequence of the split above, not a gap in any one technique. The dependable approach is progressive enhancement, the same principle Litmus's dark mode guide lands on:
- Design a solid, fully readable light-mode email first. It's the baseline every client falls back to, including the auto-inverting ones in group two.
- Layer explicit
prefers-color-schemeoverrides on top, for the ~42% of clients that will actually apply them — don't rely on the meta tag alone given its far lower adoption. - Bulletproof logo and image assets against auto-inversion: a semi-transparent PNG on a hard white background can invert into an unreadable dark-on-dark mess in group two's clients. A subtle border or a solid background swatch behind the asset survives inversion in a way a naked transparent PNG doesn't.
- Never assume a dark background implies dark-mode-aware text color — group two's auto-inversion can flip a background without touching text the way a sender expects, so explicitly-set text colors matter more under dark mode, not less.
See Email client support for the same per-client breakdown applied to MailInApp's own studio and fallback engine.