What this is for#
When a recipient reads your email in dark mode (their OS or their mail client set to dark theme), mail clients silently invert your colors — sometimes correctly, sometimes destructively:
- White logos disappear on dark backgrounds
- Black text in colored cards becomes white-on-similar-color = unreadable
- Brand colors get auto-shifted by Gmail Android's "color extraction" algorithm
- Transparent-background PNGs show black halos against light fill
This guide walks the 4 patterns that survive dark mode + the per-client behavior + the testing protocol.
Per-client dark mode behavior (2026)#
| Client |
Dark mode behavior |
| Apple Mail (iOS, macOS) |
Respects color-scheme meta; doesn't aggressively re-color; honors @media (prefers-color-scheme: dark). Best behavior. |
| Gmail (iOS app) |
Respects color-scheme; doesn't aggressively re-color. Good behavior. |
| Gmail (Android app) |
AGGRESSIVE color inversion — re-colors backgrounds; doesn't respect color-scheme consistently. Worst behavior. |
| Gmail (web) |
Doesn't aggressively re-color; honors light/dark via the user's Gmail theme setting. |
| Outlook (Windows desktop) |
Partial dark mode; behavior varies by version. Some Microsoft Word renderer quirks. |
| Outlook.com (web) |
Honors prefers-color-scheme reasonably. |
| Yahoo Mail |
Aggressive — similar to Gmail Android. |
| Newer apps (Hey, Spark, Newton) |
Mostly Apple-Mail-like behavior. |
The takeaway: design for Apple Mail's behavior; test against Gmail Android.
The 4 patterns that work#
Pattern 1 — Declare your color-scheme support#
Add to the email's <head>:
<meta name="color-scheme" content="light dark">
<meta name="supported-color-schemes" content="light dark">
This tells the client: "I have explicit dark-mode styles — don't auto-invert." Most modern clients respect it; Gmail Android often ignores it (but no harm).
Pattern 2 — prefers-color-scheme media query#
In your <style> block (which most clients honor for @media even if they strip individual style rules):
<style>
@media (prefers-color-scheme: dark) {
.dark-bg { background-color: #1a1a1a !important; }
.dark-text { color: #f4f4f4 !important; }
.dark-border { border-color: #444 !important; }
/* Swap logo */
.logo-light { display: none !important; }
.logo-dark { display: inline-block !important; }
}
</style>
Apply via class names on your HTML elements:
<td class="dark-bg" style="background-color: #ffffff;">
<h1 class="dark-text" style="color: #333333;">Hi {FIRST_NAME}</h1>
...
</td>
!important is essential — without it, the inline style="..." wins over the @media rule.
Pattern 3 — Dual-logo swap#
Ship both a light-mode and a dark-mode logo. Show one or the other based on the active mode:
<!-- Light-mode logo: visible by default; hidden in dark mode -->
<img src="https://your-cdn.com/logo-light.png"
alt="Acme Logo"
width="180" height="40"
class="logo-light"
style="display: inline-block;" />
<!-- Dark-mode logo: hidden by default; visible in dark mode -->
<img src="https://your-cdn.com/logo-dark.png"
alt="Acme Logo"
width="180" height="40"
class="logo-dark"
style="display: none;" />
Combined with the @media (prefers-color-scheme: dark) in Pattern 2:
@media (prefers-color-scheme: dark) {
.logo-light { display: none !important; }
.logo-dark { display: inline-block !important; }
}
In clients that respect the media query: only one logo renders. In clients that ignore it: both render (uncommon, looks slightly awkward but not broken).
Pattern 4 — Avoid pure-white logos with transparency#
Why: a white-fill PNG with transparent background renders fine on white. On dark mode, it becomes "white shape on dark background" — readable. But if the client auto-inverts (Gmail Android), the white fill becomes black-on-dark = invisible.
Three safer alternatives:
- Dual-logo swap (Pattern 3) — explicit + reliable
- Solid-color background behind the logo — wrap the IMG in a
<td bgcolor="#ffffff"> so the logo always sits on white regardless of email mode
- Two-tone logo design — a logo that reads correctly on either light OR dark background (most modern brand logos meet this bar)
For body imagery (product shots, illustrations), prefer photos / colorful illustrations over single-color silhouettes — they look fine in either mode.
Worked example — dark-mode-compatible template fragment#
<head>
<meta name="color-scheme" content="light dark">
<meta name="supported-color-schemes" content="light dark">
<style>
@media (prefers-color-scheme: dark) {
.card-bg { background-color: #1f2937 !important; }
.card-text { color: #f3f4f6 !important; }
.card-muted { color: #9ca3af !important; }
.card-border { border-color: #374151 !important; }
.logo-light { display: none !important; }
.logo-dark { display: inline-block !important; }
.cta-bg { background-color: #3b82f6 !important; }
}
</style>
</head>
<body style="background-color: #f4f4f4; margin: 0;">
<table role="presentation" width="100%" cellpadding="0" cellspacing="0" border="0">
<tr>
<td align="center" class="card-bg" style="background-color: #f4f4f4; padding: 20px;">
<table role="presentation" width="600" cellpadding="0" cellspacing="0" border="0" class="card-bg" style="background-color: #ffffff;">
<tr>
<td style="padding: 40px;">
<!-- Logo (light + dark variants) -->
<img class="logo-light" src="https://cdn.example.com/logo-light.png" width="180" height="40" alt="Acme" style="display: inline-block;">
<img class="logo-dark" src="https://cdn.example.com/logo-dark.png" width="180" height="40" alt="Acme" style="display: none;">
<h1 class="card-text" style="color: #111827; font-family: Arial, sans-serif;">
Hi {FIRST_NAME}
</h1>
<p class="card-text" style="color: #374151; font-family: Arial, sans-serif; line-height: 1.5;">
Body content here.
</p>
<p class="card-muted" style="color: #6b7280; font-size: 14px;">
Smaller secondary text.
</p>
</td>
</tr>
</table>
</td>
</tr>
</table>
</body>
Testing protocol#
- Send a test to yourself in each of: Gmail (Android app), Gmail (iOS app), Apple Mail (iOS), Apple Mail (macOS), Outlook (Windows), Outlook (web). Set each client to dark mode before sending. Compare rendering.
- Use Litmus or Email on Acid — both have dark-mode preview rendering across clients
- Re-test after every template change — small CSS adjustments can break dark-mode behavior in non-obvious ways
The combination of "Gmail Android (dark mode)" + "Apple Mail (light mode)" is the 90% test — if both look right, you're probably fine elsewhere.
Common failures#
| What you see |
Likely cause |
Fix |
| Logo disappears in dark mode |
White-fill logo on now-dark background |
Switch to dual-logo swap (Pattern 3) or solid-color background wrapper |
| Background card stays light, text becomes hard to read |
prefers-color-scheme styles not applied |
Add !important on every dark-mode rule |
| Gmail Android colors look weird (different from desktop) |
Gmail Android's auto-inversion algorithm |
Try declaring color-scheme: light dark — sometimes Gmail Android backs off; otherwise accept the variance |
| Two logos both visible |
Client ignored @media query |
Acceptable degradation in dark mode-unsupporting clients; doesn't break readability |
| Outlook desktop ignores dark-mode CSS entirely |
Outlook desktop has weak prefers-color-scheme support |
Design "good enough in light mode + acceptable in dark mode" — don't try to force a specific Outlook dark experience |
| Tested in Apple Mail looks great; user reports terrible dark in Gmail Android |
Forgot Gmail Android's color inversion |
Test in Gmail Android explicitly during design phase, not after launch |
FAQ#
Should I just send everything as plain text and skip dark-mode design? Plain-text emails inherit the system theme automatically and never break. For transactional + newsletter emails, plain text can be the right answer. For marketing campaigns with rich content + CTAs, dark-mode-friendly HTML is worth the investment.
Do I need dark mode if my audience is mostly desktop Outlook users? Less urgent. Outlook desktop's dark mode support is partial; many users disable it. Audit your open data (most email platforms can break out "open in dark mode") to prioritize.
What about hi-contrast / forced-colors mode? Even further niche. forced-colors: active media query lets you target Windows High Contrast mode. Not worth the effort for most senders.
Does dark mode affect deliverability? No — receivers don't penalize dark-mode-friendly emails. The rendering happens client-side.
Can AcelleMail's drag-and-drop editor generate dark-mode-friendly HTML? Partially in recent versions. For full control, edit the HTML directly after building the structure.
Related articles#
