Dark Mode and Email: What Every Marketer Needs to Know

About 35% of email opens now happen in dark mode. That number has been climbing steadily since Apple, Google, and Microsoft added dark mode options to their mail clients, and it's not going back down. If you've never tested one of your campaigns in dark mode, there's a one-in-three chance a chunk of your audience is seeing something you didn't design.

We've built email templates across Pardot, Mailchimp, Salesforce Marketing Cloud, and custom transactional systems. The dark mode problem comes up in every single engagement now. Logos vanish. Buttons become unreadable. Carefully chosen brand colours get replaced by something a client's algorithm decided was close enough. And because every email client handles dark mode differently, fixing it for Gmail can break it for Outlook.

How Email Clients Actually Handle Dark Mode

Dark mode on the web is relatively straightforward. You write a prefers-color-scheme: dark media query, define your dark palette, and browsers respect it. Email clients took that concept and splintered it into three completely different behaviours.

No colour changes. Some clients leave your email alone in dark mode. They darken the UI chrome around the email (the sidebar, the toolbar, the header) but don't touch your HTML. The email renders exactly as you designed it, sitting inside a dark shell. Apple Mail does this by default unless you specifically provide dark mode styles. Your light-background email will look like a bright window floating in a dark room, which isn't ideal but at least nothing breaks.

Partial colour inversion. The client selectively changes some colours. Light backgrounds get darkened. Dark text gets lightened. But not everything changes, and not consistently. Outlook's desktop and web apps fall into this category, and the results are unpredictable. You might end up with dark text on a dark background where the client changed the background but not the text colour. Buttons are the most common casualty here.

Full colour rewriting. The client applies its own algorithm to invert your entire colour scheme. Gmail on iOS and Android does this. You have zero CSS control over it because Gmail doesn't support the prefers-color-scheme media query. The client reads your colours, runs them through an inversion algorithm, and serves the result to the user. Sometimes the result is fine. Sometimes your brand's deep navy blue becomes a washed-out grey that looks like a rendering error.

According to Campaign Monitor's developer guide on dark mode, the client's transformation happens after your email loads. It's applied at the rendering level, not the HTML level. There is no CSS hack that universally prevents it.

If a third of your subscribers are viewing your emails in dark mode and you've never tested for it, you don't actually know what your emails look like.

The Specific Things That Break

Knowing the three rendering behaviours is useful, but what you really need is a list of what goes wrong in practice. These are the failures we see most often when auditing email templates that weren't built with dark mode in mind.

Logos on white backgrounds disappear. If your logo is a dark graphic on a white or transparent background, and the client inverts the background to near-black, that logo vanishes. This is the single most common dark mode email failure, and it's the one most likely to make your brand look unprofessional.

Buttons become unreadable. A white CTA button with dark text gets its background inverted to dark. Now you have dark text on a dark background. The button is still there in the HTML, but nobody can read it. We see this constantly in Pardot templates that were built before dark mode was a real consideration.

Text contrast collapses. You chose a dark grey text colour (#333333) for readability on white. The client inverts the background but leaves the text, or inverts the text to a lighter shade that doesn't have enough contrast against the new background. Either way, your carefully tested contrast ratios are gone. This ties directly into accessibility concerns because WCAG's 4.5:1 contrast ratio doesn't just apply to websites.

Images with solid backgrounds clash. A product photo with a white background looks perfectly natural in a light email. In dark mode, that white rectangle becomes a glowing box floating against a dark background. It draws attention to the wrong thing and makes the design feel broken.

Coloured sections lose their hierarchy. If you use background colours to create visual sections in your email (a grey header band, a white content area, a coloured footer), dark mode inversion can make them all look the same shade of dark grey. Your visual hierarchy disappears.

Writing CSS for Dark Mode Emails

The technical implementation comes down to two approaches: controlling what you can, and degrading gracefully where you can't.

For clients that support prefers-color-scheme (Apple Mail, Outlook on macOS, some versions of Outlook.com, and the Hey email client), you can define a full dark mode colour scheme. Start by declaring support in the <head>:

<meta name="color-scheme" content="light dark">
<meta name="supported-color-schemes" content="light dark">

Then add the corresponding CSS declarations:

:root {
  color-scheme: light dark;
  supported-color-schemes: light dark;
}

Your dark mode overrides go inside a media query in your <style> block:

@media (prefers-color-scheme: dark) {
  .email-body {
    background-color: #1a1a1a !important;
    color: #f1f1f1 !important;
  }
  .header-text {
    color: #ffffff !important;
  }
  .cta-button {
    background-color: #2a7d6e !important;
  }
}

The !important declarations are required. Without them, the client's own dark mode styles will override yours. In normal web development, !important is a code smell. In email, it's survival.

For image swapping between light and dark modes, you can use a CSS display toggle:

.light-logo { display: block; }
.dark-logo { display: none; }
@media (prefers-color-scheme: dark) {
  .light-logo { display: none !important; }
  .dark-logo { display: block !important; }
}

This lets you show a light-coloured version of your logo in dark mode and the standard version in light mode. Keep both images in your HTML and toggle visibility with CSS. As Litmus's technical guide to dark mode coding recommends, transparent PNGs should be your starting point, with image swapping reserved for cases where a transparent version won't work.

The Outlook Problem (Again)

Outlook.com has its own dark mode targeting mechanism that runs alongside standard CSS. When Outlook's dark mode activates, it applies data-ogsc (original style colour) and data-ogsb (original style background) attributes to your elements and uses them to decide which colours to override. To target Outlook specifically, you need to duplicate your dark mode styles with these attribute selectors:

[data-ogsc] .header-text {
  color: #ffffff !important;
}
[data-ogsb] .email-body {
  background-color: #1a1a1a !important;
}

This is separate from your prefers-color-scheme block. You need both. Litmus and Email on Acid both document this pattern, and if you're not including the [data-ogsc] rules, your Outlook.com dark mode rendering is entirely at the client's discretion.

For Outlook's desktop Word engine, you're mostly out of luck. The classic desktop Outlook (2007-2021) applies its own dark mode transformation and largely ignores CSS dark mode declarations. The new Chromium-based Outlook is better, but as we covered in our guide to HTML emails that work everywhere, the transition period means both versions are actively in use.

What About Gmail?

Gmail strips prefers-color-scheme media queries entirely. On desktop web, Gmail's dark mode makes minimal changes. On iOS and Android, it applies full colour inversion that you cannot override with CSS.

There are a few documented workarounds. Setting image heights to at least 54 pixels can prevent Gmail from inverting certain image colours, a quirk that email developer Remi Parmentier documented on GitHub. Using slightly off-pure colours (#FEFEFE instead of #FFFFFF) can change how aggressively Gmail's algorithm inverts specific elements. And mix-blend-mode hacks exist that preserve button text colours in some cases.

But these are fragile workarounds, not reliable fixes. Gmail's dark mode rendering changes with app updates and differs between Android and iOS. The honest recommendation: design your emails so that automatic inversion produces an acceptable result, then use prefers-color-scheme as a progressive enhancement for clients that support it.

Testing Dark Mode Emails (Without Losing Your Mind)

Testing is where this all comes together, and where most teams cut corners because the matrix of client-mode-device combinations feels overwhelming.

You don't need to test every combination. You need to test the ones your audience actually uses. Your ESP (Mailchimp, Pardot, Campaign Monitor, whatever you're using) can tell you which email clients your subscribers open with. If 60% of your audience uses Apple Mail and Gmail, those are your primary targets. If you have a large enterprise audience on Outlook, Outlook testing is non-negotiable.

Litmus and Email on Acid both offer dark mode previews across multiple clients. Can I Email tracks which CSS features are supported in each client, including prefers-color-scheme. Their data shows support in Apple Mail (iOS and macOS), Outlook for macOS, the Hey app, and Thunderbird, with no support in Gmail, Yahoo Mail, or Outlook desktop. That support list is your guide for deciding where CSS dark mode styles will actually fire and where you're relying on graceful degradation.

Here's a practical testing workflow:

First, test in Apple Mail dark mode. This is the client that gives you the most control. If your prefers-color-scheme styles are correct, Apple Mail will render them accurately. This is where you validate your dark colour palette, image swaps, and text contrast.

Second, test in Gmail on iOS. This shows you the worst case: full automatic inversion with no CSS override. If your email is still readable here, it'll survive anything.

Third, test in Outlook.com dark mode. This validates your [data-ogsc] and [data-ogsb] styles and catches the partial inversion issues that make buttons unreadable.

Fourth, send a real test to Outlook desktop. No preview tool perfectly replicates Outlook's Word rendering engine. The only way to know for certain is to send an actual test email and open it in the actual client with dark mode on.

If your campaigns aren't performing the way they should and you can't figure out why, dark mode rendering is one of the things worth investigating. We wrote about the broader diagnostic process in our guide to email campaigns that aren't converting.

A Practical Starting Point

If you're staring at your existing email templates and wondering where to begin, start with your transactional emails. Order confirmations, password resets, welcome sequences. These are high-open-rate messages that your customers actually read, and they're usually simpler templates that are easier to retrofit.

Swap any logo with a solid white background for a transparent PNG version with a subtle stroke. Add the color-scheme meta tags and CSS root declaration. Write a prefers-color-scheme media query that covers your background colours, text colours, and button styles. Test in Apple Mail and Gmail iOS. Fix what breaks. Then apply the same pattern to your marketing templates.

The goal is not pixel-perfect dark mode rendering across every client. That's not possible with the current state of email client support, and chasing it is a waste of time. The goal is making sure nothing in your emails becomes unreadable, invisible, or embarrassing when a subscriber's device is set to dark mode.

We build and audit email templates as part of our email marketing and development services, and dark mode testing is now a standard part of every engagement. A third of your audience is already seeing the dark mode version of your emails. The question is whether you've seen it too.

Sources

• Litmus: The Ultimate Guide to Dark Mode for Email Marketers -- Dark mode behaviour across email clients, CSS strategies, and image handling techniques
• Litmus: The Developer's Technical Guide to Coding Dark Mode Emails -- Code-level implementation for prefers-color-scheme, image swaps, and Outlook targeting
• Campaign Monitor: The Developer's Guide to Dark Mode in Email -- Meta tag implementation, the three dark mode behaviours, and client-specific rendering differences
• Can I Email: @media (prefers-color-scheme) Support -- Feature support table showing which email clients support prefers-color-scheme
• Email on Acid: Dark Mode for Email -- Design and coding techniques for dark mode compatibility
• Mailmodo: Dark Mode Email Statistics -- Usage statistics on dark mode adoption across devices and email clients
• GitHub: Gmail Dark Mode Email Bugs (hteumeuleu/email-bugs) -- Documented Gmail dark mode inversion behaviour and workarounds from Remi Parmentier
• Parcel: Guide to Color Scheme in Email -- Technical reference for color-scheme and supported-color-schemes implementation