Designing for Dark Mode: What Actually Breaks in Email

Dark mode stopped being a niche preference a while ago. Litmus's tracking puts it at roughly 35% of all email opens, and on Gmail's mobile app specifically, about a third of users have it turned on. Set against that, only 11% of marketers say they always design for dark mode, with another 44% doing it at least sometimes. That gap, a third of your opens against roughly half your peers actually planning for it, is exactly where logos disappear and buttons go invisible.

Each client decides for itself, and that's the actual problem

Dark mode in email isn't one behavior, it's three or four different ones depending on which client opens the message. Apple Mail respects the @media (prefers-color-scheme: dark) query if you've written one, and if you haven't, it just leaves your light-mode email alone rather than guessing. Gmail does the opposite: it strips prefers-color-scheme out entirely and applies its own automatic color-inversion algorithm regardless of what you coded, which is why an email with zero dark-mode CSS can still show up half-inverted in Gmail. Outlook splits down the middle again, Outlook.com partially inverts colors, while Outlook 2021 on Windows fully inverts. Three clients, three different sets of rules, and no single piece of CSS controls all of them.

What actually breaks

• Transparent PNG logos. A logo saved with a transparent background inherits whatever color sits behind it. A black wordmark on transparency turns invisible the moment the client flips the background to black, or gets an ugly white halo if only part of the image gets inverted.
• Buttons that vanish. A button whose background color happens to land close to the auto-inverted surrounding background effectively disappears, readable text on an invisible button.
• Colors chosen for contrast that stop working. A palette built for a white background can land on genuinely unreadable combinations once the background auto-inverts and the text color doesn't move with it.

Two legitimate ways to handle it, not one

The advice that circulates most is "design a proper dark mode": add meta name="color-scheme" content="light dark" and meta name="supported-color-schemes" content="light dark" to the head, mirror them in a :root { color-scheme: light dark; } CSS rule, then write an explicit @media (prefers-color-scheme: dark) block with your own chosen dark palette instead of leaving it to each client's guesswork. Swap transparent logos for versions with a solid background, or provide a separate dark-mode logo asset. Done properly, this gives you control over exactly what a dark-mode reader sees instead of hoping the auto-inversion lands somewhere reasonable.

The other legitimate option is simpler: skip adaptive dark mode entirely and force light mode with meta name="color-scheme" content="light" alone. That's not a cop-out, it's a real, commonly used choice, and it sidesteps the whole inconsistent-auto-inversion problem rather than trying to out-design it. The tradeoff is honest too: some dark-mode readers will see a bright email land in an otherwise dark interface, which a fraction of people mildly dislike, versus the alternative risk of an invisible logo or an unreadable button if the adaptive approach isn't executed carefully everywhere.

Device dark mode and app dark mode aren't the same number

One distinction worth knowing before you decide how much effort this deserves: roughly 37% of iOS devices have dark mode enabled at the operating system level, but only about 7.5% of Apple Mail opens actually render dark. Turning on dark mode for your phone doesn't automatically mean every app, including Mail, follows along. If you're trying to judge how much this matters for your own list, check your ESP's actual dark-mode-open percentage rather than assuming device-level adoption numbers translate directly into what your subscribers see.