Coding dark mode emails – best practices and considerations

Quick answer: Coding a dark mode email means writing HTML and CSS that survives three different client behaviors. Some clients leave your email alone. Some partly invert it. Some flip everything. You can’t detect which one a subscriber has. So you code defensively: color-scheme meta tags, a prefers-color-scheme media query, data-ogsc / data-ogsb overrides for Outlook, near-neutral colors, and transparent-PNG logos. Then you test on real devices, not previews.

Dark mode is not a design you make. It is a rewrite that happens to your email after you hit send.

That is the whole thing. Once you accept it, coding a dark mode email gets far less mysterious. You stop trying to build “the dark version.” You start building one email that holds up no matter what the client does to it.

This is the coding piece. Palette and branding get touched, sure. But the money here is in the markup. The meta tags, the media queries, the Outlook attributes, the logo that does not turn into a white brick.

Who is this for? Course creators mailing a launch sequence. In-house email marketers stuck with a corporate Outlook audience. Small shops who built their own template, and it looks a bit cheap, and they can’t say why. If any of that is you, keep reading.

Fair warning up front. There is no single CSS rule that fixes dark mode everywhere. Anyone selling you one hasn’t tested in Gmail on a real Android phone.

Why dark mode email stopped being optional

I’ll keep this short. Every competitor bloats this section to 800 words. It’s the most skippable part of any dark mode email guide.

Two numbers matter.

Around 35% of tracked email opens now happen in dark mode. That’s up from roughly 28% the year before. It’s Litmus data, it keeps climbing, and it skews toward the 18-34 crowd. And north of 80% of smartphone users have dark mode switched on somewhere.

So the reading environment is already dark for a large slice of your list. You just can’t see it from your desk.

One more data point, because it decides where you aim. Apple – iPhone, iPad, and Mac Mail combined – held about 51.5% of tracked opens in early 2026. iPhone alone is roughly a third. So the Apple-heavy slice is not a niche. For a lot of lists, it’s the main event, and it’s the slice prefers-color-scheme actually reaches.

Here’s the part that stings. Litmus found a big chunk of its own newsletter subscribers read in dark mode. Yet only about 11% of marketers say they always design for it. That gap is the opportunity, and the liability.

One more stat, because it reframes the stakes. A good share of dark mode opens last only a second or two before the reader bails. Some of that is a broken render. A muddy logo, illegible gray text, a CTA that vanished. People close those fast.

It’s a rendering environment, not a preference

Most guides frame dark mode as a design preference you’re being polite about. That framing is wrong. It’s why people ship broken emails.

Dark mode is a rendering environment you do not control. The client rewrites your colors after send, silently, on rules it does not publish. You find out when you test. Or when a subscriber replies to say your email looks strange.

Plant that idea now. It runs under everything below.

The battery and eye-strain reasons people like dark mode? You’ve used your phone in bed. You already know. Moving on.

The three things a client can do to your dark mode email

There is no if (darkMode) you get to run. None. The client decides, quietly, and you meet the result at test time.

And you can’t sniff it out either. Email strips JavaScript, so there’s no runtime check. There’s no reliable server-side signal for a subscriber’s dark mode state. You send one HTML file into the dark, blind, and hope your defenses hold.

So the job is never “make a dark version.” The job is one dark mode email that survives all three treatments. Here they are.

The partial-invert middle is where most breakage lives. It’s not dumb enough to be predictable. It’s not smart enough to be safe.

Full invert is the notorious one. Classic Outlook on Windows can produce absurd results. Colors you never picked. A brand blue turned into something radioactive. We’ll deal with it. Just know it’s shrinking, and I’ll get to why later.

The bit almost every guide gets wrong about Outlook.com

Here’s a claim you’ll read everywhere: “Outlook inverts everything.” For Outlook.com and new Outlook on the web, that is not what happens.

Outlook on the web is doing contrast repair, not inversion. The evidence comes from developer testing. There’s the well-documented hteumeuleu work, and a June 2026 MailMode teardown that lines up with it. Together they point to a specific process.

Here’s the process, roughly.

• It checks your colors against a contrast threshold, around 4.5:1.
• It runs a lightness remap in the CIELAB color space.
• It rewrites your inline colors, and stashes the originals in data attributes.

Practically? If your contrast already looks acceptable against its dark background, a lot of your colors survive untouched.

“Contrast repair, not invert” is a far more useful model than “Outlook wrecks everything.” It changes how you code. You stop fighting the client. You start feeding it colors it won’t feel the need to fix.

One honest caveat, because it keeps me credible. This is community-observed behavior from testing. Microsoft documents the dark mode UI toggle, not a renderer-level CSS spec. So treat all of it as “verify in a real client.” That’s the through-line of this whole piece anyway.

The meta tags – your first weak line of defense

Every dark mode email should carry these. They cost three lines and never hurt.

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

And on the body plus your key containers, for clients that read it there:

color-scheme: light dark;

What they actually do

They tell the client, roughly: “I’ve thought about dark mode. Please use my styles instead of your own inversion.” Heavy emphasis on please.

Apple Mail and a few others respect it. Plenty of clients ignore it completely. So this is not a fix.

Think of it as table stakes. Three lines, occasionally stops an aggressive auto-invert, zero downside. Ship it every single time. Then do the real work downstream, because these tags will not save you alone.

That’s genuinely it for this section. Do not overthink the meta tags. The people who obsess over them are usually avoiding the harder parts below.

prefers-color-scheme – the one that works where it works

This is the media query that does real work, in the clients that honor it.

Definition, for the snippet-scrapers:@media (prefers-color-scheme: dark) lets you write explicit dark overrides. Supporting clients apply them when the user is in dark mode.

Where it lands, and where it doesn’t

It lands in Apple Mail on macOS and iOS. Outlook for Mac, in places. Samsung Mail. Thunderbird. A handful of others.

It does not reach Gmail on any platform. Gmail ignores your custom prefers-color-scheme overrides. It does not reach classic Windows Outlook either.

So this is a progressive-enhancement layer. It covers the Apple-heavy slice of your list, which is large. Apple sits around half of all tracked email opens. But it is not a universal switch. Ship it and assume you’re covered, and Gmail will burn you.

A realistic block, not a toy

<style>
  @media (prefers-color-scheme: dark) {
    .body-wrap    { background-color: #1a1a1a !important; }
    .content-card { background-color: #222222 !important; }
    .text-primary   { color: #f0f0f0 !important; }
    .text-secondary { color: #b8b8b8 !important; }
    .divider      { border-color: #3a3a3a !important; }
    .btn          { background-color: #6d5dfc !important; color: #ffffff !important; }
  }
</style>

Notice the !important on every line. That is not sloppiness. Inline styles win over embedded styles by default. Your dark overrides live in the <style> block. So they need !important to actually bite. Drop it, and your light colors shrug the overrides off.

The rule that trips everyone

You still inline your light-mode colors on every element. Every one. The dark overrides go in the <style> block on top.

Why both? Belt and suspenders. Some clients strip <style> blocks entirely. Those clients fall back to your inline light colors. If you only set colors inside the media query, the non-supporting clients get nothing. Blank. Broken.

A dark mode email is a color problem stacked on a structure problem. It’s far easier to bolt these styles onto a clean fluid hybrid base than onto a rigid fixed-width mess. Get the structure right first.

A wrinkle – Apple Mail’s implicit dark mode

One catch worth knowing, because it trips people who only test on a Mac.

On iOS, Apple Mail can force a dark treatment even without your overrides. It signals this by adding an apple-mail-implicit-dark-support hook to the markup. So an email can look untouched on macOS and still get flipped on an iPhone.

The fix is to author your dark styles for both paths. Pair your prefers-color-scheme rules with the implicit-support selector where it matters. And, as always, confirm it on a real iPhone. macOS and iOS do not always agree.

Outlook and data-ogsc / data-ogsb – the ugly, necessary part

This is the section the design-led competitors skip or bury. It’s also where the real Outlook wins are.

Plain definition: Outlook stashes your original colors when it processes your email for dark mode. data-ogsc holds the original style color. data-ogsb holds the original style background. There’s also data-ogac and data-ogab for the attribute-based variants. You target those attributes to correct what Outlook did.

Credit where it’s due

I did not invent any of this. Neither did the ten AI-written pages ranking above me.

Mark Robbins surfaced the data-ogsc technique for the email community. Rémi Parmentier, who writes as hteumeuleu, documented the Outlook.com contrast algorithm. He also wrote some of the most-cited working patterns. Nicole Merlin has solid published fixes too.

If you spend any time in the email dev community, these names are load-bearing. Naming them is not name-dropping. It’s telling you where to go deeper.

The practical pattern

Take the prefers-color-scheme rules you already wrote. Duplicate them with [data-ogsc] and [data-ogsb] prefixes. That reaches the Outlook web and app surfaces.

<style>
  /* Correct text color where Outlook repaired it */
  [data-ogsc] .text-primary   { color: #f0f0f0 !important; }
  [data-ogsc] .text-secondary { color: #b8b8b8 !important; }

  /* Fix a container background */
  [data-ogsb] .content-card { background-color: #222222 !important; }

  /* Swap a logo for a dark-safe version */
  [data-ogsb] .logo-cell {
    background: url('logo-dark.png') no-repeat center;
    background-size: contain;
  }
  [data-ogsb] .logo-cell img { visibility: hidden; }
</style>

That image swap is the thing [data-ogsb] genuinely nails on Outlook.com. Font-color correction and logo swapping. That’s the bread and butter here.

The honest limit – classic Windows Outlook barely listens

Classic Word-engine Outlook on Windows is the high-risk, full-invert surface. And prefers-color-scheme does not reach it. data-ogsc is not dependable there either.

So for that client, your defense is boring and structural.

• Sane inline colors, chosen so an invert doesn’t turn them to mud.
• A translucent outline on transparent PNGs, so a logo doesn’t vanish.
• No pale panels that flip into a dark smear.
• A test in a real Outlook install, on real Windows, not a browser toggle.

I keep a real Windows box with a genuine Outlook 2019 install around for exactly this. It’s the least glamorous part of the setup. It catches the ugliest bugs.

Why coding for a dark mode email is quietly getting easier

Here’s the contrarian bit. Most pages still write “blame Outlook’s Word engine.” That advice is going stale, and fast.

Microsoft is winding down classic Word-engine Outlook. The opt-out phase is the one that matters here – the stage where new Outlook flips to the default. That was originally penciled in for April 2026, then Microsoft pushed the enterprise opt-out back to March 2027, handing orgs a twelve-month runway. (Which, honestly, tells you how sticky classic Outlook still is.) After opt-out comes the cutover, the actual point of no return, and managed customers get at least twelve months’ notice before that lands – so realistically no earlier than 2028. Meanwhile existing classic installs, both perpetual and Microsoft 365 subscription, stay supported until at least 2029. The dates keep sliding, so don’t quote me to the day. The direction doesn’t slide.

New Outlook uses a web-based rendering engine, the same lineage as Outlook.com. So follow the logic through.

• The worst, least-controllable, full-invert surface is shrinking.
• What replaces it is the partial-invert / contrast-repair surface.
• That surface you can target with data-ogsc and steer with good contrast.

Translation: over the next few years, the Outlook dark mode picture consolidates. It becomes more code-addressable, not less. The nightmare client is dying off. Almost nobody frames it this way.

So my advice is blunt. Stop over-blaming the Word engine. It’s on the way out. Code for where Outlook is going, not where it sat in 2016.

I won’t pretend this is instant. Classic Outlook lingers in locked-down corporate fleets. Some of those machines will run Outlook 2019 until the hardware dies. But the trend line is unambiguous. And it points your way.

Gmail – the client you can’t target, only survive

Gmail is the other hard one, for the opposite reason to Outlook.

Outlook gives you attributes to grab. Gmail gives you nothing. The Gmail app runs its own partial inversion, and it ignores your prefers-color-scheme overrides. So you can’t steer it. You can only feed it colors it won’t wreck.

That means the Gmail defense is all upstream. Inline colors on every element. Near-neutral values that survive the invert. High baseline contrast, so a nudge doesn’t push text under AA.

There is one clever trick worth knowing. Rémi Parmentier documented a CSS blend-mode approach for Gmail’s app. It can hold certain colors steady where inversion would otherwise shift them. It’s narrow, it’s fiddly, and it doesn’t cover everything. But for a logo or an accent that must not move, it’s worth a look.

Mostly, though, the honest answer for Gmail is boring. Pick resilient colors. Test on a real Android phone. Accept that you’re surviving Gmail, not controlling it. That’s the deal, and no amount of CSS changes it.

Color and contrast for dark mode email – the decisions before you write CSS

The best dark mode fixes happen before the CSS. They happen in the palette.

The near-neutral trick

Pure #FFFFFF and pure #000000 are the exact values aggressive auto-inverters target first. Nudge them. Use #FEFEFE or #FDFDFD for white. Use #1A1A1A or #111111 for black. Sometimes that alone dodges the inversion.

There’s a related rule of thumb worth knowing. Partial-invert clients tend to leave #CCCCCC or darker mostly alone. Same for #333333 or lighter. So those give you a “kinda-white” and a “kinda-black” that survive better than the pure values.

Is this documented? No. Is it superstition-adjacent? A little. Does it work often enough to do by default? Yes. I keep the same trick going in the background images piece, so the thread stays consistent.

Don’t go pure white on a dark background either

Screaming #FFFFFF text on #1A1A1A looks cheap and harsh. It also causes eye fatigue in a low-light room.

Pull it back. #F0F0F0 or #E8E8E8 reads calmer and looks intentional. Pure-on-pure looks amateur in both modes, frankly.

The contrast collision

This one bites people who thought they did everything right.

You tune a palette to a clean 4.5:1 in light mode. Then a client inverts it. The same colors, flipped, can collapse below AA. Worse ratio, same email.

So here’s the rule. Test the inverted version’s contrast, not just the light one. I won’t re-litigate all of WCAG here. The accessible HTML email guide does the full treatment. Just internalize the one rule. Check both directions.

Gradients, shadows, and the non-standard stuff

Cross-client gradients and subtle shadows are my thing. So let me be straight about the risk. These are exactly what partial-invert clients mangle in unpredictable ways.

A shadow that reads beautifully in light mode can evaporate in dark. A gradient tuned for a white ground can turn to sludge when the ground flips. Build them to survive both contexts. Or don’t let them carry meaning. Decorative is fine. Load-bearing is dangerous.

Here’s how I handle a brand gradient in practice. I pick stops that already sit mid-range, not near-white or near-black. Mid-range colors are the ones inverters are least aggressive with. Then I set a solid fallback color underneath, for the clients that drop the gradient entirely. And I give the gradient block its own dark treatment where I can target it. So it degrades to a clean solid, never to mud. It’s more work than a single background line. On a brand send, it’s the difference between “polished” and “what happened here.”

Images and logos – where dark mode visibly embarrasses you

The number-one real-world complaint, stated plainly: “our logo looks terrible in dark mode.”

It’s almost always the same cause. A PNG with a baked-in white background, sitting on a now-dark panel. You get a white brick around the logo, or an ugly halo. It reads like a mistake, because it is one.

The fix takes five minutes. Transparent-PNG background. Done, forever.

The outline trick

Transparent backgrounds create a second problem, though. A dark logo on a transparent ground vanishes when the panel behind it goes dark.

The trick is a translucent or white outline on the artwork. Invisible on white. A legible halo when the surroundings invert. Same idea in reverse for light artwork on transparent grounds. Cheap insurance.

Swapping the asset entirely

Sometimes one asset can’t work on both grounds. Then you swap.

<style>
  @media (prefers-color-scheme: dark) {
    .logo-light { display: none !important; }
    .logo-dark  { display: block !important; }
  }
  [data-ogsc] .logo-light { display: none !important; }
  [data-ogsc] .logo-dark  { display: block !important; }
</style>

Light version by default. Dark version swapped in for supporting clients. One honest note here. Gmail won’t run the swap. So the default asset has to be the safe one. It should read acceptably even if the swap never fires.

The image-only email temptation – and why I say no

Some brands ship the whole email as one giant image. On purpose. The logic is that dark mode can’t invert what it can’t parse.

It “works,” in the narrowest possible sense. It’s also a bad idea on three counts a developer should care about.

1. It tanks accessibility. A screen reader gets nothing. You’re straight back into WCAG trouble, and into legal-exposure trouble too.
2. It looks like spam. Image-heavy, text-light emails trip filters. Deliverability suffers. Your email lands in Promotions, or worse.
3. It overrides the subscriber’s choice. Someone picked dark mode on purpose. You’re forcing a light rectangle onto them anyway.

My take, stated as a take: it trades one rendering problem for three worse ones. I don’t ship it. I’ll push back if a client asks for it. That’s a real opinion, and the point of having one is that it saves you from the fence-sitters.

Dark-mode assets are also more images to weight-budget. The same image-optimization discipline applies. Don’t let a dark logo variant balloon the send.

Buttons, CTAs and the parts that quietly break

Your CTA is the one element that absolutely cannot break. So of course it’s one of the first to.

Contrast in both modes

A button that pops on white can lose all definition on dark. And the reverse is just as bad. A dark-fill button on a now-dark background melts into it.

Give the CTA an explicit dark treatment. Flip the fill and text, or add an outline that holds in both modes. One clear, high-contrast CTA survives a dark mode email far better than three competing muddy ones. If you spend attention anywhere, spend it here.

Bulletproof buttons, revisited

Live HTML text with a VML fallback for classic Outlook. That’s still the move. An image-based button that inverts, or fails to load, is a dead CTA. And a dead CTA is a dead campaign.

I won’t rebuild the full bulletproof-button pattern here. The background images guide already carries that build. Reference it, don’t reinvent it.

The sneaky ones

These pass a desktop glance and die on a real phone. Run through them before every send.

• Dividers and hairline borders disappearing into a dark background.
• “Invisible” white spacers suddenly becoming visible gray bricks.
• Drop shadows evaporating, so cards lose their separation.
• A mid-gray footer going fully illegible. The unsubscribe link included, which is a compliance problem, not a cosmetic one.

None of these show up in a light-mode preview. All of them show up on an actual device. Which brings us to the part everyone skips.

Testing dark mode email without lying to yourself

A browser dark-mode toggle is not Gmail’s dark mode on a real Android phone. The two disagree, in ways nobody bothers to document.

So preview tools are step one. They are not the finish line. If you stop at previews, you are guessing.

The real-device minimum

For any high-stakes send, the floor is real hardware. A launch, a big promo, anything you’d be embarrassed to get wrong. For those, you need:

• an actual iPhone in dark mode,
• an actual Android running the Gmail app in dark mode,
• a real Outlook install.

Toggle each between light and dark. Watch what moves. The stuff that moves is the stuff that breaks.

I’ll admit the least fun version of this is the late check. The one you do the night before a send, when you’d rather be done. That’s usually when the phone catches the thing the preview swore was fine. It’s tedious. It’s also the gap between shipping clean and shipping a white-brick logo to fifty thousand people.

The tools, priced straight

I’m going to be honest about cost here. Honest converts better than shilling. Here’s what I actually reach for, and when each is worth it.

Litmus is still the industry default for previews across a big spread of clients. Dark mode variants included. But the pricing changed hard. After the Validity acquisition, the old cheap tiers vanished. The entry point is now the Core plan, around $500 a month. That’s roughly $4,980 a year. If your volume justifies it, it’s excellent. For a solo freelancer, it’s overkill, full stop.

Mailgun Inspect is the successor to Email on Acid, now under Sinch. Existing accounts migrate through 2026. It’s the same screenshot-preview idea, on usage-based pricing. The Basic tier lands around $99 a month plus overages. For small teams and freelancers, that’s the sensible pick. A fraction of Litmus for the core previewing job.

A couple of practical notes. Putsmail is gone. Don’t send anyone looking for it. It’s not coming back. And there are leaner newer options in the $20-a-month range. Those suit you if all you need is real-device rendering screenshots.

Here’s the honest version of the recommendation. If Litmus fits your budget and volume, it’s the most complete tool. If it doesn’t, Mailgun Inspect covers previewing for most people. And free real-device testing is a respectable baseline for a one-person shop. Nobody needs a $500 subscription to send a good dark mode email.

The free workflow, if that’s all you’ve got

You don’t need a paid tool to test a dark mode email. You need the accounts you already have.

Set up a free Gmail address and an Outlook.com address. Send yourself the campaign. Open it in the Gmail app on Android, in dark mode. Then open it in Outlook.com on the web, in dark mode. Open in Apple Mail on your phone. Toggle each one, light to dark, and watch.

It’s slower than a preview grid. It’s also more honest, because it’s the real renderer, not a simulation. For a one-person shop, this is a perfectly good baseline. Paid previews buy you breadth and speed, not truth.

Keep the testing approach consistent across the whole build. The same real-device logic covers your fluid hybrid responsive checks. It covers your background image fallbacks too. One testing habit, applied everywhere.

A minimal dark-mode-ready starting point

Not a full template dump. Just the audit checklist. This is what a dark-mode-ready email actually has. Run your own email against it.

1. color-scheme and supported-color-schemes meta tags in the head, plus color-scheme on the body.
2. Inline light-mode colors on every element. No exceptions. This is your floor.
3. Near-neutral colors rather than pure #FFFFFF / #000000.
4. A prefers-color-scheme block with !important on the overrides.
5. The same rules duplicated under [data-ogsc] / [data-ogsb] for the Outlook web and app surfaces.
6. Transparent-PNG logos with a safe outline so nothing vanishes.
7. An explicit dark treatment for the CTA. A flipped fill or an outline that holds.
8. A real-device test before send. iPhone, Android Gmail, a real Outlook.

Hit all eight and you have a resilient default. Notice I said resilient, not bulletproof.

There is no CSS rule that fixes dark mode everywhere. This checklist gets you a dark mode email that holds up across most of your list. It degrades gracefully on the rest. That’s the actual goal. Anyone promising more hasn’t tested in Gmail on Android lately.

Frequently asked questions

What does coding a dark mode email actually mean?

It means writing one email that survives three client behaviors: no change, partial invert, and full invert. You can’t detect which one a subscriber has. So in practice it’s defensive coding. Meta tags, a prefers-color-scheme query, data-ogsc overrides for Outlook, near-neutral colors, transparent logos, and real-device testing before you send.

Which email clients support prefers-color-scheme?

Apple Mail on macOS and iOS, Outlook for Mac in places, Samsung Mail, Thunderbird, and a few others. It does not work for your custom overrides in Gmail on any platform. Classic Windows Outlook ignores it too. Treat it as progressive enhancement that reaches your Apple-heavy audience, not a universal switch.

What are data-ogsc and data-ogsb?

They’re attributes Outlook adds when it processes your email for dark mode. data-ogsc stores your original text color. data-ogsb stores your original background. There’s also data-ogac and data-ogab for attribute-based variants. You target them in CSS to correct Outlook’s dark rendering on the web and app. Classic Windows Outlook is unreliable for it.

Do the color-scheme meta tags actually do anything?

Sometimes. They ask the client to respect your styles instead of forcing its own inversion. Apple Mail and a few clients honor the request. Many ignore it. They cost three lines and never hurt, so add them every time. Just don’t expect them to fix anything on their own.

Why does my logo look bad in dark mode?

Almost always a baked-in white background on the PNG. It sits on a now-dark panel and gives you a white brick or halo. Switch to a transparent PNG and add a safe outline, so the mark doesn’t vanish. If the artwork still can’t work on both grounds, swap a dark variant via media query and [data-ogsb].

Should I just send an image-only email to avoid dark mode?

No. It breaks accessibility, since screen readers get nothing. It hurts deliverability, because image-heavy emails trip spam filters. And it overrides the subscriber’s stated preference for dark mode. You’d be trading one rendering problem for three worse problems. Code a real dark mode email instead.

Does Gmail support dark mode CSS for emails?

Gmail applies its own partial inversion and ignores your custom prefers-color-scheme overrides. So on a Gmail-heavy list, you can’t rely on the media query. Your defense is explicit inline colors on every element. Add near-neutral values that survive inversion. Then test obsessively on a real Android phone.

Will new Outlook change how I code for dark mode?

Yes, in your favor. Classic Word-engine Outlook is being retired, and users are moving to new Outlook. New Outlook runs a web-based engine. So the worst full-invert surface shrinks. It’s replaced by the partial-invert / contrast-repair surface you can target with data-ogsc. Expect fewer full-invert surprises over the next few years.

How do I test a dark mode email properly?

Use preview tools for breadth. Litmus, or the cheaper Mailgun Inspect. Then confirm on real devices. An iPhone, an Android running Gmail, and a real Outlook install. Toggle each between light and dark. Previews miss the disagreements between a browser toggle and a real client. Real hardware catches them.

How many people actually read emails in dark mode?

Around a third of tracked opens, and climbing. Rates run higher among younger audiences. Most smartphone users have dark mode enabled somewhere. That’s a large enough slice that ignoring it means shipping a broken email to a meaningful part of your list. Often without you ever knowing.

Where this leaves you

You’re not designing a dark version. You’re coding one email to survive a rendering environment you don’t control. And here’s the part almost nobody says out loud. That environment is slowly consolidating in your favor, as classic Outlook dies off.

So build for where the inbox is going. Near-neutral colors. Inline everything. A prefers-color-scheme layer, duplicated for data-ogsc. Transparent logos with an outline. Then test on real hardware, because the previews lie.

If you’d rather hand this off, I build cross-client emails that hold up in dark mode. I answer within the day. I don’t disappear mid-project. And I show you the test results before you send, not after a subscriber complains. Send me a brief and tell me where it’s currently breaking.

Next up on the blog, I’m tying the dark-mode-plus-accessibility thread back to the WCAG guide. There’s also a container-queries-in-email piece coming that I keep threatening to finish.

If this was useful, the newsletter is where the new builds and re-tests go out. No fluff. Just the stuff that breaks, and how I fixed it.

That’s the piece. Go re-test something.