Newsletter dark mode design: a practical playbook
TL;DR
When we render every newsletter we track in both light and dark mode at ingestion, roughly one in three ships a logo that vanishes against Gmail's dark background. The fix is rarely a second template. It is a handful of CSS rules, a swappable logo, and a colour palette that survives a client inverting your email without permission. This is the newsletter dark mode design playbook we use on client audits.
When you send a newsletter at Newsletrix, we render it twice. Once on a light background, once on dark. The gap between the two renders tells you most of what you need to know about whether the design will hold up inside subscribers' inboxes. Across the corpus we track right now, roughly one in three newsletters ships a logo that vanishes against Gmail's dark background. Brand colours flip from red to cyan in Apple Mail. Body copy slides from black-on-white to mid-grey on darker grey. None of this is rare.
This is a playbook, not a theory piece. The CSS works, the testing loop is reproducible, and the opinion at the end is one we will defend.
What dark mode email really means today
If you came up on the web, "dark mode" sounds like one thing. In email it is at least three. Apple Mail on macOS Sonoma respects prefers-color-scheme. Gmail on Android usually does a partial inversion: light-grey backgrounds darken, near-white ones invert, certain saturated colours get touched. Outlook.com applies its own [data-ogsc] selector. Outlook on Windows desktop pretty much ignores all of it. Gmail web still does not respect prefers-color-scheme as of Q1 2026, no matter how many blog posts say otherwise.
So when a designer says "make it work in dark mode," they are really saying make it survive five rendering policies at once. Three modes describe most of what you will see: no change, partial inversion, and full inversion. The partial mode is the most common and the trickiest, because the client picks which colours to swap based on luminance thresholds you do not control.
The four failure modes we see across tracked newsletters
There are more, but four account for nearly every render bug we flag in audits.
First, invisible logos. A brand uploads a transparent PNG with dark strokes. It looks great on a white background. In Gmail dark, it disappears. The body is dark, the logo is dark, and there is no negative space. We see this in roughly 33% of the B2B newsletters we have rendered in the last six months. It is the single most common failure we flag.
Second, brand colour drift. Apple Mail will sometimes flip the hue of a saturated colour block. We have watched a Klaviyo-generated red CTA turn cyan, with white text becoming dark grey on top of it. The button still works. It no longer looks like the brand, and the contrast ratio collapses below WCAG 2.2's 4.5:1 minimum for body text.
Third, hardcoded white inside dark frames. You set bgcolor="#FFFFFF" on a <td> so the body looks clean. Gmail iOS keeps it white, and now your reader has a white slab inside an otherwise inverted email. The reverse happens too: a hardcoded near-black survives the inversion and sits awkwardly against a newly dark surrounding frame.
Fourth, hero images with embedded text. Many newsletters - we see this most in creator sends from Beehiiv and Substack - bake the headline directly into the hero PNG. In dark mode the image stays as it was, but the surrounding text inverts. You end up with a daylight-looking image stapled to a midnight email, and the visual hierarchy breaks. The fix is boring: keep headlines as live HTML, treat the hero as illustration only.
See how your competitors' newsletters render in dark mode
Newsletrix renders every tracked newsletter in both light and dark at ingestion. Plug in a competitor's domain and you can see how their template holds up across Gmail, Outlook, and Apple Mail before you redesign your own.
Try the ESP Detector →The CSS that holds up across clients
This is the block we ship to clients. It is not novel, most of these snippets exist in Litmus and Email on Acid guides going back to 2020, but the combination matters and the order matters.
In the <head>:
<meta name="color-scheme" content="light dark">
<meta name="supported-color-schemes" content="light dark">
<style>
:root { color-scheme: light dark; supported-color-schemes: light dark; }
@media (prefers-color-scheme: dark) {
.body-bg { background-color: #0d0d10 !important; }
.body-text { color: #e9e9ee !important; }
.card { background-color: #1a1a1f !important; border-color: #2a2a30 !important; }
.logo-light { display: none !important; }
.logo-dark { display: block !important; }
}
/* Outlook.com */
[data-ogsc] .body-bg { background-color: #0d0d10 !important; }
[data-ogsc] .body-text { color: #e9e9ee !important; }
[data-ogsc] .logo-light { display: none !important; }
[data-ogsc] .logo-dark { display: block !important; }
</style>Three things to call out. One: the color-scheme meta is the line that tells iOS Mail not to apply its own inversion on top of your styles. Drop it and Apple Mail will second-guess you. Two: the [data-ogsc] block is the Outlook.com hack. Microsoft strips style rules that target prefers-color-scheme and rewrites them under its own selector, so you need a parallel block with the same rules. Three: every override needs !important. Email CSS does not honour specificity the way browser CSS does, and without it your inline styles win every conflict.
What none of this gets you is Gmail web. Gmail strips <style> tags from the head on the desktop client. Your only lever there is inline styling and choosing colours that survive Gmail's partial inversion without complaint. Avoid pure-white and pure-black backgrounds and most designs degrade gracefully.
Logo handling: the one pattern that survives
You can argue about CSS specifics for hours. Logos are simpler. There is exactly one pattern that holds up.
Ship two logos in the source HTML. One light-mode version (dark strokes on a transparent or white background), one dark-mode version (white or light-grey strokes on a transparent or dark background). Tag each with the logo-light and logo-dark classes from the CSS above. In light mode the dark one is hidden. In dark mode the light one is hidden. Both versions sit in the email, but only one is ever visible.
That works in Apple Mail, iOS Mail, Outlook.com, and any client that respects prefers-color-scheme. It does not work in Gmail web, where neither display swap fires. The fallback for Gmail web is a logo with a soft padded background, so it has a visible boundary regardless of the surrounding colour. A 4-8px transparent halo, or a subtle rounded rectangle behind the wordmark. Not pretty. It survives.
Two patterns we have watched people try and abandon. SVG with currentColor looks elegant in a browser, but Gmail strips inline SVG entirely and Outlook renders it inconsistently. We tested this on a client send last quarter and ate three hours of debugging before reverting. Skip it. The other failure is "single PNG, transparent background, dark strokes," which is exactly what the 33% in our corpus still ships. There is no single PNG that survives inversion in every client. Two PNGs swapped via CSS, or one PNG with a padded background. Those are the two options.
How major ESPs handle dark mode by default
Newsletrix's ESP detection classifies each tracked send by sender, so we can see how each provider behaves out of the box. The defaults vary more than the marketing copy implies.
Mailchimp's current default templates include the color-scheme meta tag and a partial prefers-color-scheme block. Start from a Mailchimp template, never touch the head, and dark mode works in Apple Mail. It does not handle the Outlook.com [data-ogsc] selector and it does not give you a logo swap. About 60% of the way there for free.
Klaviyo defaults are color-scheme aware and mostly inversion-friendly, but Klaviyo bakes more colours into the template than Mailchimp does, which means more surface area for Apple Mail to flip. We see more brand-colour drift in Klaviyo sends than in any other ESP we track.
Beehiiv ships clean light-mode templates and does not include the color-scheme meta tag by default as of Q1 2026. Dark mode rendering is whatever the client decides. Creator newsletters from Beehiiv are some of the prettiest in light and some of the most broken in dark.
Substack stays consistent across light and dark because the design vocabulary is restrained: black serifs on a white card with thin grey rules. Not much for a client's inversion logic to touch. Kit (formerly ConvertKit) ships color-scheme aware templates and the visual options are tight enough that even a poorly designed Kit email tends to survive. Lower ceiling, higher floor.
If you are picking an ESP today on dark-mode behaviour alone, Mailchimp and Kit are the safer starting points. Klaviyo gives you more control and more ways to break things. Beehiiv gives you the best light-mode design tools and the worst dark-mode defaults.
Testing without paying for Litmus
Litmus is good. It is also expensive, and for a one-person operation or a small marketing team the testing license is hard to justify. There is a workable manual loop.
Send a test to four real addresses: one Gmail account opened on a recent Android device, one Gmail account opened on the web from a desktop, one iCloud address (Apple Mail on macOS), and one Outlook.com address. Those cover the four most common rendering paths. Add an iPhone if you have one.
Switch each device to dark mode before opening the test. Take a screenshot of each render and compare with the light-mode equivalent. Look for: an invisible logo, colour drift on buttons, white slabs inside dark frames, illegible body text. That is 80% of what Litmus would catch, for $0.
The loop does not cover older Outlook on Windows, which is its own galaxy of rendering bugs. If your audience skews heavily B2B and the data shows real Outlook desktop opens, you still need Litmus or a Windows VM. For competitor work, you can also see how Newsletrix differs from Litmus on the rendering side.
Stop shipping separate dark mode templates
Here is the opinion. Every client who has asked us to build a dedicated dark variant ended up with more rendering bugs than they started with. Two templates means two places to keep brand colours in sync, two places to update when CTA copy changes, two places where a stale image or typo can leak through. We have seen brands send the wrong template on dark phones because the swap logic broke and nobody noticed for six sends.
The newsletters in our corpus that render best in dark mode are not the ones with two templates. They are the ones with a single, restrained, design-for-inversion template. A limited colour palette. No hardcoded backgrounds inside cards. One logo with a padded background, or two logos swapped via CSS. The discipline of designing for both at once tends to produce a better single email than designing for either alone.
The trade is real: a single inversion-friendly design constrains the visual identity. You give up some saturation, some pure-white space, some hero-image flexibility. If your brand book leans hard on a signature colour or a hero-driven layout, you lose a little of that. We still think the trade is worth it.
That is the playbook. One template. Inversion-aware CSS. A logo that survives. Test on four real devices. Run it through our spam score checker at the same time, because a clean dark render does not save you if you are tripping deliverability filters.
Frequently asked questions
Does Gmail support dark mode in emails?
Gmail on Android applies a partial colour inversion when the device is in dark mode, but Gmail web on desktop still ignores prefers-color-scheme as of Q1 2026. Gmail iOS sits in between with its own luminance-based inversion logic. You cannot serve dedicated dark CSS to Gmail web; only design colours that survive the partial inversion mobile clients apply.
How do I stop Outlook from inverting my email colors?
Outlook.com strips prefers-color-scheme rules and rewrites them under a proprietary [data-ogsc] selector, so ship a parallel CSS block using [data-ogsc] with the same rules. Outlook desktop on Windows largely ignores both blocks; the only lever there is choosing inline colours that look acceptable without inversion.
What is prefers-color-scheme in email?
prefers-color-scheme is a CSS media query that lets a client request dark or light styles based on the user's system setting. Apple Mail 13 and later, iOS Mail, and Outlook 2021 on macOS support it. Gmail web does not, Outlook desktop on Windows does not, and Outlook.com uses its own [data-ogsc] selector instead.
Why does my logo disappear in dark mode?
A transparent PNG logo with dark strokes is invisible against a dark background. About a third of the B2B newsletters we render at ingestion still ship this single-file setup. Fix it with two logo files swapped via CSS (a light and a dark version), or one logo with a padded background that provides contrast either way.
Do I need a separate dark mode email template?
No. We have not seen a client benefit from running two parallel templates. Every dedicated dark variant introduces drift, doubles your QA surface, and tends to create more rendering bugs than it prevents. The better approach is a single restrained template designed for inversion, with a swappable logo and inversion-aware CSS.