Which Email Clients Should You Actually Test?

Test the clients your audience actually opens in. For most lists that means five to seven environments covering 90% or more of opens, and everything past that is coverage you pay for in test credits and producer attention without reducing risk. Pull your own client and device breakdown from your ESP, keep every dark-mode-capable client in the suite, add Outlook on Windows if any meaningful part of your list is B2B, and skip the rest until a real support ticket proves you wrong.

That is the whole strategy. The rest of this article is how to build the matrix, which clients earn a permanent slot regardless of share, and how much testing each version of a build actually deserves. Render testing is one QA gate inside the wider discipline of campaign production management.

Why is testing 90 clients procrastination?

Ninety clients sounds ten times safer than nine. It is not, for three reasons.

A large share of any catalog is dead weight. Lotus Notes 8.5, AOL Desktop, old Thunderbird builds: they stay in test suites long after they left real inboxes. A second chunk is duplicates. Gmail in Chrome, Gmail in Firefox, and Gmail in Safari are one rendering engine and one CSS support profile with three screenshots. A third chunk is traffic you do not have. If 0.1% of your opens come from an environment, a broken layout there affects fewer people than the typo you missed while scrolling thumbnails.

The deeper problem is what wide testing does to attention. Forty screenshots get skimmed. Six get read. The failure modes that actually damage a send are specific and repeatable: a logo disappearing in dark mode, a button collapsing in Outlook, a preheader colliding with the subject line on a 375px screen. Those are found by looking carefully at a small number of renders, not by generating a large number of them.

Anyone who has maintained a browser support matrix knows the reflex. You do not test IE11 because it exists. You test it because analytics say 6% of your users are still on it, and you drop it the quarter that number goes under one. Email gets that discipline less often because the tooling makes exhaustiveness feel free.

How do you build your test matrix from your own opens?

Your ESP already has the report. It is usually called "Email client," "Device," or "Environment," and it sits in campaign analytics rather than in the audience section. Two rules when you pull it: use 90 days of sends rather than one campaign, and segment it by list. A B2C promo list and a B2B nurture list rarely share a top five.

For context, here is the global aggregate (not your list, everyone's, averaged together) from Litmus's Email Client Market Share report, calculated from over a billion tracked opens as of May 2026:

Four environments clear 95% of opens, globally. That is not a number you should test to, though. It is an average of every list on earth, and averages erase exactly the variation that matters to yours. A B2B list skews hard toward Outlook desktop, often well past this 6.49%, because that is where its audience actually works. A list concentrated in one country picks up whatever webmail is locally dominant there, not this Yahoo Mail figure. That is the whole reason to pull your own report instead of testing to this table.

Two caveats even so. Apple's Mail Privacy Protection pre-fetches images on open, and Litmus itself notes MPP is behind the majority of tracked opens today, so Apple's share here is inflated relative to real reading behavior. Treat client share as directional, and sanity check it against the user agents behind your clicks, not just your opens. Second, agency side this is a per-client exercise. Your fashion retail account and your logistics SaaS account do not get the same suite, and assuming they do is how a broken Outlook build reaches a procurement director.

Rendering on your real top clients is one item on a longer pre-send list, and it works best sitting inside the rest of it. The pre-send checklist covers where this check belongs in sequence, and who signs off on it.

Which clients earn a permanent slot?

Dark-mode-capable clients. This is where most modern rendering damage happens, and it does not need a design change to appear. Apple Mail on iOS and macOS invert aggressively. The Gmail app inverts partially and inconsistently by version. Outlook.com applies its own color logic. The concrete failures: a logo saved as a transparent PNG with dark text vanishes into a dark background, a #FFFFFF container gets shifted to a color the designer never chose, hairline borders disappear, and text set in #1A1A1A stays dark against a background that also went dark. For the full breakdown of what causes each of those failures and how to fix them, see why your email looks broken in dark mode. Keep one full-inverting client and one partial-inverting client in every suite. That pair catches most of it.

Outlook desktop on Windows, if you have any B2B audience. It renders through Word: no background images without a VML fallback, border-radius ignored, margin frequently dropped, 120 DPI scaling that stretches fixed-width tables. Three percent of a B2C list is arguably skippable. Three percent of a B2B list is often the enterprise buyers, and a collapsed CTA in front of them costs more than the test credit.

Whatever broke last time. Keep a scar list next to your template documentation. If a Samsung Mail render ate your two-column footer in March, Samsung Mail stays in the suite until you have shipped three clean sends with a rewritten footer. Cheapest institutional memory a production team has, and almost nobody writes it down.

One thing that is not a client but belongs here: keep a real device in the loop. A physical iPhone with the actual send in the actual Mail app shows you tap target size, subject truncation, and load behavior on a weak connection. No screenshot service reproduces that.

How much testing does each version deserve?

Spot checks in between, matched to what changed.

The logic is risk, not ritual. Version 1 carries structural risk: the HTML is new and nobody has seen it in a real client. The final build carries last-mile risk: copy was edited, links were swapped, and personalization tokens were added after the layout was approved. Those two get everything.

Between them, match the test to the change. A copy revision that lengthens a headline from 34 to 51 characters is a layout risk in exactly two places: Outlook desktop, where the fixed-width table has no give, and the iOS preview line, where the subject and preheader pair gets cut. Test those two, spend four minutes, move on. A swapped hero image is a dark mode risk, so run the inverting pair. A new module with a background color is a full-suite event even if it is v3, because it introduces the same structural risk as v1 did.

Render tests are not free. Platform plans meter them, each round takes five to ten minutes of a producer's attention, and a suite run on v2 of a copy-only change is time taken from the check that would have caught the wrong UTM. One exception to the spot-check rule: when a build goes out for client approval, treat it as a final version and run the whole thing. The approval you are asking for is on the render as much as on the words.

Testing is one part of the production sequence that sits between an approved brief and the ESP, one of several production guides we've written about that gap. For how that whole sequence gets coordinated end to end, see managing a campaign from brief to sign-off, which covers the category and where the tooling overlaps.

In LaunchSign, render screenshots stay attached to the version they belong to, so an approver can see which build they signed off on rather than which build was current when they replied. More on how that works.

FAQ