Around 1 in 3 email opens now happens in dark mode, and most signatures weren't designed for it. Here's why dark mode mangles signatures and the design rules that ship one signature that survives both modes.
The MailSigCraft Team
MailSigCraft
You sent a signature with a black logo, a thin navy divider, and gray disclaimer text. It looked sharp in the editor preview. The recipient opens it on their iPhone in dark mode and sees: an invisible logo, a glowing white rectangle around the headshot, and disclaimer text so light it's barely there. The HTML didn't change between you and them — their mail client repainted your signature for dark mode, and the original design wasn't built for it.
Apple Mail (macOS + iOS), Gmail iOS, and Outlook 365 ship with dark mode active on devices set to system-dark. If your signature wasn't designed against the dark-mode renderer, roughly one in three recipients sees a broken version of it — and you almost never find out, because the sender-side preview always renders against your own theme.
This post walks through exactly why each thing breaks, and the design rules that fix it.
Test order if you want to catch the most bugs first: Apple Mail iOS dark mode (partial inversion catches most failures), then classic Outlook for Windows dark theme (catches anything full inversion mangles), then Outlook 365 web on a dark account.
If your logo is dark linework on a transparent PNG, it renders perfectly on a white email background — and disappears against a dark email background. Partial-inversion clients keep images as-is, so your black mark is now black-on-black with nothing in between.
Export two logo variants — logo-dark.png (dark linework, for light backgrounds) and logo-light.png (light linework, for dark backgrounds). Use the prefers-color-scheme media query to swap them:
<picture>
<source srcset="logo-light.png" media="(prefers-color-scheme: dark)">
<img src="logo-dark.png" alt="Acme" width="120" height="40">
</picture>
Apple Mail (macOS + iOS) honors prefers-color-scheme and serves the dark-mode variant. Gmail iOS and Outlook 365 ignore the <picture> swap and render the fallback <img> — so the fallback still has to be readable on dark.
If you can ship only one image, add a 1–2px outline stroke around the dark elements in your image editor: invisible against white, visible against dark, no media query needed.
Photographs and JPEG logos export with a solid background — there's no alpha channel in JPEG. On a dark email background, the JPEG renders as your logo plus a glowing white rectangle around it. This is the most-reported dark-mode signature failure, and the fix is one line of guidance: never ship a signature image as JPEG.
Re-export as PNG-24 with a transparent background. The email background shows through and the rectangle vanishes. If you absolutely need a photographic headshot, mask it to a circle in your image editor and export as PNG with the corners transparent — circular headshots dodge the rectangle entirely because there's no straight edge to glow.
Outlook 365 and Apple Mail auto-darken explicit light text colors during partial inversion. A disclaimer set to color: #999999 (light gray, intended to sit quietly on a white background) gets repainted darker against the dark background — usually landing somewhere around #444444, which now disappears against the email's dark gray. The "subtle" gray becomes invisible.
Use semi-transparent black for de-emphasized text instead of an explicit hex gray. color: rgba(0, 0, 0, 0.6) renders as gray-on-white in light mode and as 60% white-on-dark after partial inversion. The transparency adapts to whatever background sits behind it; a hardcoded hex value cannot. Same rule for "lighter than black" headings: rgba(0, 0, 0, 0.85) survives both modes; #222222 doesn't.
If your signature uses a thin horizontal rule (border-top: 1px solid #EEEEEE) to separate the name block from contact details, the dim border is invisible against the email's dark background. Partial-inversion clients keep the border at its original hex value, so a light gray rule sits on dark gray and reads as nothing.
Use a border with at least 40% opacity black: border-top: 1px solid rgba(0, 0, 0, 0.4). After inversion, it becomes 40% white — visible against dark. If you can't use rgba (older classic Outlook builds reject it), pick a mid-gray like #999999 that survives both modes at the cost of being a touch heavy on white. The wrong move is a near-white gray that only works in one mode.
Black monochrome social icons (the LinkedIn "in" glyph, the Twitter X) on a transparent background render perfectly on white. On dark, they disappear — same root cause as #1, but more obvious because social icons sit in a row and you notice the holes.
Two reliable choices. Either ship monochrome white social icons with a prefers-color-scheme swap (per #1), or use brand-colored social icons — LinkedIn blue, Instagram pink-orange, GitHub gray, X black-with-white-glyph-on-circle. Brand colors render fine in both modes because the hex stays the same and the icons have built-in contrast against both white and dark backgrounds. Brand colors are also more recognizable, so they double as accessibility wins.
Classic Outlook for Windows in a dark Windows theme fully inverts every CSS color. A signature with color: #000000 text on a background: #FFFFFF body becomes white-on-black — which is what you want. The failure mode is when only part of your signature has a background set: the unbacked cell inverts, the cell with background: white does NOT invert (Outlook treats explicit white as intentional), and now you have white-on-white text inside a dark email.
Either set a background color on every cell or set it on none of them. Consistent declaration means consistent inversion. The most common cause of this bug is a single "highlight" cell (a yellow CTA banner, say) sitting inside an otherwise unbacked signature — that highlight cell now refuses to invert while everything around it does.
The reliable workflow is to design against the strictest renderer (partial inversion, since it's the most common) and confirm the other two work as a side effect.
Every image either has a transparent background or a brand-color background — never white. No JPEG inside a signature. PNG-24 with transparency for logos and icons.
Every "subtle" color is rgba, not hex. rgba(0, 0, 0, 0.6) for disclaimer text, rgba(0, 0, 0, 0.4) for borders, rgba(0, 0, 0, 0.85) for de-emphasized headings. The transparency adapts to whatever background sits behind it.
Either set a background color on every cell or none of them. Mixed declarations are the #1 cause of Outlook full-inversion bugs.
Apple Mail iOS dark mode → classic Outlook for Windows dark theme → Gmail iOS dark. If it works in all three, it works everywhere.
The MailSigCraft editor ships these four defaults out of the box — uploaded logos render with transparency, "subtle" text uses rgba, the templates avoid mixed-background mistakes, and the rendered HTML includes the prefers-color-scheme logo swap automatically. The output paste-tests across light and dark on every major client without changes.
Add a prefers-color-scheme swap for the logo. Apple Mail honors it; the rest render the fallback. Cheap insurance for the largest signature element.