Dark mode can change your email colours because the recipient’s email app applies its own reading treatment. It may adjust light areas, change dark areas too, or leave the HTML colours alone. Check the actual delivered message: the useful goal is readable text, a recognisable logo and a clear action in both reading modes.
A button changing shade and a button losing its label are different problems. Give the template owner that distinction before asking them to preserve every brand colour.
Why can the same email look different in dark mode?
Receiving apps treat colours differently: some leave the HTML colours alone, some adjust light areas, and some change dark areas too. The app’s interface, its message-reading background and your email’s styling are also separate things. Microsoft documents reading-pane controls that let a message have a light background while the surrounding interface stays dark.
Client behaviour also varies. In Litmus’s February 2025 tests, the Gmail iOS app applied full colour inversion, its Android app partial inversion, and Outlook 2021 on Windows full inversion. Those are dated observations, not guarantees for today’s versions. They show why “it works in my inbox” needs an app, platform and reading mode attached.
An image and the area behind it can become a particularly awkward pair. In Rémi Parmentier’s April 2021 Gmail iOS demonstration, the background became lighter and white lettering inside a logo image became almost invisible. Treat that as a pairing problem: test the artwork against the background the app actually renders.
Before investigating code, record the exact app and operating system, the version where available, and whether the message-reading view is actually dark. An address ending in a particular mailbox domain is not a complete description of the receiving environment.
Which colour changes should you fix first?
Separate readability failures from brand variations: fix unreadable offer text, button labels and footer links first, then decide whether a remaining shade change is acceptable. Use the following as a proposed acceptance order for your template:
| What you see in the delivered message | Decision to make | First repair to investigate |
|---|---|---|
| Offer, price or conditions merge with the background | Treat as a readability failure | Adjust the text/background pair and retest both modes |
| Button label disappears, even though the button is visible | Treat as an action-label failure | Check the label and button fill together |
| Logo lettering disappears against the header | Repair brand recognition | Try artwork with a protective outline or background treatment |
| Button changes shade but its label remains clear | Make an explicit brand decision | Decide whether that tested variation is acceptable before adding a workaround |
| Footer links become difficult to read | Repair the footer | Give its text and links the same contrast review as the offer |
For example, imagine an email whose button becomes darker but remains readable in one test, while its label merges with the background in another. These are illustrative results, not predictions for named clients. The second needs a readability repair; the first needs a decision about the acceptable brand treatment.
Use a contrast check to support that judgment. WCAG’s Level AA text criterion specifies at least 4.5:1 for ordinary text and 3:1 for large-scale text, subject to its exceptions. Large-scale means at least 18 point, or 14 point bold, or the specified equivalent CJK sizes. Do not assign the lower threshold merely because a heading looks large.
Check the rendered text and background, rather than assuming the design file’s original values survived. These ratios address text contrast; they do not certify the entire email’s accessibility. Logo text has an exception under this particular criterion, but an invisible brand name is still worth fixing.
How should you protect logos and handle dark-mode CSS?
Start with a default logo that you are willing to show when special styling does not run. A dark-mode image swap should improve that fallback, rather than be the only way the brand remains recognisable.
Litmus’s guide illustrates a light outline or glow around dark transparent artwork, or a background shape behind an icon. Treat these as options to test against your header, not guarantees that an asset will survive every receiving app unchanged.
Then ask the template owner three concrete questions:
- Does the editor preserve the template’s head and dark-mode styles through sending?
- Which receiving environments can use those styles or select an alternate image?
- What text colours and default image remain when the styling is ignored?
@media (prefers-color-scheme: dark) can express a dark theme where supported. It does not give a sender universal control over the inbox. Can I email’s compatibility record documents support gaps and rewritten queries, and labels the feature last tested in March 2023. Use that record to plan tests, rather than as proof about every current version.
Google’s CSS documentation says unsupported properties and selectors may be ignored and documents media queries for width, orientation and resolution. Browser support for a dark-mode rule does not establish that the delivered email will use it.
Client-specific workarounds need equally specific acceptance tests. Parmentier’s 2021 blend-mode technique targets a particular rendering problem and limits its blending method to white text. He also warns that applying the blend markup without targeting can leave black backgrounds in clients without blend-mode support. A copied snippet needs its target, limitations and fallback checked together.
How do you test the actual email before sending?
Send the template through the intended sending path to test accounts, then inspect those delivered messages in light and dark reading views: offer text, button label, logo, footer and the images-off fallback. Use the following sequence as a practical acceptance check:
- Identify the environment. Record the app, platform, version/build where available, account type if relevant, and actual message-reading mode.
- Compare light and dark views. Inspect the same message’s offer, conditions, button label, logo and footer. Save screenshots of defects.
- Check the fallback. With images hidden where the app permits it, check whether the offer, action and footer remain understandable. Separately test what happens when an alternate dark-mode image is not selected.
- Record the decision. Distinguish an unreadable element from an acceptable colour change. Assign a repair owner rather than leaving an unlabelled screenshot in chat.
- Retest the changed template. Repeat the affected environments in both modes before accepting that revision.
For before-and-after inspection, Microsoft’s documented new Outlook and web views offer Turn on the lights at the top of the reading pane to show original formatting; look under More if the control is hidden. Use it to diagnose the difference, rather than asking customers to change their preferences to read the message.
Keep a record the next person can reproduce:
| Check field | What to save |
|---|---|
| Message | Template name, revision and test-send date |
| Receiving environment | Exact app/platform, version where available and reading mode |
| Affected component | Offer text, button, logo, footer or another named element |
| Evidence | Light/dark screenshots and rendered text/background contrast where relevant |
| Fallback | Images-off result and default-logo result when a swap does not run |
| Resolution | Acceptable variation or repair required; owner and retest outcome |
A browser preview or editor toggle alone is not this test record. If you are assessing AI-assisted production, include the repair and retesting effort in the full email-production time budget.
Keep the diagnosis specific, too. A delivered email with an unreadable button needs rendering work; rejection or spam placement needs the separate deliverability diagnosis.
Frequently asked questions
Can you force every recipient to see a white email background?
Do not treat one CSS setting as a universal solution. Receiving apps differ in their colour treatment and CSS support. Test the actual message in the environments you need to support, including its fallback when a special rule is ignored.
Does a dark-mode image swap solve a disappearing logo?
It can help where the receiving app supports the required styling. Keep a usable default logo and test that fallback separately; the alternate image cannot protect the brand when the selection rule does not run.
Is keeping the original button colour enough?
No. Check the label against the rendered button fill in both reading modes. An unchanged background is not proof that the text stayed readable. Accept the pair together, then decide whether any remaining shade change is acceptable for the brand.