How to Design Emails That Work in Dark Mode

The modern web has embraced dark mode as the default. Nearly 82% of smartphone users now have dark mode enabled on at least one device, and 81.9% of Android users use it on their phones, in apps, and across other contexts. That's the default viewing environment for most of your audience, and it changes how every element of your email renders: backgrounds, text, buttons, logos, and images.

Most teams treat dark mode as a QA problem. Build the email, test it, fix whatever broke. But by that point, colors have been chosen, images exported, brand guidelines applied. You're patching decisions that were already made, not making better ones.

"The biggest issue I see with dark mode isn't technical, it's organizational," says Sarah Gallardo, accessibility specialist and founder of Stitch. "Designers and developers are often siloed, which leads to missed opportunities early in the design process and rushed, hacky fixes later."

How dark mode changes your email rendering

Dark mode in email clients isn't a single behavior. It's at least three distinct approaches, each applied differently depending on the client, the platform, and sometimes the version of the app your subscriber happens to be running. A fix that works for Apple Mail might create new problems in Outlook.

Neither partial nor full inversion is entirely predictable. Email clients continually update how dark mode renders, and an email that tested perfectly in Outlook last quarter may behave differently after an app update. Gmail on Android can differ from Gmail on iOS, which differs from Gmail on desktop. This unpredictability is why Gallardo advocates addressing dark mode at the design stage. When color choices are informed by how clients actually handle inversion, there are fewer surprises downstream.

Common dark mode rendering issues

The problems dark mode creates fall into a few recurring categories. Some are cosmetic. Others fundamentally break readability or render CTAs invisible.

Mid-tone colors and dark mode email design

Gallardo's most practical recommendation is one many email teams overlook. "One underused but effective fix is designing with mid-tone colors," she explains. "Mid-tone backgrounds and CTA colors tend to survive dark mode inversion more predictably and are more likely to maintain sufficient color contrast."

The logic is straightforward. When an email client inverts colors, it flips the lightness value. Pure white becomes near-black. Pure black becomes near-white. Colors at either extreme undergo the most dramatic transformation, while mid-tones shift less because they have less distance to travel on the scale. Litmus recommends the same approach in their dark mode guide: "Use a color that has a high enough color contrast for both white and black because it falls toward the middle of the value range." A medium blue or muted teal will maintain more consistent contrast ratios across light and dark environments than a neon green or pale yellow.

This doesn't mean redesigning your entire brand palette. Most brand guidelines include primary, secondary, and accent colors, and often the mid-range options translate best to dark mode even if they're not the defaults for web or print. "It's not foolproof, so testing is still essential," Gallardo adds, "but this approach dramatically reduces dark mode issues across clients."

How to test dark mode rendering systematically

Testing dark mode can feel overwhelming given how many client and device combinations exist, but Gallardo's team at Stitch has developed an approach that turns it into pattern recognition rather than guesswork.

"At Stitch, we created a base HTML file with common color scenarios: brand colors on light and dark backgrounds, different text color combinations, and CTA treatments," she says. "We swap in a client's brand colors and test across email clients to see which values invert cleanly and which cause problems." The goal is to "identify patterns: what holds up, what breaks, and what needs adjustment, so design decisions are informed by real behavior."

The key shift is treating dark mode testing as a per-brand activity rather than a per-email activity. Test the brand's color system once, document the results, and every subsequent email benefits from that research. Knowing your actual dark mode vs light mode split makes this prioritization concrete. Knak's Performance Insights tracks email client breakdown and rendering environment automatically, so you can see exactly what percentage of your audience opens in dark mode and allocate testing effort accordingly.

• Build a color test template that displays your brand colors in every relevant combination: primary and secondary backgrounds with light and dark text, CTA buttons in each brand color on both background types, logos on both light and dark backgrounds.
• Test across priority clients by reviewing your email analytics for the top five or six clients by open volume, then running your color template through those. For most enterprise senders, that means Apple Mail, iOS Mail, Gmail (mobile and desktop), and at least one version of Outlook.
• Document the patterns and establish fallbacks. Record which colors invert cleanly, which create contrast problems, and which break entirely. For brand colors that don't translate well, identify approved alternatives. A primary blue that loses contrast in dark mode might have an approved darker variant that maintains readability. This documentation becomes a design reference that guides every email your team builds.

Designing for dark mode from the start

"We've found that dark mode works best when it's treated as a design constraint, not a post-build fix," Gallardo says. "At Stitch, designers and developers review color choices together early, which avoids a lot of downstream compromises."

This addresses the organizational problem she identified at the outset. When designers choose colors without understanding how email clients will transform them and developers inherit those choices without the ability to change them, both sides are working with constraints neither fully controls. The result is "rushed, hacky fixes" that patch individual emails instead of solving the underlying pattern.

In a siloed workflow, QA catches dark mode issues after the email is built, fixes go back to production, sometimes back to design if a color change is needed. The loop adds hours or days to timelines. In a coordinated workflow, design and development address rendering issues together from the start. Color decisions happen once, informed by testing data, and they cascade through every template that follows.

For enterprise teams managing dozens or hundreds of templates across multiple brands and regions, this approach scales in ways that per-email fixes don't. A template built with dark-mode-tested colors produces compatible emails by default. Organizations that have already systematized their email production are positioned to make this shift. When design and production share a system, design decisions carry through without interpretation errors or manual rebuilds.

Dark mode email design checklist

For teams ready to operationalize these principles, this checklist covers the critical decisions at each stage of the email production process.

Enterprise template systems and dark mode

For organizations sending email at scale, individual dark mode fixes don't work. If you send 50 emails per month and each one requires 30 minutes of troubleshooting, that's 25 hours of reactive QA every month. The math only gets worse across regions, brands, and business units.

The alternative is building dark mode compatibility into the template layer. When templates are designed with tested mid-tone color palettes, approved logo treatments, and semantic color attributes, every email built from those templates inherits compatibility without per-email intervention. The testing happens once at the template level, not repeatedly at the email level.

The scale of this challenge is real. Uber runs 25,000 render tests annually across 10 email clients to catch rendering issues early, and built 100+ reusable modules so brand consistency holds across global teams. That kind of template-level governance is what makes dark mode compatibility sustainable rather than heroic.

With the majority of smartphone users already defaulting to dark mode, designing for both rendering environments is a baseline requirement. The teams that treat it as a design constraint rather than a QA problem will spend less time fixing broken emails and more time on work that actually moves campaigns forward.

See how Knak handles enterprise email creation.