Email clients

Quick answer: Email clients are the apps people use to read mail – Gmail, Apple Mail, Outlook, Yahoo. For anyone building email, though, each one is a rendering environment: an app, an operating system, and an engine that together decide whether your layout survives. Two clients, Apple Mail and Gmail, pull in roughly 90% of all opens. The engines underneath them disagree about almost everything, which is why one email can look perfect in one inbox and broken in the next.

Email clients are the single biggest reason email development is harder than web development, and most guides about them never tell you that. They define an email client as software for sending and receiving mail, list a few names, mention IMAP versus POP3, and stop. Fine for an end user. Useless for the person who has to make a campaign render across forty of them. This entry takes the developer’s view. We cover what an email client really is, the three shapes they come in, the rendering engines that actually matter, who uses what, how dark mode splinters across them, and the Outlook shift that runs all the way to 2029. The honest version, with the parts the generic pages skip.

What an email client actually is

Start with the plain definition, because beginners and AI tools both need it.

An email client is a piece of software that connects to a mail server and lets you send, read, and organise email. It talks to that server using protocols: IMAP or POP3 to fetch mail, SMTP to send it. IMAP syncs across devices. POP3 downloads and often deletes from the server. Most modern setups use IMAP.

That is the textbook answer. Here is the distinction people trip over.

An email client is the tool you read mail in. An email provider is the service that stores it. Apple Mail is a client. Gmail-the-account is a provider. The Gmail app is both at once.

So far, so dull. None of that is the interesting part for an email developer.

The part that matters for developers

For anyone coding email, an email client is a rendering environment. It is one more place your HTML can fall apart. Each client interprets your markup its own way. Some strip your CSS, ignore your padding or invert your colours without asking.

And you do not get to choose. Your subscribers pick their client, not you. You write one email, and it has to survive every client on your list. That is the whole job, really.

Webmail, desktop, mobile: the three shapes of email clients

Email clients come in three broad shapes. Knowing the shape tells you something about how it will behave.

• Webmail. Opened in a browser. Gmail.com, Outlook.com, Yahoo Mail on the web.
• Desktop apps. Installed on a computer. Classic Outlook for Windows, Apple Mail on macOS, Thunderbird.
• Mobile apps. On a phone or tablet. Gmail for iOS and Android, Apple Mail on iPhone, Outlook mobile.

Simple enough. Here is the trap.

The same brand renders differently

A single brand is not a single email client. Gmail on the web is not Gmail on Android. Gmail on Android is not Gmail on iOS. They share a name and behave like three separate products when it comes to rendering.

This is where beginners burn an afternoon. Someone says “I tested it in Gmail.” That tells you almost nothing. Which Gmail? On what device? Desktop Gmail does not support media queries. Mobile Gmail handles dark mode differently again. The label hides three engines wearing one coat.

Apple Mail has the same issue. It is iOS Mail, iPadOS Mail, macOS Mail, plus everything bundled under Apple’s privacy bucket. Shared roots, individual quirks. Test the platforms, not the brand.

The part that matters: rendering engines

This is the heart of it, and the thing almost no glossary page covers.

Web browsers grew up. They converged on standards. Blink, WebKit, and Gecko all read the same CSS and mostly agree on the result. You write a layout once, it works everywhere. Email clients never had that moment. Each one made its own choices about which HTML and CSS to support. Those choices are wildly inconsistent and decades apart.

So when you ask “how do email clients render HTML,” there is no single answer. It depends entirely on the engine underneath.

The engine map

Here is what powers each major client, and the thing it tends to wreck.

Read that Outlook row again. Classic Outlook for Windows renders email with the Microsoft Word engine. Yes, Word, the document program, on a 2007-era core. In 2026 you are coding for a layout engine older than the iPhone.

Why that one row drives developers up the wall

Word was never built to render web pages. It ignores your margins in places, eats padding or throws random white lines between table cells. Float and position are out. Flexbox and grid may as well be science fiction.

So you fall back on nested tables, ghost tables, and VML for backgrounds. You declare widths twice, once as an HTML attribute for Word and once in CSS for everyone else. It is genuinely ridiculous, and it is the daily reality of cross-client email. The related entries on nested tables and srcset go deeper on those specific workarounds.

Who actually uses what: email client market share

You cannot test everything equally. Market share tells you where to spend your effort. The numbers in 2026 are lopsided, and that is good news.

Apple Mail and Gmail together account for roughly 90% of all email opens. Apple Mail sits anywhere from about 45% to 58% depending on the month and the measurement method. Gmail runs roughly 23% to 31%. Everything else splits the remaining sliver.

Optimise for those two and you have covered most of your list. That is the headline. But there is an asterisk, and it matters a lot for some audiences.

The B2B asterisk

Outlook looks tiny by consumer opens. Reported share lands somewhere between 3% and 10%, depending on who is counting. Easy to dismiss.

Do not dismiss it. Outlook dominates the workplace. It is tied into Microsoft 365, and a large share of big companies run on it. Industry estimates put it across roughly 60% of major enterprises. So if your audience reads mail at work – corporate marketers, B2B course buyers, anyone in an office – Outlook punches far above its consumer share. For a B2B sender, Outlook is not an edge case. It is the main event.

A word on trusting these numbers

Be a little sceptical of any single figure. Apple’s Mail Privacy Protection pre-loads images, which inflates Apple’s “opens.” Single-month numbers swing. Different tools measure differently, which is why you see Gmail quoted at 23% one place and 31% another.

Treat any one percentage as a snapshot, not a law. And here is the practical move: your own top-ten list of email clients is not the global one. Pull it from your own analytics. Your audience is not the world’s average.

Mobile is the default now

One more reality. Most email gets opened on a phone. And on mobile, the iPhone is overwhelming – somewhere near 90% of mobile opens happen on an iPhone. Which means Apple Mail effectively sets your design baseline whether you planned for that or not. If it looks wrong on an iPhone, it looks wrong for most of your list.

Dark mode: the same email, a different outcome in every client

Dark mode belongs in any serious discussion of email clients, because it is not a setting you control. It is a behaviour the client applies to your email after it arrives. And every client does it differently – five major behaviours across the clients below, not one.

Adoption is real. Depending on the audience, somewhere between a quarter and 40% of readers open mail in dark mode. So this is not a fringe concern any more.

Here is how the major email clients handle it.

• Apple Mail. Respects the prefers-color-scheme media query. You get real control. Write proper dark styles and they apply.
• Gmail on iOS. Full inversion. Light backgrounds go dark, dark text goes light, images get flipped too. High risk for designs that were already dark.
• Gmail on Android. Partial, algorithmic darkening. It changes some colours and leaves others. Different from Gmail iOS, so test both.
• Classic Outlook (Windows). Force-inverts your colours with the Word engine, and there is basically no clean coding hook to override it. This is the one to design around, not code around.
• Outlook.com and the Outlook app. These are the ones that hand you the data-ogsc and data-ogsb attributes (Outlook saves your original text colour in data-ogsc, your original background in data-ogsb), which you can target in a <style> block. People mix this up constantly and slap those selectors on hoping classic desktop Outlook will read them. It won’t. Different Outlook, different engine.

What that means in practice

You cannot make dark mode look identical everywhere. So you design defensively instead. Use solid background colours, not faint greys that turn harsh when inverted. Give logos a transparent PNG so they do not get a white halo. Then test the logo and the call-to-action button specifically, in dark mode, on the clients your audience uses.

This is a per-client problem, not a global toggle. That alone is a reason to understand email clients individually rather than as one blurry category.

The Outlook shift: what changes through 2029

This is the freshest and most misunderstood part of the email client landscape. The dates keep moving, and half the advice online is already stale.

The good news first. The new Outlook for Windows dropped the Word engine. It now runs a Chromium-style, web-based core, much like Outlook.com. That means real HTML and CSS. In the new Outlook, ghost tables and VML stop being mandatory. The single worst rendering engine in email is finally on its way out.

So why do you still build for the old one? Timing.

The real Outlook timeline

The “tables are dead” crowd loves to name an end date. The end date keeps slipping. Here is where things actually stand, from current Microsoft and industry sources.

Read the bottom row twice. Classic Outlook, the one running Word, is supported until at least 2029 for Microsoft 365 and perpetual licences. After cutover, enterprises can still download and deploy it on their own. And don’t let that October 2026 row fool you – that is the Office 2021 perpetual suite hitting end of support, not the Word rendering engine packing up. Anyone on a Microsoft 365 subscription keeps classic Outlook, and its Word-based rendering, for years past that. The engine you keep cursing at is not going anywhere on that date.

Why this matters for your build

The opt-out already slipped a full year, from April 2026 to March 2027. The new Outlook still lacks features that power users rely on, which is part of why Microsoft keeps pushing the dates. Enterprises move slowly by nature. So the Word engine is not vanishing on any neat schedule.

Anyone telling you to drop tables in 2026 is coding for their own inbox, not their audience’s. The sober move is the hybrid approach: a solid table base that holds at any width, with modern CSS layered on top for the clients that support it. Tables for the floor, CSS for the polish. That stays correct for years yet.

Which email clients should you actually test in?

Direct answer, because this is the question people really came for.

You cannot test forty clients by hand. You do not own forty. So you test a representative set and trust tooling for the rest. Here is a realistic minimum.

1. Apple Mail – iOS and macOS. Your baseline and your biggest audience.
2. Gmail – web, Android, and iOS. Three different behaviours, remember.
3. Classic Outlook for Windows – the Word engine, the thing most likely to break.
4. New Outlook / Outlook.com – the Chromium future, increasingly common.
5. One wildcard – whatever your analytics show. Often Yahoo or Samsung Mail.

Test each one in light mode and dark mode. That doubles the list, and it is not optional any more.

Why you cannot eyeball it

There are something like forty client, OS, and engine combinations in regular use. You have personal access to maybe four. Your inbox is not forty inboxes. The one client you skipped is reliably the one that breaks. Outlook especially will find the single mistake you missed.

This is where testing platforms earn their place. They render your email across dozens of real clients and flag problems before you hit send.

A note on testing tools

A few things shifted recently, so old tutorials mislead.

Litmus changed its pricing hard after the Validity acquisition. As of 2026 the Core plan starts at $500 per month, covering 5 users and 2,000 previews. The cheap old entry tiers are gone. For a solo freelancer that stings. For a team shipping weekly, the time saved can still pencil out.

Email on Acid, now under Sinch, was the more budget-friendly competitor, and a lot of small shops moved there after the Litmus change. Heads up, though, because this one is mid-transition as I write. Sinch is folding Email on Acid into a rebuilt platform called Mailgun Inspect, and existing Email on Acid contracts start migrating to it from June 2026. The emailonacid.com address now points at Mailgun. Same core previews, new name, new usage-based pricing where you pay for the devices you actually test instead of a flat tier. If you go looking for “Email on Acid” and land on Mailgun, that is why – it is not a different tool, it is the same one wearing a new badge.

One more, since people still ask. Putsmail, the old free send-a-test tool, is no longer available. If a guide points you there, the guide is stale. Whatever you pick, test on real renders. Never trust a single preview.

Email clients and the next five years

Nobody owns a crystal ball. But the direction is fairly clear, and building for today without watching the horizon is how you redo everything in 2028.

• 2026 to 2027. Classic Outlook share bleeds slowly. Apple Mail and Gmail stay dominant. Dark mode moves from afterthought to standard QA on every send.
• 2027 to 2028. New Outlook becomes the default for more organisations. You start trusting CSS more in your base layout, while still shipping a table fallback.
• 2028 to 2029. If cutover actually lands, the Word-engine requirement softens for real. Leaner markup becomes safe for a wider slice of your list.
• Across all of it. Privacy features in the style of Apple’s Mail Privacy Protection spread further. Open tracking gets less reliable. Client detection itself gets murkier.

The thing that does not change

Your own analytics matter more, not less, as tracking gets fuzzier. Real-client testing never stops mattering, because legacy email clients persist for years after the headlines declare them dead. The new Outlook arriving does not retire the need to test.

The label keeps shifting. Email clients multiply, merge, and swap engines. The job underneath stays exactly the same. Clean code in, inbox-safe HTML out, checked on real clients before it reaches a subscriber.

Frequently asked questions

What is an email client?

An email client is software that lets you send, read, and organise email. It connects to a mail server using protocols like IMAP, POP3, and SMTP. Common examples are Apple Mail, Gmail, Outlook, and Yahoo Mail. For email developers, each client is also a rendering environment that displays HTML its own way.

What is the difference between an email client and an email provider?

The client is the tool you read mail in. The provider is the service that stores it. Apple Mail is a client you can use to read a Gmail account, where Gmail is the provider. Some products are both – the Gmail app is a client and Gmail is also a provider.

Which email client has the most market share?

Apple Mail leads, somewhere around 45% to 58% of opens depending on the month. Gmail is second, roughly 23% to 31%. Together the two account for close to 90% of all opens. Outlook is small by consumer share but dominates business and enterprise inboxes.

Why does my email look different in Outlook?

Because classic Outlook for Windows renders email with the Microsoft Word engine, not a browser. Word ignores much of modern CSS, including background images, flexbox, and border-radius. Apple Mail uses WebKit and the new Outlook uses Chromium, so both render far closer to web standards.

Do I still need to code for classic Outlook in 2026?

Yes, for most senders. Classic Outlook is supported until at least 2029, and its enterprise opt-out was delayed to 2027. Plenty of business inboxes still run the Word engine. Use a hybrid build: a table base for Outlook, with modern CSS layered on top.

What is the difference between new Outlook and classic Outlook?

Classic Outlook for Windows uses the Microsoft Word engine and breaks modern CSS. The new Outlook for Windows runs a Chromium-based web engine, similar to Outlook.com, and supports far more standard HTML and CSS. Both currently coexist, which means you may need to support each.

Which email clients should I test my emails in?

At minimum: Apple Mail on iOS and macOS, Gmail on web, Android, and iOS, classic Outlook for Windows, and the new Outlook or Outlook.com. Add one wildcard your analytics flag, like Yahoo or Samsung Mail. Test every one in both light and dark mode.

Do all email clients support dark mode the same way?

No. Apple Mail respects prefers-color-scheme and gives real control. Gmail on iOS fully inverts colours. Gmail on Android applies partial, algorithmic darkening. Classic Outlook for Windows force-inverts through the Word engine with no clean override. Outlook.com and the Outlook app are the ones that expose the data-ogsc and data-ogsb hooks you can target. The same email can produce four or five different dark-mode results.

Key takeaways

• Email clients are the apps people read mail in. For developers, each one is a rendering environment that decides whether your email survives.
• Apple Mail and Gmail are roughly 90% of opens. Outlook is small by share but rules B2B and enterprise inboxes.
• The engine underneath is what matters: WebKit for Apple Mail, Google’s own for Gmail, Word for classic Outlook, Chromium for the new Outlook.
• Classic Outlook’s Word engine sticks around until at least 2029. The hybrid build wins.
• Dark mode is a per-client behaviour, not a setting you control. Design defensively and test the logo and button.
• You cannot eyeball forty clients. Test on real renders, and pull your priority list from your own analytics, not a global chart.

Email clients are not going to suddenly agree with each other. They never have. But the worst engine is finally fading, the good ones keep improving, and the gap between web and inbox is slowly closing. Until it closes for real, the rule holds. Know your clients, design for the floor first, and test before you send. The day this all gets easy is coming. It is just not quite here yet.