Why does your email look broken in dark mode?

Because there is no dark mode standard in email, and the failures cluster into seven patterns: logos that vanish, brand colors that get rewritten, text that ends up low contrast on a transformed background, buttons that lose their fill or their border, images that show halos and light corners, sections that only half convert, and client-specific behavior nobody previewed. Six of the seven are build problems you can fix in the HTML. The seventh is a QA problem, and it is the one that ships, the kind campaign production management is meant to catch before send.

The useful mental model is three behavior families, not a list of clients. Some surfaces leave your message body alone and just darken the app shell around it. Some apply selective rewriting, closer to contrast repair than a mathematical invert. Some force an aggressive transform that flips your palette outright. One send gets all three treatments.

Why does my logo disappear in dark mode?

On a darkened surface the artwork and the background sit at nearly the same value, and the logo is gone. Same failure in reverse for a white knockout logo when a client lightens a dark section.

Where it happens: any partial or full invert surface, so Gmail iOS, Gmail Android, Outlook.com, Outlook mobile. The mechanic is that the client preserves your image while transforming the color around it.

The fix is to stop shipping a logo that depends on the background behind it. Give the mark 20 to 30 pixels of padding in a color that reads on both light and dark, add a thin keyline, or sit it on a controlled backing shape. A light and dark image swap using display:none plus max-height works in standards-friendly clients, but classic Outlook has known display:none inheritance bugs and Gmail may reveal both assets, so treat the swap as an enhancement. The fallback that always holds: pick a logo treatment with acceptable contrast on both #FFFFFF and #111111.

Why do my brand colors get rewritten?

You built a hero on #0B1F3A. In Gmail iOS it comes through as a washed pale blue. Already-dark designs carry the highest risk here, because a forced-dark transform can flip a dark section into a light one.

Where it happens: Gmail iOS and classic Outlook for Windows are the two aggressive surfaces. Neither gives you a reliable authored path out. Gmail does not support prefers-color-scheme as a practical targeting API, and classic Outlook renders through the Word engine with no dependable media query support.

There is a known workaround for Gmail accounts: declaring a surface as a one-color gradient, linear-gradient(#663399,#663399), survives the transform more often than a plain background color. It is a repair, not a theme. Gmail Android has been observed rewriting inline gradient values into broken CSS, and Gmail with a non-Google account strips most of the embedded CSS these hacks depend on. The reliable move is a mid-tone palette that stays on brand after a transform.

Why is my text unreadable after inversion?

A client can darken a card and leave #666666 body copy where it was, or lighten a colored panel and leave your #FFFFFF headline on top of it.

Where it happens: Gmail iOS is the worst case for white text on a brand color. Outlook web produces the subtler version, where a section darkens and the copy inside it survives at the wrong value.

Two fixes. First, avoid pure #000000 on pure #FFFFFF as your only contrast strategy and avoid light gray body copy, because both sit where a transform makes things worse. Second, for specific Gmail iOS failures with white text on a colored surface, the community blend-mode pattern nests mix-blend-mode: screen and mix-blend-mode: difference wrappers inside a gradient surface to push blackened text back toward white. Test it before production and keep the email readable without it.

Why do my buttons break in dark mode?

Two different failures, one symptom. In classic Outlook for Windows, a VML button fill and the HTML layer inside it are transformed through different paths, so you get a dark rectangle sitting behind the label, or a fill and a stroke that no longer match. Everywhere else, the fill changes but the one-pixel border, arrow, or icon stops separating the button from the surface behind it.

Keep the VML fallback scoped to classic Windows Outlook inside an MSO conditional, and keep the inner Outlook-only link background transparent so the two layers cannot disagree. New Outlook, Outlook web, and Outlook mobile are not VML clients, so do not reuse that pattern there. For the general case, do not rely on a thin border for legibility. Use a padded cell with bgcolor and an inline background-color, and pick a fill with enough contrast that the button reads even if the border is rewritten.

Why do my images have halos or light corners?

Three variants. A hero exported as a JPEG with a white background becomes a white slab floating in a dark email. Rounded corners cut as image slices stay light while the CSS background around them darkens, so the card visibly tears apart. And anti-aliased edges on transparent PNGs show a pale fringe once the surface behind them changes.

Outlook.com and Outlook web reliably reproduce the sliced-corner version: CSS colors get rewritten while image content is preserved.

The fixes are unglamorous. Use real CSS border-radius instead of image corners. Export artwork with genuine transparency rather than a baked white background. Keep a single flat background color behind image blocks so there is one color to reason about. Where an image has to carry a background, match it to a mid-tone that survives in both modes.

Why does only part of my email go dark?

Community inspection of Outlook web behavior points to a 4.5:1 contrast threshold and a lightness remap in CIELAB before it rewrites inline colors. That is why a card darkens while the #EEEEEE divider inside it stays bright, or a table cell keeps its bgcolor while its parent changes: each value is judged on its own.

Outlook.com also stores your original values in data-ogsc, data-ogsb, data-ogac, and data-ogab attributes, which is what makes [data-ogsc] and [data-ogsb] selectors useful as an override hook. Expect Outlook.com to write its own inline !important on top of yours, and expect your dark CSS to sometimes stay active after a recipient hits "Turn on the lights."

Practical rules: put backgrounds on tables and cells rather than only on body, pair bgcolor with background-color, use softer or semi-transparent dividers instead of a hard #EEEEEE rule, and always ship literal color fallbacks if you use CSS custom properties.

Why does it look fine in Gmail web but broken on my phone?

It darkens the interface around your email and leaves the message body close to how you authored it. Checking dark mode there and calling it tested is why most dark mode bugs reach an inbox.

Treat these as separate targets, because they behave differently:

Two caveats worth internalizing. color-scheme and supported-color-schemes meta tags are a signal that Apple-family clients honor, not a switch that opts you out of recoloring elsewhere. And recipients have their own controls, including light reading panes and background toggles, so part of your list sees the light version no matter what your HTML says.

How do you make dark mode part of QA, not a surprise?

Dark mode is not a separate test pass. It is a second row per client in the matrix you already maintain. If you have not built that matrix yet, start with which email clients are actually worth testing and pull the client and device split from your own opens.

Then make the checks explicit rather than leaving them to whoever opens the screenshots.

Those checks belong in the same pre-send checklist as your link and merge field checks, not in someone's head, alongside the rest of our production guides for that same sequence.

The last piece is where the evidence lives. A dark mode failure spotted in a Slack thread at 6pm on Thursday has a habit of being fixed in v4 and forgotten by v6. In LaunchSign, QA is a blocking validation phase on the markup deliverable: the checklist is recorded against the sealed version, comments are pinned directly on the render, and the campaign cannot reach client sign-off until that phase closes.

If that sounds like the gap in your current process, see how the production workflow handles it.

FAQ