uCheckeruChecker
Blog/Best Practices
9 min read

Email in dark mode: how to design without breaking it

More than half your subscribers keep dark mode on all the time. Your crisp white email lands in their inbox as something unpredictable: inverted colors, vanishing text, a logo floating on a black square. Every email client handles dark mode differently, and there is no shared standard. This guide covers concrete fixes for each scenario.

Who actually sees your emails in dark mode

According to Android Authority's 2025 data, about 82% of Android users have dark mode enabled. On iOS, the figure is around 70%. Desktop numbers are lower, but macOS and Windows both offer system-level dark mode, and Outlook, Apple Mail, and Thunderbird pick it up automatically.

So the majority of your subscribers are not seeing what you designed. White backgrounds turn dark gray or black. Dark text flips to light. A logo drawn against a white backing sticks out as a bright rectangle in the middle of a dark layout. All of this happens without your involvement, because the email client decides how to invert colors on its own.

The problem is worse because there is no single mechanism. The three largest email clients each handle dark mode in a different way, and email developers have to account for all three.

Three rendering models: how clients invert your email

The first model: no changes. The client leaves your HTML and CSS alone. The email looks exactly as coded. Some versions of Yahoo Mail and AOL work this way. No inversions, but if your background is white, subscribers get a blinding rectangle inside a dark interface.

The second model: partial inversion. The client only swaps light backgrounds to dark and adjusts text colors to match. If you already have a dark background, it leaves it alone. Apple Mail does this. It is the cleanest approach and causes the fewest surprises, though elements with specific hex values set via inline styles can still break.

The third model: full inversion. The client rewrites all colors: backgrounds, text, links, borders. Outlook on Windows and mobile does this aggressively. Gmail for Android applies its own palette. The results are unpredictable. White text on a white background, a dark button on a dark background, invisible dividers, these are all side effects of full inversion.

Gmail deserves a separate note because it behaves differently by platform. Gmail on the web does not invert at all. Gmail on Android in dark mode applies its own recolor. On iOS it sometimes inverts, sometimes does not, depending on the app version. Testing Gmail once is not enough; you need to test it on each platform separately.

What breaks most often

Logos. The most common casualty. A JPEG or PNG with a white background becomes a white patch in dark mode. The fix is obvious: use a PNG with a transparent background. But that is not enough on its own. A dark-colored logo on a transparent background disappears into a dark email background after inversion. You need either a light outline or two logo versions, one for each theme.

CTA buttons. If the button is styled with a dark background-color and white text inside, inversion can turn the background light while leaving the text white. The result: invisible label on the button. Or the reverse, dark text on a dark button.

Dividers and borders. A thin gray line on a white background is a classic way to break up an email into sections. After inversion, that gray line can become invisible on a dark background, or turn into a harsh white stripe.

Icons. SVG support in email is close to nonexistent, so icons are usually raster images. A black icon on a transparent background vanishes in dark mode. Same situation as the logo: you need an outline, a background swatch, or an alternate version.

Dark mode does not break emails. Emails break because they were designed only for light backgrounds. That is a design-thinking problem, not a rendering one.

The CSS approach and its limits

In theory, @media (prefers-color-scheme: dark) solves everything. You write alternate styles for dark mode and the client applies them. In practice, this media query has full support only in Apple Mail and partial support in Outlook for macOS. Gmail ignores it entirely. Outlook for Windows ignores it too. Samsung Mail supports it partially.

The media query is a useful tool, not a strategy. You cannot write dark theme styles via prefers-color-scheme and call it done. More than half your audience will never see those styles. The right approach works in reverse: first make sure the email degrades acceptably under any inversion without special styles. Then layer in the media query as an improvement for clients that support it.

The practical pattern: dark mode rules go inside a <style> block, while for clients without media query support you rely on inline styles that survive inversion without catastrophic results. Two layers of protection instead of one.

Concrete fixes for common problems

Logo. Prepare two versions: one for light theme and one for dark. Show the right one via media query. For clients without media query support, use the transparent-background version and add a thin semi-transparent outline. It is invisible on light backgrounds but provides contrast on dark ones. Alternatively, set a background-color on the logo cell. Even if the client inverts the surrounding area, the cell keeps its color.

Buttons. Avoid pure white or pure black button backgrounds. Bright colors, blue, green, orange, hold up better under inversion. The client may shift the hue, but the button stays visible and readable. Set the text color inside the button explicitly via inline color. Do not rely on inheritance. Under inversion it behaves unpredictably.

Background colors. Drop pure white #ffffff as your email background. Use #f5f5f5 or #fafafa. The visual difference is minimal. Some clients, Apple Mail included, only invert #ffffff and leave near-white values alone. That gives you control: the background stays light gray rather than flipping to black.

Text. Always set text color explicitly. Every <td>, every <p>, every <a> needs an inline color. Without it, the client assigns one. Usually fine, but Outlook occasionally changes text color without touching the background, producing light text on a light surface.

Images with baked-in text. Text inside an image does not get inverted. White text on a dark banner stays white. Black text on a light one stays black, because the image is never recolored. But image-embedded text is invisible to screen readers, does not scale on mobile, and is not indexed. Use it only for decorative elements, never for content.

Outlook: its own category of pain

Outlook for Windows renders HTML through the Word engine. That alone causes plenty of problems, and in dark mode it adds another: its own [data-ogsc] and [data-ogsb] attributes for overriding colors. Outlook injects these into elements and uses them to change text color (ogsc, original style color) and background (ogsb, original style background).

You can fight this with the <meta name="color-scheme" content="light dark"> tag and the CSS property color-scheme: light dark. This tells Outlook you are aware of dark mode and want to manage colors yourself. Outlook may respect it and skip the forced inversion. May. The behavior depends on the version, and there are no guarantees.

If a specific element breaks badly in Outlook dark mode, wrap it in a conditional comment <!--[if mso]> and apply separate Outlook-only styles. Old technique, still works. Another option: use VML buttons for Outlook. They render through Word and are not affected by CSS inversion.

Testing: without it, none of the above matters

You cannot predict how an email will look in dark mode by reading the code. You have to see the render. Litmus and Email on Acid both show previews across dozens of clients, including dark mode variants. They cost money, but for professional sending they are not optional.

The minimum manual test matrix: Gmail on Android with dark mode on, Apple Mail on iPhone with dark mode on, Outlook for Windows. Those three clients cover all three rendering models and expose where your layout breaks. If the email holds up in all three, it will probably be fine everywhere else.

Test more than visuals. Check text readability, button visibility, link contrast. Ask a colleague to open the email on their phone in dark mode and describe what they see. Fresh eyes catch problems that a developer stops noticing after three hours of revisions.

Dark mode checklist

  • 1Logos are PNGs with transparent backgrounds; a light version is ready
  • 2Email background uses #f5f5f5 or #fafafa instead of #ffffff
  • 3Text color set explicitly via inline style on every element
  • 4CTA buttons use bright backgrounds; text has explicit color; no #000 or #fff
  • 5color-scheme meta tag added: light dark
  • 6@media (prefers-color-scheme: dark) rules added for Apple Mail and macOS Outlook
  • 7Icons have an outline or background swatch visible on dark surfaces
  • 8Dividers use #d0d0d0 or similar — readable in both modes, not just #eee
  • 9Tested in Gmail Android, Apple Mail, and Outlook for Windows
  • 10List validated before sending — great design is useless if the email does not arrive

Mistakes that keep coming up

Relying only on the media query. Half your audience will never see your dark theme styles. If the email only looks right with prefers-color-scheme and breaks without it, the strategy is wrong. It needs to work both ways.

Ignoring dark mode entirely. "We don't have the bandwidth for dark theme support" is a common response. But support does not require a full rebuild. Switching the background from white to #fafafa, using transparent PNGs, and adding explicit inline colors is an hour of work. It covers most subscribers.

Testing in only one client. "Checked it in Apple Mail, looks fine" means you tested one of three scenarios. Gmail and Outlook will render that same email completely differently.

Using screenshots instead of live text. Image banners do not get inverted, which sounds like a win. But image-embedded text is invisible to screen readers, does not scale on mobile, and adds weight. Gmail clips emails over 102 KB. Three heavy banners and subscribers see a truncated message with a "View entire message" link.

Good design does not help if the email never arrives

You can nail dark mode, build a fully responsive layout, pass every Litmus test. But if 30% of your list contains invalid addresses, the bounce rate will damage your domain reputation and your ESP will start filtering your sends. The email will not reach anyone, in light mode or dark.

Deliverability and design are two layers of the same job. Design controls what subscribers see when they open the email. Deliverability controls whether they get it at all. Without the second, the first does not matter. Validating your list before a send is the same kind of preparation as testing your template across clients.

You spent three hours on dark mode support. Spend three minutes checking your list. Otherwise those three hours went nowhere for a third of your addresses.

Make sure your emails actually reach subscribers. Check your list in uChecker — 30 free verifications to see the real state of your list.

dark mode emailemail dark mode designprefers-color-schemeOutlook dark modeGmail dark modeemail renderingemail designemail validation