← Back to writing
Email Development 6 min read

Going dark: building dark-mode-ready email templates for a national charity

NT

Nischal Tiwari

Website manager · Digital producer

Dark mode arrived in email the way most platform changes do — not with a migration plan, but with supporters quietly seeing something we never designed.

Apple introduced Dark Mode with macOS Mojave in September 2018. Gmail followed a year later, September 2019, across Android and iOS. Between them, they changed the default rendering environment for a large share of every email list in the world. Nobody sent an announcement to the people who build the emails.

I was an Frontend developer (Email) in the marketing automation team at World Vision Australia, and part of my role was tracking where the email industry was heading and bringing it back to the marketers and creative teams who commissioned our campaigns. Dark mode was the clearest example I’d seen of a trend that wasn’t optional.

Why this wasn’t a design preference

The temptation with dark mode is to treat it as an aesthetic — a nice option for people who like dark interfaces. The adoption data says otherwise.

Two studies from the period:

  • November 2019 (Polar): 95% of users preferred dark mode.
  • March 2020 (Android Authority): 91.8% of people used dark mode wherever it was available.

Those are preference figures, not usage-in-email figures, and they should be read as directional rather than precise. But the direction was not ambiguous. This was rapidly becoming the default way a large share of people saw their screens.

More to the point, dark mode has genuine functional benefits — reduced eye strain from light text on dark backgrounds, better battery life on OLED displays, and, done properly, improved legibility and accessibility. For a charity whose entire email programme depends on supporters actually reading the message, “more legible for most of the audience” isn’t a style question.

The actual problem: every client does it differently

Here’s what makes dark mode hard in email, as opposed to on the web.

On a website, you control the rendering. You write a prefers-color-scheme media query, you define your dark palette, done. In email, the client decides — and each one decides differently.

Some clients respect your colour declarations. Some partially invert. Some, like Outlook on Windows, aggressively reverse light backgrounds and dark text regardless of what you specified. The result is that an email designed only for light mode can come apart in ways that are hard to predict and harder to test:

  • Body copy and headings failing to render against an inverted background
  • Brand logos disappearing — a dark logo on a white background becomes a dark logo on a dark background
  • Colour contrast collapsing to the point of illegibility
  • Buttons losing their shape when background fills invert but borders don’t

We saw exactly this. In one Oracle CX Marketing example I pulled apart for the team, the dark mode version failed to render both the body copy and the heading, and the brand logo went with them.

The instinctive fix is to force the email to stay in light mode. That’s the wrong answer. It fights the client, it fails inconsistently, and it overrides a setting the user deliberately chose — often for accessibility reasons. Forcing light mode is a worse outcome than dark mode done badly.

Working out how much it mattered to us

Industry statistics justify paying attention. Your own platform data justifies a build.

I pulled a year of Oracle Responsys open data for our supporter base:

  • 47% of opens were on a known smart device.
  • Of those, 71% were on Apple iOS.

That second number is the one that mattered. Apple Mail was, at the time, the most consistent and widely-deployed dark mode implementation across mobile and desktop. Nearly three quarters of our smart-device supporters were opening in the environment where dark mode was most fully supported — and where our light-only templates were most likely to be reinterpreted.

I mapped the client support landscape as it stood in mid-2020:

Mobile apps: iPhone Mail, iPad Mail, Gmail app (Android/iOS), Outlook app (Android/iOS) Web clients: Outlook.com Desktop apps: Apple Mail, Outlook 2019 (macOS), Outlook 2019 (Windows), Outlook 365

That’s not a fringe list. That’s most of where our supporters read email.

What we built

The solution wasn’t a dark mode template. It was making dark mode a property of the template system.

We already needed two visual identities in the email programme:

  • A dark theme for BAU campaigns and emergency appeals
  • A light theme for the Child Sponsorship product, with its own header and footer

The obvious approach would have been two separate templates, maintained separately, drifting apart over time. Instead we built one shared module library — a central set of production-ready content modules — and skinned it two ways. Same modules, two branded themes, one codebase.

Layered on top of that, both themes were engineered to respond correctly to the device’s dark mode setting rather than being overridden by it. That meant:

  • Declaring colours explicitly rather than relying on client defaults
  • Supplying logo and image treatments that survive an inverted background
  • Choosing colour pairs that hold their contrast ratio in both rendering modes
  • Testing every module in both states, in both themes, across the client matrix above

The design principle: the email should look intentional in dark mode, not merely survive it.

Shipping it

We rolled it out on the Annual Tax Statement campaign — one of the highest-volume, highest-stakes sends in the calendar, going to a broad cross-section of the supporter base. Both desktop and mobile, both rendering modes.

Choosing a large campaign as the first outing was deliberate. A small test send would have proved the code worked. A tax statement campaign proved it worked at scale, across the full spread of clients our supporters actually use, on a message where rendering failures would have been immediately visible and immediately costly.

What I took away from it

Platform changes don’t wait for your roadmap. Apple shipped dark mode and every email in the world was affected the same week. Tracking where the platforms are going is part of the job, not an extra.

“Force light mode” is a trap. It’s the fastest fix and the worst one. It fights the renderer, breaks unpredictably, and overrides a user’s deliberate accessibility choice.

Theme it once, at the system level. Two templates become two codebases become two sets of bugs. One module library with two skins meant dark mode support was built once and inherited everywhere — and every module added afterwards got it for free.

Bring the platform data, not just the industry data. “95% of people prefer dark mode” is interesting. “47% of our opens are on smart devices and 71% of those are iOS” is what turns a trend deck into an approved build.

Then go and tell people. I ran this as an internal showcase for the marketers and creative teams — what dark mode is, what it breaks, what we’re doing about it, and what it means for how they brief future campaigns. Building the capability is half the work. Making sure the people commissioning the work understand it is the other half.

Written up in 2022, covering work delivered at World Vision Australia. Platform figures are from Oracle Responsys reporting; client support matrix current as of July 2020.