Emails in dark mode

Mail clients repaint emails in dark mode, and they do not agree on how. The product does not give you a dark theme — it gives you a negative guarantee: no dark text ends up on a dark background, and no light text on a light one. Outside that case, your palette is left exactly as you wrote it. A section you deliberately made dark stays dark.

Where the fix happens

At render time, and identically for all five: a campaign send, a sequence send, a test send, the editor preview, and a rendering requested over the API. Two consequences. Templates and campaigns saved long ago benefit without being touched — the HTML is rendered when it is sent, not when it is written. And nothing has to be fixed template by template.

What it does to your document

  • A @media (prefers-color-scheme: dark) block is injected, with !important declarations, so it can win over your inline styles without the product having to parse your HTML.
  • Outlook.com is handled through its own hooks ([data-ogsc], [data-ogsb]), which it substitutes for classes in dark mode.
  • Gmail ignores prefers-color-scheme entirely and applies its own partial inversion. It is covered differently: any element carrying a background is given an explicit text colour.
  • The color-scheme and supported-color-schemes meta tags are added only when the dark rules ship with them — and removed when they cannot.
That last point is the whole story of dark mode. Declaring color-scheme tells the client "I handle dark", so it stops applying its own inversion, which at least flipped background and text together. With nothing behind the promise, the background darkens and the text stays black. The declaration alone is worse than nothing.
An inline !important puts your document out of reach. A rule in a <style> block beats an inline style — but not an inline style that is itself !important. Against style="background-color:#ffffff !important" the correction loses: the background stays white while the text lightens. Drop the !important from your inline colours.

It warns, it never blocks

When the renderer finds a risky pair, it corrects it and says so. No send is ever refused over contrast. Three notices exist: the contrast was corrected, it could not be verified, or a color-scheme declaration was removed because the rules behind it could not be produced.

What it implies elsewhere

The editor preview has a light and a dark view — use it. Seeing the defect before sending is worth more than the correction itself. Images are not covered: a logo baked onto white stays on white while everything around it inverts. Use a transparent PNG, or one that reads on both grounds. See media.