Dark mode email design: what clients support and which tools help
By Mara Levin · Updated October 7, 2026
The short answer
Dark mode in email is really three jobs: declare that the message can handle both schemes, write dark styles for the clients that read them, and choose colours and images that hold up in the clients that invert on their own. The caniemail.com data shows how lopsided the first two are. Apple Mail supports the media query, the color-scheme property and light-dark(); Gmail supports none of the three. No tool changes that, so tools matter for authoring speed and previews, and the choice between them comes down to who edits the email.
Which client reads which dark-mode feature
| Client | prefers-color-scheme | color-scheme property | color-scheme meta | light-dark() |
|---|---|---|---|---|
| Apple Mail, macOS | Yes | Yes (html element only) | Yes | Yes (Safari 17.5 or later) |
| Apple Mail, iOS | Yes | Yes (html element only) | No (entry is for 12.4) | Yes |
| Gmail, webmail | No | No | No | No |
| Gmail, iOS and Android apps | No | No | Partial ("light only" value) | No |
| Outlook for Windows (2016, 2019) | No | No | No | No |
| Outlook.com, Outlook for Mac, Outlook for iOS | Yes (adds data-og* attributes) | No | No | No |
| Outlook for Android | Yes since the 2023-03 entry | No | No | Unknown |
| Samsung Email | Yes (6.1 on) | Yes | No | Partial |
| Yahoo! Mail, AOL | No | No | No | No |
| Thunderbird | No (latest entry) | Yes | Yes | Yes (128.1 on) |
| ProtonMail, webmail | No | Yes | No | Partial |
Source: caniemail.com data, last updated September 16, 2026, one feature page each for prefers-color-scheme, the color-scheme property, the color-scheme meta tag and light-dark(). Where a client has several version entries, the table shows the newest. Clients not named here are on the feature pages.
Reading the table as a designer
Three patterns fall out of it. Apple Mail and Samsung Email read your dark rules directly, so a designed dark palette pays off there. Outlook.com, Outlook for Mac and Outlook for iOS also run the media query, but caniemail.com adds that they attach the attributes data-ogsc, data-ogac, data-ogsb and data-ogab to the document in dark mode, which is the hook for Outlook-only overrides. Gmail, Yahoo! Mail, AOL and Outlook for Windows ignore all of it, which means a large share of recipients get the email either untouched or recoloured by the client, with your dark rules never consulted.
How those clients recolour is not something the data records. Beefree's dark mode documentation sorts clients into three behaviours: nothing changes (it names Yahoo Mail and Gmail's webmail), partial inversion where only light-coloured areas flip (it names outlook.com), and full inversion (Gmail's mobile app and iOS 13). Parcel's dark mode page describes the same thing in a sentence: some clients find areas with dark text on a light background and flip them to match the user's setting. Plan for all three, because one subscriber list contains all three.
A starter pattern that respects that spread
The idea is to write the light design inline, as you would anyway, then override from the head only for the clients that read it. Everything in the dark block is an enhancement; the email must already read correctly without it.
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<meta name="color-scheme" content="light dark">
<style>
:root { color-scheme: light dark; }
@media (prefers-color-scheme: dark) {
.surface { background-color: #1f2328 !important; }
.ink { color: #e6e8eb !important; }
.cta { background-color: #8ab4ff !important; color: #10141a !important; }
}
/* Outlook.com and the Outlook apps add data-ogsb / data-ogsc
to the markup in dark mode, so these selectors can restyle it */
[data-ogsb] .surface { background-color: #1f2328 !important; }
[data-ogsc] .ink { color: #e6e8eb !important; }
</style>
</head>
<body class="surface" style="margin:0; background-color:#f6f7f9;">
<p class="ink" style="color:#1c1f24;">Your order has shipped.</p>
</body> Two caveats from the data. The meta tag only matters where it is supported (the table shows where), and the CSS color-scheme property is listed for Apple Mail as working on the root element only. If you want to try light-dark() for text or background colours, give the property a plain colour first so clients that drop the function still get a value:
.ink {
color: #1c1f24; /* fallback for clients without light-dark() */
color: light-dark(#1c1f24, #e6e8eb);
} That fallback matters more than it looks. caniemail.com marks light-dark() as partial in Samsung Email (not with Hotmail or Outlook accounts) and as buggy in several smaller webmail clients, where the function is accepted but the colour stays light even in dark mode. A bare light-dark() with no fallback is a gamble on client versions.
Images and logos need their own plan
Colours are the easy half. A dark logo on a transparent PNG disappears on a dark background, and a logo exported with a white box looks like a sticker. The three remedies are the same ones any designer would reach for: a mid-tone mark that reads on both, a logo with a thin light outline, or two image files with the dark one shown only inside the dark media query. The last option does nothing in clients that skip the query, so make sure the default file is the one that survives the most clients. Stripo's article on its built-in dark mode lists checking images and logos for visual integrity as one of the two reasons to preview, the other being contrast and readability.
Fourteen tools, sorted by who does the work
Every dark-mode feature below is the vendor's own description from its documentation, not something verified in a client. Prices are from each vendor's pricing page on October 7, 2026, in US dollars.
Code-first: you write the dark rules
MJML. Open source under the MIT licence, per its FAQ. The documentation has no dark-mode component, but mj-style puts your CSS into the output's head and mj-raw lets you add raw markup, which is where the meta tag and the dark block from the starter go. Dark mode is yours to write; MJML only compiles the table layout. See the MJML documentation.
Maizzle. Its Tailwind chapter says the dark: variant compiles to @media (prefers-color-scheme: dark) and that ogsc: and ogsb: variants target Outlook.com's dark mode for text and background. It also warns that Gmail drops an entire style tag when it meets nested at-rules, such as the output of stacking dark: with ios:, and suggests keeping those utilities in a separate Tailwind block. Framework cost is zero; the pipeline is the team's to run.
React Email. MIT-licensed and free, per its GitHub repository. I found no dark-mode section in its documentation, so anything you do here is hand-written CSS inside components. That suits teams that want to keep light and dark values next to the content they style.
Parcel. A code editor with previews. Its preview has a colour-scheme menu with Light, Dark, Forced Dark and System; Light and Dark drive prefers-color-scheme, and Forced Dark emulates the inversion some clients apply on their own. That second mode is the useful one, since it shows what happens to an email that has no dark rules at all. Parcel's pricing page lists a $0 plan for people who code emails, then $29 and $56 per user per month.
Visual builders: you check, the tool lays out
Stripo. The editor has a light/dark switch for the design area and a toggle in preview mode. Stripo itself states the preview is approximate. Stripo's pricing page lists Free at $0 (4 exports a month, and the plan is described as not meant for exporting to ESPs), Basic $20, Medium $45 and Pro $125 a month, with 20% off for yearly billing.
Beefree. A Dark Mode Preview toggle sits in preview mode. The documentation is candid: it is a general approximation, tested with standard content blocks, may differ for custom HTML blocks, and the builder does not automatically optimise designs for dark mode. On Beefree's pricing page Starter is $0 (up to 10 designs, 6 exports a month), Professional $30 and Business $160 a month.
Postcards. A module-based builder from Designmodo. I have no dark-mode documentation or current price for it that I can cite, so I cannot say what its preview does; open the product and run your own header, button and logo through it.
Topol. Topol's pricing is per prepaid end user: Startup $70 a month for 50 users, Expansion $140 for 100, Business $300 for 500. That points at embedding the editor in a product, so the question to ask is whether your own custom blocks come through with their dark-mode classes intact.
Embedded editors: your customers do the editing
Unlayer. Unlayer's pricing starts at $250 a month, then $750 and $2,000, each with a 14-day trial and 1 TB bandwidth. The dark-mode question for an embedded editor is different from a standalone one: your users can drop in any block, so the safe move is a library of pre-checked blocks and a rule about what they may recolour.
Chamaileon. A published starting price of $4k a year or $400 a month, with onboarding and email design system setup included, per its pricing page. A design system is exactly where dark-mode tokens belong, but I have not found a dark-mode feature description to cite.
Render checking: you see the real clients
Litmus. Its testing page describes previews across many clients, dark mode among them. It does not publish a plan price I can quote, so budget by asking.
Email on Acid. Its pricing page lists Basic at $99 a month for 1,000 previews and Premium at $199 for 2,000, with $0.15 for each extra preview, and says subscribers begin moving to Mailgun Inspect from June 2026. Check which product you would actually be buying.
Senders with a builder attached
Mailchimp. Its pricing page lists a free plan for up to 250 contacts and 500 sends a month. I have no dark-mode documentation to cite for its editor, so preview a real campaign from a test send. Brevo. A free plan of 300 sends a day, then Starter from $9 and Standard from $18 a month, per its pricing page. The same advice applies: its builder preview is not evidence of what Gmail or Outlook does with the delivered message.
What the previews can and cannot tell you
Three of the tools above, Stripo, Beefree and Parcel, describe a built-in dark preview, and all three are honest that it is an emulation. Parcel's Forced Dark and Beefree's preview, which mainly simulates full inversion, answer "what if the client flips my colours", Parcel's Dark setting answers "what does my own prefers-color-scheme block do", and none of them runs the code of a real mail client. That is why the cheapest useful check is still a test send to a handful of real accounts with dark mode switched on.
A short evaluation routine
- Take one real email with a header logo, a two-column block, a button and a footer, not a demo template.
- Preview it three ways: light, your dark rules, and forced inversion if the tool offers it. Fix contrast first, since a pale grey on white often becomes pale grey on near-black.
- Send it through the real path with merge tags, tracking and the footer in place, to Apple Mail, a Gmail account and an Outlook account.
- Write down what you cannot control in one line each, for example "Gmail recolours the hero image background". That list is your maintenance plan.
- Price the finalist at your current volume and at double, including seats and exports for builders or preview credits for testers.
Choosing by who edits the email
| If the email is edited by | Look first at | Prove before committing |
|---|---|---|
| Developers, templates in Git | MJML, Maizzle, React Email | That the compiled head survives your sender, and that Gmail keeps the style tag |
| A developer and a designer sharing a file | Parcel | Forced Dark output on the logo and the buttons |
| Marketers building campaigns | Stripo, Beefree, Postcards | Export limits on the free plan, and custom HTML blocks in preview |
| Your customers, inside your product | Unlayer, Topol, Chamaileon | Saved designs reopening intact, and a locked block set |
| A release gate across many clients | Litmus, Email on Acid | Whether dark and light previews count separately against your allowance |
Related reading: the HTML email accessibility guide covers contrast and alt text, the client compatibility guide covers the rest of the rendering differences, and the CSS in email guide explains which properties survive inlining.
FAQ
Does Gmail support dark mode styles in email?
Not the kind you write yourself. caniemail.com lists the prefers-color-scheme media query, the color-scheme property and light-dark() as unsupported in Gmail on desktop webmail, mobile webmail, iOS and Android, and the color-scheme meta tag as partial in the iOS and Android apps (only the value "light only"). That leaves colour choices that survive whatever inversion Gmail applies on its own.
Do I still need the color-scheme meta tag if I write prefers-color-scheme rules?
It does different work. The media query supplies the dark values; the meta tag and the color-scheme property declare which schemes the email is designed for. caniemail.com shows the meta tag as supported in Apple Mail on macOS and in Thunderbird, and the CSS property in Apple Mail, Samsung Email, Thunderbird and ProtonMail webmail. Where neither is supported, it does no harm and no good, so adding it is cheap.
Can an email builder fix dark mode for me?
It can shorten the loop, not remove the work. Beefree's documentation says its builder does not automatically optimize designs for dark mode and that custom HTML blocks may preview differently, and Stripo describes its preview as an approximate result. Treat builder previews as a first check and the real clients as the final one.
Which tool should a small team start with?
Pick by who edits the email. A developer who owns templates in Git gets the most control from MJML, Maizzle or React Email; a marketer assembling campaigns is better served by Stripo or Beefree, each with a free plan and a dark-mode preview. Add a render-testing service only when the list is big enough that a wrong colour costs more than the subscription.