The complete guide to email client compatibility

Quick answer: Email client compatibility means one email rendering correctly across clients that run on different engines. Three matter. WebKit and Blink power Apple Mail, Gmail web and the new Outlook, and handle modern CSS. The Word 2007 engine still powers classic Outlook for Windows, so backgrounds need VML and layout needs tables. Gmail strips CSS it distrusts and clips anything past 102 KB.

What actually breaks emails across clients

99.88% of HTML emails contain accessibility issues categorized as “Serious” or “Critical”, according to the Email Markup Consortium’s 2026 report. Out of 376,348 emails analyzed between May 2025 and May 2026, eight passed every automated check. Eight. From three brands. That’s a 0.002% pass rate, and EMC’s own word for the result is a standstill, which is generous.

The previous year’s number was 99.89%. So in twelve months, across an industry that talks constantly about quality and craft, the needle moved by one hundredth of a percentage point. I find that genuinely funny and also a bit depressing, depending on the day.

Which puts you in an odd spot if you’re sending email campaigns. You could design something beautiful, write copy that actually converts, nail your segmentation, and still have the thing arrive in someone’s inbox looking like a website from 2003 got in a fight with a Word document. Because honestly, that’s sort of what’s happening. Email client compatibility is the problem nobody wants to budget for until they look at their analytics one Monday and realize their best campaign in six months lost a chunk of its reach to a rendering engine.

The case of widespread email clients

Apple sits at 62.26% of tracked email opens and Gmail at 27.03%, per Litmus Email Analytics for July 2026. Together that’s nearly 90% of everything, which sounds like it should make your job easier and mostly doesn’t, because “Apple” isn’t one thing. It’s iOS Mail, iPadOS Mail, macOS Mail, plus every open Litmus buckets under Apple’s Mail Privacy Protection, plus a pile of third-party apps running on Apple hardware that report as Apple. Gmail renders differently on web versus the mobile apps, with different levels of CSS support depending on where someone’s reading, and Litmus can’t split those out because Gmail routes everything through its image cache.

So you have two clients covering ninety percent of your audience, and neither of them is a single rendering target. That’s the actual shape of the problem.

This guide covers what breaks emails, why it happens, and how to fix it without coding a hundred workarounds for every edge case.

---

The email client compatibility crisis: understanding the stakes

The true cost of poor email rendering

Email client compatibility issues kill revenue in ways you can measure and ways you can’t. The measurable stuff: emails with rendering problems see drops in click-through rates compared to properly displayed campaigns. Testing platforms have pointed at double-digit percentage drops for broken campaigns for years, though the exact figure varies wildly by vertical and audience, and I’d treat any single number you see quoted with suspicion. (More on that in a moment – a lot of the numbers floating around this topic are garbage, and I cut several of them out of this article.)

Then there’s the stuff you won’t see in your analytics at all. When someone opens your email and it looks broken, they don’t send you a polite note explaining what went wrong. They delete it, or worse, they form an opinion about your technical competence that affects every future interaction. You run a professional service? That broken email suggests otherwise. Selling a SaaS product? Good luck convincing someone your software works if your emails don’t.

The silent version of this is the one that gets me. A subscriber opens your campaign on a phone, the two-column layout hasn’t stacked, the text is six pixels tall, and they’re gone in under two seconds. No analytics event fires. No feedback. You get a slightly worse click rate that month and you attribute it to subject line fatigue or send timing or the algorithm, and you go and rewrite your subject lines, and the actual problem is that a width="600" never got a max-width next to it.

Accessibility violations add another layer of risk. Roughly 0.002% of emails pass automated accessibility checks, which means nearly every campaign potentially runs into regulations like the ADA in the US or the European Accessibility Act in the EU. The EAA – Directive (EU) 2019/882 – has applied since 28 June 2025. It’s enforceable legislation, not a guideline, and each member state enforces it with its own procedures and penalties. Service contracts signed before that date have until 28 June 2027, and products and services already on the market have until 28 June 2030, but anything new is in scope now. If your business serves EU customers, this applies regardless of where you’re based.

The complexity behind the scenes

Email clients operate as isolated ecosystems, each with their own rendering engines, security restrictions, and feature limitations. Unlike web browsers, which mostly converged on standards over the past decade (thank you, quiet death of IE6), email clients are still fragmented in ways that feel almost deliberate.

Security concerns drive most of these limitations. Email clients strip out potentially dangerous code, block JavaScript entirely, and restrict advanced features that work fine in web browsers. They have to – an email is executable code arriving from an unknown sender, and one bad actor could compromise an entire system.

Legacy support requirements make things worse. Many popular email clients maintain backward compatibility with standards from the 2000s, which prevents adoption of modern web technologies. Classic Outlook for Windows still uses the Microsoft Word 2007 rendering engine. Not Word 2023, not even Word 2010 – the 2007 version, which is old enough to vote in most countries. I keep coming back to that fact because it stops being funny somewhere around hour three of debugging a padding issue.

Technical note on Outlook timelines: Office 2021 and Office LTSC 2021 reach end of support on 13 October 2026, with no extended phase and no paid ESU program. That takes one generation of Word-engine Outlook out of circulation. It does not take the engine out of circulation – Office 2024 and Office LTSC 2024 also ship a Word-engine Outlook and are supported to October 2029, and Microsoft’s migration documentation states that existing classic Outlook installations through perpetual and subscription licensing will be supported until at least 2029.

Microsoft’s migration guide describes three stages: opt-in (where new Outlook is off by default and users toggle in), opt-out (new Outlook on by default, users can still switch back), and cutover (no switching back). As of Microsoft’s most recent update to that document, new Outlook for Windows is described as being in the opt-in stage, with at least 12 months of notice to administrators before each subsequent stage. You will see third-party articles quoting confident calendar dates for the enterprise switchover. I’ve stopped repeating them, because they keep moving and Microsoft’s own docs don’t confirm them.

Platform constraints on mobile add another dimension. Mobile email clients face operating system restrictions, screen size constraints, performance considerations, and battery life concerns that just don’t exist on desktop. iOS has its own set of rules about what apps can do, Android has different rules, and both affect how email clients render HTML.

The statistics that should concern you

Data from the Email Markup Consortium’s 2026 Accessibility Report, based on 376,348 emails collected between May 2025 and May 2026:

• 99.88% of HTML emails contain “Serious” or “Critical” accessibility issues
• 8 emails out of 376,348 passed all automated checks, from three brands
• 47.88% of emails contain images with no alt text, which EMC classifies as Critical
• 83.78% of emails use layout tables without role="presentation" or role="none"
• 95.66% are missing a lang attribute on the body, and 97.41% are missing dir

Serious and Critical issues aren’t minor problems. Serious issues create significant barriers for people using assistive technology. Critical issues block access to content entirely.

New in the 2026 edition, and the finding I’d point at if you only read one: EMC audited 10,566 emails sent through Substack, Shopify and Beehiiv. None passed. Not one. Users of those platforms mostly don’t control the markup, which means the defaults are doing the damage. If you’re on a builder that owns your output, your accessibility ceiling is set by someone else’s template decisions.

Look at that alt text number again. 47.88%. Almost half of all commercial email ships images with nothing behind them. That is not a hard problem. That is an attribute you type. And I say that as someone who has shipped an email with alt="" on a hero image because I was rushing a Friday send, so I’m not standing on a hill here, I’m just pointing at the hill.

EMC also expanded its client benchmark this year from 20 tested features to 37, covering semantic HTML, ARIA, focus states, user-preference media queries, and language and direction attributes. That matters for anything you read comparing client accessibility scores – numbers from previous reports aren’t comparable to this year’s.

---

Email client market share: who really controls your inbox

Apple and Gmail together account for close to 90% of tracked email opens, which is why every other client gets tested rather than designed for.

The big picture (based on recent Litmus Email Analytics data)

Litmus updates its Email Client Market Share page monthly from over 1 billion tracked email opens. Here’s the July 2026 leaderboard:

Client	Share of tracked opens
Apple	62.26%
Gmail	27.03%
Outlook (desktop)	5.83%
Yahoo Mail	2.59%
Google Android	1.45%
Outlook.com	0.42%
Thunderbird	0.23%

Apple at 62.26% includes iPhone Mail, iPad Mail, macOS Mail, and opens from devices using Mail Privacy Protection. Since MPP launched, opens from opted-in users don’t pass along client version or platform specifics, so they land in the Apple bucket without further detail. Some third-party apps running on Apple devices also report as Apple. This number moves month to month and part of that movement is measurement, not behaviour.

Gmail at 27.03% covers the web interface, the Android app and the iOS app, all reported through Gmail’s image cache. Litmus can’t distinguish between them. If it was opened in a Gmail client it shows as Gmail; if a gmail.com address gets read in Apple Mail, it shows as Apple Mail. Worth internalising, because “27% Gmail” doesn’t tell you how many of those opens hit the mobile app, which behaves differently from the web.

Outlook desktop at 5.83% is the number that misleads people most. In B2B and enterprise environments it runs far higher. A financial services list or an enterprise SaaS list can see Outlook in the double digits, sometimes well into them, which is why “small market share” and “safe to ignore” are not the same sentence.

Yahoo Mail at 2.59% is declining but still relevant for certain demographics and regions, and its quirks are distinctive enough to cause problems you won’t see elsewhere.

Market share reality check: These numbers shift monthly and vary enormously by audience. A B2B SaaS company might see Outlook running fifteen or twenty percent. A consumer retail brand might see Apple even higher than 62%. Don’t rely solely on global statistics – check your own email analytics to see what your subscribers actually use. Your list is not the global list, and I’ve never once seen a client’s breakdown match the leaderboard.

Mobile-first reality

Mobile and webmail account for the overwhelming majority of email opens, and desktop applications are a small minority.

I’d love to give you a precise three-way split here. I’m not going to, and I want to explain why, because you’ll find one quoted everywhere. There’s a widely circulated breakdown of 41.6% mobile, 40.6% webmail, 16.2% desktop, attributed to Litmus. Litmus doesn’t publish a device-category breakdown – it publishes a client leaderboard. Chase the citation and you land on aggregator sites citing each other, and they don’t even agree: one set says 41.6 / 40.6 / 16.2, another says 41.6 / 39.1 / 19.3, both crediting “Litmus 2025”. Two different numbers cannot both be the same source.

The honest position: precise device splits can’t be measured cleanly any more. MPP preloads content on Apple’s proxy servers and Gmail caches images through its own, so a substantial share of opens carry no reliable device signal. What survives contact with the evidence is that phones dominate reading, webmail is enormous, and desktop applications are a minority that punches above its weight in B2B.

Which is enough to design from, honestly. You don’t need a decimal to know the answer is “build it so it works at 320 pixels wide.”

There’s a second behaviour worth designing around: many people read on mobile and act on desktop. Microsoft research documented this dual-reading pattern years ago and it hasn’t changed. Your email gets viewed twice before anyone does anything, and it needs to work in both contexts, which is a different requirement from “it needs to look good on a phone.”

For email developers, mobile-first design isn’t optional. It’s the baseline assumption. Desktop layouts are the enhancement, not the foundation. I know that’s the opposite of how most of us learned to build websites in the 2010s. That’s where we are now.

Regional and demographic variations

B2B vs B2C differences: desktop Outlook usage remains considerably higher in corporate environments than the global 5.83% suggests. Some enterprise organizations run Outlook across nearly all employee desktops, which means a single B2B campaign can face a client mix that inverts everything on the leaderboard.

Geographic variations: international markets have different dominant clients. Mail.ru is significant in Russia, Naver in South Korea, QQ Mail in China. European business users often skew toward Outlook because of Microsoft’s enterprise footprint. If you’re sending into those markets, the global chart is not your chart.

If you’re working with a specific audience segment, global statistics might not reflect your reality at all. A campaign targeting enterprise IT buyers will see a completely different client distribution than one targeting online shoppers. Checking your own client breakdown is worth repeating until it becomes reflex.

---

The big 5: critical email clients you must master

Five clients cover almost every open worth testing: Apple Mail, Gmail, the Outlook family, Yahoo Mail, and whichever regional client your specific audience actually uses.

1. Apple mail ecosystem (the biggest single bucket)

Apple Mail’s dominance makes it the most critical platform to master, but “Apple Mail” isn’t one thing – it’s several platforms with shared characteristics and individual quirks.

iPhone mail

Uses the WebKit rendering engine, the same engine that powers Safari. This gives it excellent CSS support compared to most mobile email clients, including solid media query support for responsive design. On the Email Markup Consortium’s expanded 37-feature accessibility benchmark, Apple Mail on iOS supports 31 of 37, second only to Apple Mail on macOS at 34. Nothing else is close.

Dark mode considerations: Apple Mail often doesn’t automatically invert email colours when background colours are already defined in your HTML. Your carefully chosen palette can stay exactly as you set it even when the surrounding interface is dark, which produces a bright rectangle sitting in a dark UI. That’s not a bug you can fix by ignoring dark mode – it’s a design decision you’re making by default whether you meant to or not.

Mail Privacy Protection effects: since iOS 15, Apple Mail users can enable MPP, which pre-loads email content and images on Apple’s proxy servers. This breaks traditional open tracking and makes it impossible to know whether a human actually opened your email. It also obscures device information, location data and browser details you’d normally get from the tracking pixel. Litmus currently puts MPP’s reach at roughly 55 to 60% of all email opens. If your open rate went up and your click rate didn’t, you already know what happened.

Apple mail (macOS desktop)

WebKit-based with excellent HTML and CSS support, better than the mobile versions in some respects. Strong background image support, good typography rendering, consistent with web standards. This is the easiest client to code for because it behaves predictably.

Retina display considerations mean you need 2x resolution images for graphics to look sharp. A 600px wide email should use 1200px wide images scaled down with HTML attributes or CSS.

Optimization priorities for Apple Mail

Focus your testing on responsive behaviour – layouts that reflow gracefully from desktop to tablet to mobile. Test dark mode thoroughly, especially image visibility and text contrast. Use high-DPI images for retina displays. Accept that MPP affects your analytics and plan your metrics around clicks and conversions instead.

The good news: Apple Mail is forgiving. Follow web standards, use semantic HTML, and your emails will probably look fine. The bad news: with that market share, any mistake here hits nearly two thirds of your audience.

2. Gmail (second largest share, still huge)

Gmail is the second-most important platform, and it presents unique challenges despite its popularity. Different Gmail interfaces behave differently – the web version strips certain CSS, mobile apps render differently, and what works in one context might break in another.

Gmail web interface

Gmail’s security preprocessing removes CSS properties and selectors it doesn’t trust. Embedded styles in <style> tags have limited and inconsistent support. External stylesheets are blocked entirely. There is no published list of exactly what gets stripped, which is part of what makes this annoying – support is property by property, it differs between the web interface and the apps, and it changes without announcement.

The web interface uses Blink, which should mean good standards support. In practice, Gmail’s sanitiser limits what actually renders. Responsive design works but with limitations – Can I Email lists @media as only partially supported in Gmail.

On EMC’s accessibility benchmark, Gmail on desktop webmail supports 17 of 37 features, and the mobile surfaces support 15. That’s a long way behind Apple Mail and, notably, roughly level with Yahoo Mail. More on that surprise below.

Gmail mobile apps (Android and iOS)

Different rendering behaviour than the web version, sometimes more restrictive CSS support, common image loading delays, and different handling of touch interactions. The Android version has partial dark mode support with automatic adjustments you can’t fully control, while iOS Gmail follows system dark mode settings.

Gmail optimization strategies

Inline all critical CSS. Don’t rely on embedded styles or external stylesheets. Put your CSS directly in the style attribute of each element.

<!-- Good for Gmail -->
<td style="padding: 20px; background-color: #f0f0f0; font-family: Arial, sans-serif; color: #333333;">
  Content
</td>

<!-- Might get stripped in Gmail -->
<style>
  .content { padding: 20px; background-color: #f0f0f0; }
</style>
<td class="content">Content</td>

Test image loading and alt text thoroughly. Gmail blocks images by default until users enable them, so your alt text needs to make sense without images. Use descriptive alt text that explains what the image shows, not decorative filler.

Account for the Gmail Promotions tab. Marketing emails usually land there, and if yours does, it needs to stand out among competitors. (A small rant: Gmail’s classification became noticeably more aggressive in late 2024, and a lot of senders who used to see balanced splits between Primary and Promotions experienced sudden shifts. If that happened to you, you weren’t imagining it.)

3. Microsoft Outlook family (small share, huge importance for B2B)

Despite lower overall market share, Outlook remains critical for B2B communications and presents the most email client compatibility challenges of any major client.

Outlook desktop with Word rendering

Uses Microsoft Word’s rendering engine – specifically the Word 2007 version. Not an updated engine, the exact same rendering technology from 2007. Microsoft made this choice for Outlook 2007 and has maintained it through every subsequent perpetual and classic release, including Outlook 2021 and Outlook 2024.

On EMC’s 37-feature accessibility benchmark, Outlook on Windows supports 11. That’s the lowest score of any major client, and it’s roughly a third of what Apple Mail manages.

Severely limited CSS support: no flexbox, no grid, no CSS transforms, no animations, no position properties, unreliable margin handling, and no background-image support without a VML workaround.

Tables required for all layout. Forget div-based layouts. Outlook needs nested tables to structure content. This isn’t 1998 nostalgia, it’s still a technical necessity.

VML (Vector Markup Language) required for advanced features. Want background images? VML. Rounded buttons? VML. Gradients? VML. It’s Microsoft’s proprietary markup that only Outlook understands, which is why you wrap it in conditional comments so other clients ignore it.

120 DPI scaling issues. Windows users can run at 120 DPI, and Outlook respects it. Images and text become larger, which breaks layouts that depend on precise sizing.

Outlook 365 (web-based and new desktop)

The new Outlook for Windows reached General Availability by 1 August 2024 and is a completely different animal. Web-based rendering engine instead of Word, much better CSS support, background images work normally, responsive design functions properly. Still needs testing, but far more forgiving. One useful detail: it doesn’t process MSO conditional comments, so your VML workarounds for classic Outlook sit inside it harmlessly invisible.

Outlook.com (webmail) uses a Blink-based engine with good CSS support, closer to modern web standards, and scores 20 of 37 on EMC’s accessibility benchmark.

Where the transition actually stands:

• 1 August 2024 – new Outlook for Windows reaches General Availability
• 13 October 2026 – Office 2021 and Office LTSC 2021 reach end of support, along with their Word-engine Outlook. No extended phase, no paid ESU
• October 2029 – Office 2024 end of support, and Office 2024 also ships a Word-engine Outlook
• at least 2029 – existing classic Outlook installations through perpetual and subscription licensing continue to be supported, per Microsoft’s migration documentation

Microsoft’s migration stages run opt-in, then opt-out, then cutover, with at least 12 months of administrator notice before each of the last two. Their documentation currently describes new Outlook as being in the opt-in stage.

The practical read for anyone building emails: the Word engine is shrinking, not vanishing. Enterprise upgrade cycles are slow and IT departments that skipped a generation will skip another. Plan to support Word rendering into 2028 and probably beyond, and stop treating each announced deadline as the finish line. I want it gone more than most people do and I’m still building ghost tables.

Outlook compatibility essentials

Use table-based layouts for classic Outlook. Implement VML for background images, rounded buttons, gradients, and any visual effect Word doesn’t support. Test across classic Outlook and the new Outlook for Windows separately – they render differently enough that passing in one tells you almost nothing about the other. Use conditional comments to target Outlook-specific fixes without affecting other clients.

<!--[if mso]>
  <v:rect xmlns:v="urn:schemas-microsoft-com:vml" fill="true" stroke="false" style="width:600px;height:300px;">
    <v:fill type="tile" src="background.jpg" color="#cccccc" />
    <v:textbox inset="0,0,0,0">
<![endif]-->
<div style="background-image: url('background.jpg'); background-color: #cccccc;">
  Content that appears over background image
</div>
<!--[if mso]>
    </v:textbox>
  </v:rect>
<![endif]-->

4. Yahoo mail (smaller share, unique quirks)

Yahoo Mail’s smaller market share doesn’t make it unimportant, and it has one genuinely surprising property.

Rendering characteristics

Here’s the thing I had to update in this article and enjoyed updating: Yahoo Mail now scores better than classic Outlook for Windows on the Email Markup Consortium’s accessibility benchmark. Yahoo Mail on desktop webmail and Android support 16 of 37 features, Yahoo on iOS supports 14, and Outlook on Windows supports 11. The old received wisdom that Yahoo and legacy Outlook are equally bad is out of date. Yahoo is ahead.

That said, CSS support remains inconsistent across Yahoo’s different interfaces, and image blocking is aggressive by default – more aggressive than Gmail or Apple Mail, which makes alt text critical rather than nice-to-have.

Media query support is partial and unpredictable. Don’t build complex responsive behaviour that depends on it. Use fluid layouts that adapt without media queries and treat the queries as enhancement.

Yahoo mail optimization

Inline CSS extensively, more than you’d bother with for Gmail. Write robust, descriptive alt text for every image, because a meaningful share of Yahoo users will see your email without images. Test across Yahoo’s web, iOS and Android interfaces separately, because they render differently. Keep your HTML structure simple – complex nesting causes problems here that it doesn’t cause elsewhere.

5. Regional and specialized clients

Don’t overlook smaller clients that might matter for your specific audience.

Samsung Email: popular among Android users, especially where Samsung devices dominate. Worth knowing that on EMC’s accessibility benchmark Samsung Email scores 31 of 37, tied with Apple Mail on iOS. It’s a far better rendering target than its market share suggests.

Thunderbird: common in enterprise environments and among technical users. Gecko-based on macOS with reasonable support; the Windows build is largely untested on Can I Email, which is its own kind of warning.

International clients: region-specific platforms have unique requirements. Mail.ru, Naver, QQ Mail. If you’re sending to those markets, research the dominant local clients. And yes, testing against them is harder. That’s just the nature of the problem.

---

Rendering engines: why emails look different everywhere

Email clients don’t share a rendering engine, and that single fact explains most of what breaks.

The technical foundation of email client compatibility issues

Email clients use different rendering engines to interpret HTML and CSS. This creates the fundamental source of email client compatibility challenges – the same code produces different results depending on which engine processes it.

WebKit and Blink-based clients (Apple Mail, Gmail web, new Outlook, Outlook.com)

Chromium’s fork of WebKit – WebKit and Blink provide excellent CSS support, modern web standards compliance, good media query support, consistent typography rendering, and predictable behaviour that matches what you’d see in Safari or Chrome.

WebKit and Blink clients are the easy ones to code for. Follow web standards, use semantic HTML, write clean CSS, and most things work. The exception is Gmail, which runs Blink but sanitises your HTML before rendering it, so a good engine doesn’t guarantee good output.

Microsoft Word engine (classic Outlook desktop)

Severely limited CSS support, because Word was designed for document layout, not web rendering. No background-image support without VML. Table-based layout is mandatory. VML becomes necessary for any visual effect beyond basic styling.

The Word engine interprets HTML through the lens of document formatting, which means it makes assumptions your browser wouldn’t. Line heights change unexpectedly. Spacing behaves differently. What looks like 20 pixels of padding in your design might render as 17 or 23 in Outlook depending on surrounding elements. The prevailing theory is that Word upconverts between pixels and points and the rounding is imperfect. I’ve spent actual hours of my life chasing a one-pixel horizontal white line in Outlook that turned out to be exactly this, and the fix was mso-line-height-rule: exactly, and I was not gracious about it.

Custom rendering engines

Various proprietary systems used by smaller clients. Unpredictable support that requires individual testing. Unique quirks specific to each client. No documentation in many cases – you test and discover what works.

How rendering differences manifest

Typography variations: font family fallbacks render differently across clients. Classic Outlook and Yahoo Mail tend to fall back to system fonts even when you specify web fonts. Line height calculations vary. Text alignment goes inconsistent when mixing directions or using unusual combinations.

Layout disruptions: box model interpretations differ – what counts as “width” in one client might exclude padding in another. Padding is close to universal; margin is partial in Gmail, Outlook and Yahoo Mail and only fully supported in Apple Mail. Float and positioning are unsupported in most clients. Responsive breakpoints behave inconsistently even where media queries are supported.

Visual element issues: background image support ranges from full (Apple Mail, Gmail) to partial (Outlook, Yahoo Mail). Border radius works in Apple Mail and Gmail and degrades to square corners elsewhere. Colour interpretation can differ slightly, especially converting between hex and RGB. Image scaling algorithms differ, so the same file might look sharp in one client and soft in another.

---

Mobile vs desktop: the great compatibility divide

The mobile imperative

Mobile and webmail account for the overwhelming majority of email opens, and desktop applications are a small minority. The exact split isn’t cleanly measurable – MPP preloading and Gmail’s image cache strip the device signal from a large share of opens – but the direction hasn’t been in question for a decade. If your email doesn’t work on a phone, it doesn’t work.

Mobile-specific challenges

Touch interface requirements: buttons need to be at least 44 by 44 pixels for reliable finger tapping. Smaller targets cause missed clicks. Links need adequate spacing – tapping the wrong link because two sit three pixels apart is a bad experience and an entirely avoidable one.

Screen size variations: from small phones at 320 to 375px wide up to tablets at 768px and beyond. Your layout needs to adapt across all of it, usually without knowing which device will display it.

Performance constraints: limited processing power affects complex layouts. Heavy emails may not load fully on slower connections. Complex layouts that take a long time to render drain battery.

Image optimization: large images that look fine on desktop can stall mobile rendering. Serve appropriately sized files rather than shipping 1200px assets to a 375px screen, and compress properly – there’s more on getting image weight down without wrecking quality in a separate piece.

Desktop compatibility considerations

Legacy client support: older Outlook versions remain common in enterprise environments. Some organizations still run Outlook 2016 or 2019 because of “if it works, don’t fix it” IT policies. These users need your emails to function even though their software is years behind current standards.

Screen real estate: larger screens allow more complex layouts. Multi-column designs, larger images, more detailed graphics. Viewing distance is different too – people sit further from monitors than they hold phones, which affects optimal font sizes.

Mouse interaction: hover states work on desktop. Precise clicking allows smaller targets than touch interfaces need. Right-click context menus are available.

Processing power: desktop machines can handle more complex CSS and larger images without performance issues. This doesn’t mean you should use them (most clients block the interesting stuff anyway), but the capacity exists.

Responsive design strategies

Mobile-first approach

Build the mobile experience first, then enhance for larger screens. Start with a single-column layout that works at 320px. Use fluid layouts with percentage widths for the base structure. Add media queries to reorganize for larger screens.

<!-- Base mobile styles -->
<table width="100%" cellpadding="0" cellspacing="0" role="presentation">
  <tr>
    <td style="padding: 20px 15px; font-size: 16px; line-height: 24px;">
      Mobile-optimized content with comfortable spacing
    </td>
  </tr>
</table>

<!-- Enhanced desktop styles -->
<style>
  @media screen and (min-width: 600px) {
    .desktop-padding { padding: 40px 30px !important; }
    .desktop-text { font-size: 18px !important; line-height: 28px !important; }
  }
</style>

A reality check on media queries, because this is where a lot of otherwise-good emails come apart. Can I Email lists @media as supported in Apple Mail and only partially supported in Gmail, Outlook and Yahoo Mail. Classic Outlook for Windows doesn’t need media queries at all, because it isn’t responsive – it renders at whatever width you set and that’s the end of the conversation.

Which is why the hybrid approach matters. Your base layout has to work at any width using percentage widths and max-width, and then media queries layer on top for the clients that support them. If your layout only works when a media query fires, you’ve built something that breaks for a meaningful share of your list. The fluid and hybrid approach is the version of this that survives contact with real inboxes.

Progressive enhancement

Start with a functional mobile experience that works everywhere. Add desktop enhancements through media queries for clients that support them. Make sure core functionality works without CSS – if an aggressive client strips your styles, the email should still be usable. Test graceful degradation. What happens when the ideal rendering fails?

The 600px breakpoint is standard for email. Below 600, assume mobile. At 600 and above, assume desktop or large tablet. You can add more breakpoints and I sometimes do, but every one you add multiplies your testing matrix, so keep it simple until something forces your hand.

---

Dark mode dilemma: the new email client compatibility challenge

The dark mode reality

Dark mode is used by more than a quarter of subscribers, and every major client handles it differently – some invert your colours, some leave them alone, and classic Outlook ignores the setting entirely.

I’m deliberately not giving you a decimal here. You’ll see 34% and 35% quoted constantly; both trace back to Litmus measurements from 2022, which is four years of device adoption ago, and Litmus’s current published position is that dark mode is used by more than 25% of the total user base. Among Litmus’s own subscribers – an unusually email-savvy audience – the figure runs higher, which tells you the number depends heavily on who’s on your list.

The number doesn’t change what you should do anyway. A quarter or more of your audience is reading in dark mode, and you can’t tell which quarter.

Dark mode handling by client

Apple Mail: inverts colours in some cases, sometimes inverts images unintentionally (including logos), supports prefers-color-scheme, and often leaves your colours alone entirely when backgrounds are explicitly defined in the HTML. That last behaviour is the one that surprises people – your email can sit as a bright white block inside a dark interface, which looks less like a design choice and more like a mistake.

Gmail: limited automatic adjustments. Gmail mostly leaves your colours alone. Manual optimization is usually required. Behaviour is inconsistent across platforms – Android Gmail handles it differently from iOS.

Outlook: varies significantly by version. Classic Outlook for Windows ignores dark mode preferences. Web versions handle it better with some automatic adjustments. The new Outlook for Windows improves dark mode support considerably.

Dark mode optimization strategies

CSS-based approach using prefers-color-scheme

<style>
  @media (prefers-color-scheme: dark) {
    .dark-bg { background-color: #1f1f1f !important; }
    .dark-text { color: #ffffff !important; }
    .dark-border { border-color: #444444 !important; }
    .dark-logo { display: block !important; max-height: inherit !important; }
    .light-logo { display: none !important; }
  }
  .dark-logo { display: none; }
</style>

<table class="dark-bg" style="background-color: #ffffff;">
  <tr>
    <td class="dark-text" style="color: #333333; padding: 20px;">
      Content that adapts to dark mode preferences
    </td>
  </tr>
</table>

Image considerations

Provide dark mode versions of logos and graphics. Your black logo on a transparent background becomes invisible in dark mode. Swap to a white or light version using CSS to hide and show based on colour scheme.

Avoid automatic image inversion where you can. Gmail and some other clients will invert images, which makes photos look strange. Test image visibility in both modes – that subtle grey text inside your image will disappear.

Use transparent PNGs with caution. They inherit background colours when inverted, which sometimes works in your favour (icons that adapt naturally) and sometimes doesn’t (elements that look broken). A one-pixel stroke or a small padded background around a logo solves most of this and takes two minutes.

Outlook-specific dark mode handling

Outlook for Android exposes a special attribute for dark mode detection:

<style>
  [data-ogsc] .light-mode-image {
    display: none !important;
  }
  [data-ogsc] .dark-mode-image {
    display: block !important;
    max-height: inherit !important;
    max-width: inherit !important;
  }
</style>

This targets Outlook for Android without affecting other clients. The data-ogsc attribute appears in the DOM when Outlook renders in dark mode. Outlook.com uses a similar [data-ogsb] attribute.

The full pattern, including the parts I keep having to re-derive, is in the piece on coding emails that survive dark mode.

---

CSS support matrix: what works where

CSS support in email splits three ways: properties that work everywhere, properties that work in modern clients and fail silently elsewhere, and properties that get stripped on sight.

Support is per property and per client, and the terms below – inlining, conditional comments, VML – all have entries in the email development glossary if any of them are unfamiliar.

One important caveat before the lists. Check anything you’re about to depend on against caniemail.com, per property, rather than trusting a summary table in a blog post. Including this one. Support data moves and an article doesn’t. I found three errors in my own version of this section when I last went through it property by property, which is a slightly humbling thing to admit in a guide.

Universal CSS properties (safe everywhere)

These work reliably across all major clients, including classic Outlook with Word rendering:

Typography:

• font-family (with appropriate fallbacks to system fonts)
• font-size (pixels recommended; ems and percentages behave unpredictably)
• font-weight (normal and bold work universally, numbered weights are inconsistent)
• color (hex values are most reliable)
• text-align
• text-decoration

Layout basics:

• width and height
• padding – supported in Apple Mail, Gmail and Yahoo Mail, partial in Outlook, and still the most reliable spacing tool you have
• background-color – supported in all four major clients, no caveats
• border (simple styles – solid, thickness, colour)

Table properties:

• cellpadding and cellspacing attributes
• width and height attributes on table elements
• align and valign
• the bgcolor attribute, though CSS background-color is preferred

Use these as your foundation. They work everywhere, including in clients you’ve never heard of.

Limited support properties (use with caution)

These work in modern clients and degrade or fail elsewhere. Several entries in this list moved since the last version of this article, because the support data changed and the old summaries were wrong.

• border-radius – supported in Apple Mail and Gmail, partial in Outlook and Yahoo Mail. Not WebKit-only, which is what a lot of guides (including a previous version of this one) still claim
• background-image – supported in Apple Mail and Gmail, partial in Outlook and Yahoo Mail. Classic Outlook needs the VML workaround
• max-width – supported in Apple Mail, Gmail and Yahoo Mail, partial in Outlook. This is better support than its reputation suggests and it’s the backbone of fluid layout, so use it
• box-shadow – supported in Apple Mail, partial in Gmail and Outlook, not supported in Yahoo Mail
• linear-gradient – supported in Apple Mail, partial in Gmail, not supported in Outlook or Yahoo Mail. In classic Outlook a gradient renders as nothing at all, which for a B2B list is a large slice of people seeing an unstyled block
• margin – supported in Apple Mail, partial in Gmail, Outlook and Yahoo Mail. Partial is not the same as never, but Outlook’s handling is unreliable enough and Gmail rejects negative values, so padding stays the default for spacing
• @media queries – supported in Apple Mail, partial in Gmail, Outlook and Yahoo Mail
• flexible units (em, rem, vw, vh) – limited and unpredictable

Use these with fallbacks. Your email should function without them; they should improve the experience for people whose clients can take them.

Never use in email

These are stripped, ignored, or unreliable enough that reaching for them is a mistake:

Unsupported CSS:

• position (absolute, relative, fixed, sticky)
• flexbox
• grid
• transform and animations
• float for layout

JavaScript and advanced features:

• JavaScript is blocked in all email clients without exception
• <script> tags are stripped before rendering
• external stylesheets are blocked
• form submissions are extremely limited
• <iframe> elements are blocked
• <video> and <audio> have no support – use animated GIFs or link out

The blocked properties above exist for security reasons. Email clients can’t risk arbitrary code execution from unknown senders. Work within the limits rather than fighting them, which took me about two years to accept and has saved me time ever since.

---

The 7 most common email rendering issues

Seven failures account for most of the broken emails that land in my inbox with a “can you look at this” attached, and each one has a known cause and a known workaround.

1. Background images in classic Outlook

The problem: classic Outlook doesn’t support the CSS background-image property. Your hero section with text over an image appears as empty white space with floating text.

What happens: the background image doesn’t load. Any text positioned over it appears against white or a default colour. Layouts that depend on the image for visual structure fall apart. Recipients see something confusing that looks nothing like what you designed.

The solution: implement VML for Outlook. VML is Microsoft’s proprietary markup that only Outlook understands, wrapped in conditional comments so other clients ignore it.

<!--[if mso]>
<v:rect xmlns:v="urn:schemas-microsoft-com:vml" fill="true" stroke="false" style="width:600px;height:300px;">
  <v:fill type="tile" src="https://yourdomain.com/background.jpg" color="#cccccc" />
  <v:textbox inset="0,0,0,0">
<![endif]-->
<div style="background-image: url('https://yourdomain.com/background.jpg'); background-color: #cccccc; width: 600px; height: 300px;">
  <table width="100%" height="300" cellpadding="0" cellspacing="0" role="presentation">
    <tr>
      <td align="center" valign="middle" style="color: #ffffff; font-size: 32px; font-weight: bold;">
        Your content here
      </td>
    </tr>
  </table>
</div>
<!--[if mso]>
  </v:textbox>
</v:rect>
<![endif]-->

The VML creates a rectangle with a tiled fill for Outlook. Other clients see the regular CSS background. The color="#cccccc" provides a fallback in case the image doesn’t load, which matters more than people think – Yahoo will block it and a proportion of everyone else will be on a bad connection. The full VML and fallback pattern for background images, including the HTML background attribute trick that reaches further than the CSS property, goes deeper than this.

2. Mobile layout collapse

The problem: your carefully designed two-column layout stacks in the wrong order on mobile, text becomes unreadable, buttons become untappable, and the whole email needs horizontal scrolling.

What happens: columns stack right-before-left instead of left-before-right. Fixed widths push content off screen. Font sizes tuned for desktop go microscopic. Tap targets fall below 44 pixels. The reader gives up.

The solution: proper responsive design with mobile-first thinking, and a base layout that doesn’t depend on media queries firing.

<style>
  /* Mobile adjustments */
  @media screen and (max-width: 600px) {
    .mobile-stack {
      display: block !important;
      width: 100% !important;
    }
    .mobile-text {
      font-size: 16px !important;
      line-height: 24px !important;
    }
    .mobile-padding {
      padding: 15px !important;
    }
  }
</style>

<table width="600" cellpadding="0" cellspacing="0" role="presentation">
  <tr>
    <!-- Left column -->
    <td class="mobile-stack" width="300" style="display: inline-block; vertical-align: top; padding: 20px;">
      <img src="product.jpg" width="260" style="width: 100%; max-width: 260px; height: auto;" alt="Product photo">
    </td>
    <!-- Right column -->
    <td class="mobile-stack" width="300" style="display: inline-block; vertical-align: top; padding: 20px;">
      <h2 class="mobile-text" style="font-size: 24px; margin: 0 0 10px 0;">Product Name</h2>
      <p class="mobile-text" style="font-size: 16px; line-height: 24px;">Description that remains readable on all devices.</p>
    </td>
  </tr>
</table>

The display: inline-block approach creates a hybrid layout. Columns sit side by side on desktop and stack on mobile when the media query applies display: block and width: 100%. The !important overrides the inline styles when the query activates. Most of this class of problem disappears entirely if you build fluid and hybrid from the start rather than retrofitting responsiveness onto a fixed-width desktop design.

3. Gmail strips embedded CSS

The problem: Gmail’s sanitiser removes CSS properties and selectors it doesn’t trust. Spacing disappears, colours change, layouts shift.

What happens: embedded styles in <style> tags might not apply. Complex selectors get removed. External stylesheets are blocked entirely. Your email looks different in Gmail than in your testing tool because Gmail processes the HTML before rendering it.

The solution: inline all critical styles directly on elements. Don’t rely on embedded stylesheets or external CSS.

<!-- Safe for Gmail - inline styles -->
<td style="padding: 20px; background-color: #f0f0f0; font-family: Arial, sans-serif; color: #333333; font-size: 16px; line-height: 24px;">
  Content with all styles directly on the element
</td>

<!-- Risky in Gmail - embedded styles might get stripped -->
<style>
  .content { padding: 20px; background-color: #f0f0f0; }
  .content p { margin-bottom: 15px; }
</style>
<td class="content">
  <p>Content relying on stylesheet</p>
</td>

<!-- Never works in Gmail - external stylesheet -->
<link rel="stylesheet" href="styles.css">

Use preprocessors or inliners rather than doing this by hand. MJML, Foundation for Emails, Premailer, Juice – pick one. Writing everything inline manually is tedious and error-prone and you will miss a td.

Worth keeping in mind alongside this: Gmail clips emails whose HTML passes roughly 102 KB, which can hide entire sections including your CTA. Images don’t count toward it – only the code. Your ESP adds tracking links after you hand off the file, so build under about 100 KB to leave headroom. What else Gmail rewrites before it renders covers the rest.

4. Dark mode inverts images and logos

The problem: a quarter or more of opens happen in dark mode, and many emails look terrible when clients invert colours automatically. Logos become unreadable, brand colours distort, photos look wrong.

What happens: your black logo on a transparent background becomes invisible, or shows as white when that wasn’t the intent. Product photos get inverted and look unnatural. Text over images loses contrast.

The solution: provide dark mode versions of images and swap them based on colour scheme.

<style>
  /* Hide dark logo by default, show in dark mode */
  @media (prefers-color-scheme: dark) {
    .dark-logo {
      display: block !important;
      max-height: inherit !important;
    }
    .light-logo {
      display: none !important;
    }
  }
  .dark-logo { display: none; }
</style>

<!-- Light mode logo (default) -->
<img src="logo-dark.png" class="light-logo" alt="Company Logo" width="200" height="80" style="display: block;">

<!-- Dark mode logo (hidden by default, shown in dark mode) -->
<img src="logo-light.png" class="dark-logo" alt="Company Logo" width="200" height="80" style="display: none; max-height: 0;">

Create separate logo versions for each mode. For images you can’t duplicate, use transparent PNGs carefully or add a background colour that works in both. Test properly – what looks fine in light mode can vanish in dark. There’s a fuller treatment in coding emails that survive dark mode.

5. Yahoo Mail blocks images by default

The problem: Yahoo Mail blocks images more aggressively than other clients. Image-heavy emails appear as blank rectangles with placeholder icons. Information embedded in images becomes inaccessible.

What happens: Yahoo displays placeholder boxes where images should be. Text inside images is invisible. Buttons built as images don’t appear. Your entire message can be lost if you leaned on images to carry it.

The solution: design with image blocking in mind from the start. Never put critical information exclusively in images. Use real text. Write alt text that communicates value on its own.

<!-- Button with fallback -->
<table cellpadding="0" cellspacing="0" role="presentation">
  <tr>
    <td style="background-color: #0066cc; padding: 15px 30px; border-radius: 4px; text-align: center;">
      <a href="https://yoursite.com/shop" style="color: #ffffff; text-decoration: none; font-weight: bold; font-size: 16px; display: block;">
        Shop Now - Save 25%
      </a>
    </td>
  </tr>
</table>

<!-- Image with descriptive alt text -->
<img src="product-feature.jpg" alt="Wireless headphones with noise cancellation, 30-hour battery life, available in black and silver" width="600" height="400" style="display: block; width: 100%; max-width: 600px; height: auto; border: 0;">

The button is real HTML and CSS, not an image, so it displays with images off. The alt text describes the product specifically enough to be useful on its own.

Given that 47.88% of emails ship images with no alt text at all, this is also the single cheapest accessibility win available to anyone reading this. Writing alt text that carries the message goes into what “descriptive” actually means, because “product photo” is technically alt text and practically useless.

Test your emails with images disabled. If your email makes no sense without images, redesign it.

6. Animated GIFs freeze in classic Outlook

The problem: classic Outlook doesn’t play animated GIFs. It shows the first frame and stops. If your first frame is blank or mid-transition, that’s what Outlook users see permanently.

What happens: the animation doesn’t play. Whatever frame one is becomes the whole message. Your product demo becomes a static, possibly meaningless image.

The solution: design a meaningful first frame that works as a standalone image. Or provide a static fallback specifically for Outlook.

<!-- Animated GIF for modern clients -->
<!--[if !mso]><!-->
  <img src="animated-demo.gif" alt="Product demonstration showing three key features" width="600" height="400" style="display: block; width: 100%; max-width: 600px; height: auto;">
<!--<![endif]-->

<!-- Static fallback for Outlook -->
<!--[if mso]>
  <img src="static-fallback.jpg" alt="Product demonstration - view the animated version online" width="600" height="400" style="display: block;">
<![endif]-->

Design the first frame as if it might be the only frame anyone sees. Clear subject, complete composition, visual interest. The animation enhances the message rather than carrying it.

File size matters too. Animated GIFs get enormous fast, which hurts on mobile connections and eats into that 102 KB budget indirectly through the rest of your template. Optimising GIFs for weight and first frame covers frame reduction and dimension trimming.

7. Typography rendering inconsistencies

The problem: web fonts and typography render completely differently across clients. Classic Outlook doesn’t support web fonts and falls back to system fonts. Gmail loads them inconsistently. Line heights calculate differently.

What happens: headlines use a completely different typeface than designed. Line heights that look right in Apple Mail appear compressed in Gmail. Layouts break because font metrics differ between your choice and the fallback. Letter spacing behaves unpredictably.

The solution: use email-safe fonts with comprehensive fallback stacks. Accept that typography won’t be pixel-perfect everywhere. Design for degradation.

<!-- Good: email-safe fonts with fallbacks -->
<h1 style="font-family: 'Helvetica Neue', Helvetica, Arial, sans-serif; font-size: 28px; line-height: 34px; color: #333333; margin: 0 0 20px 0; font-weight: bold;">
  Reliable Typography
</h1>

<p style="font-family: Georgia, 'Times New Roman', Times, serif; font-size: 16px; line-height: 24px; color: #666666; margin: 0 0 15px 0;">
  Body text that renders consistently across email clients using serif fallbacks.
</p>

<!-- Risky: web fonts that will fail in classic Outlook -->
<style>
  @import url('https://fonts.googleapis.com/css2?family=Montserrat:wght@400;700&display=swap');
  /* This will be stripped by many email clients */
</style>
<h1 style="font-family: Montserrat, sans-serif;">
  This looks great in Apple Mail, falls back to default sans-serif in Outlook
</h1>

System fonts that exist nearly everywhere: Arial, Helvetica, Georgia, Times New Roman, Courier, Verdana, Tahoma. Predictable, available, boring, fine.

If you want web fonts, implement them knowing a large share of recipients won’t see them, and pick fallbacks with similar metrics so the layout doesn’t shift when they don’t load. Web fonts versus fallback stacks has the metric-matching part, which is the bit everyone skips and then wonders why the desktop version looks cramped.

---

Client-specific optimization strategies

Each major client rewards a different set of choices, and coding for the lowest common denominator everywhere leaves real capability on the table in Apple Mail.

The trade-offs below are the ones I actually made on a cross-client build for Verto, where the same template had to hold up in classic Outlook and still look right in Apple Mail dark mode. Reading someone’s finished decisions is more useful than reading their principles, usually.

Apple mail optimization

Apple Mail is forgiving because of its CSS support, and you can use advanced features to build a better experience for what is now nearly two thirds of your audience.

Take advantage of superior CSS support

Use border-radius for rounded corners. Implement box-shadow for depth and hierarchy. Take advantage of good typography rendering. Use background images without VML hacks.

<style>
  .card {
    border-radius: 8px;
    box-shadow: 0 2px 8px rgba(0,0,0,0.1);
    overflow: hidden;
  }
</style>

<table class="card" style="width: 100%; max-width: 600px; border-radius: 8px; overflow: hidden; background-color: #ffffff;">
  <tr>
    <td style="padding: 30px;">
      Enhanced styling that works beautifully in Apple Mail
    </td>
  </tr>
</table>

Dark mode excellence for Apple mail

Use colour scheme meta tags to signal dark mode support:

<meta name="color-scheme" content="light dark">
<meta name="supported-color-schemes" content="light dark">

<style>
  :root {
    color-scheme: light dark;
    supported-color-schemes: light dark;
  }
  
  @media (prefers-color-scheme: dark) {
    .adaptive-bg { background-color: #1f1f1f !important; }
    .adaptive-text { color: #ffffff !important; }
    .adaptive-border { border-color: #444444 !important; }
  }
</style>

These tags tell Apple Mail your email was designed with dark mode in mind, which helps it apply more sensible automatic adjustments instead of guessing.

Retina display optimization

Provide 2x resolution images for high-DPI displays. Test on actual retina hardware rather than trusting a simulator.

<!-- Standard approach: 2x image scaled down -->
<img src="product-2x.jpg" width="300" height="200" alt="Product photo" style="width: 300px; height: 200px; display: block;">

The file is 600 by 400 pixels, displayed at 300 by 200. Sharp on retina, downsampled gracefully elsewhere.

Gmail optimization

Gmail requires a more conservative approach because of its sanitiser and inconsistent CSS handling.

Security-first coding approach

Inline all critical CSS directly on elements. Avoid complex selectors. Test image loading behaviour – Gmail caches aggressively. Don’t rely on embedded stylesheets.

<!-- Gmail-safe button -->
<table cellpadding="0" cellspacing="0" role="presentation">
  <tr>
    <td style="background-color: #0066cc; padding: 12px 24px; border-radius: 4px;">
      <a href="https://yoursite.com" style="color: #ffffff; text-decoration: none; font-weight: bold; font-size: 16px; font-family: Arial, sans-serif; display: inline-block;">
        Click Here
      </a>
    </td>
  </tr>
</table>

All styles inline. No class selectors, no embedded styles, no external dependencies. This renders consistently across Gmail web and the mobile apps.

Mobile app considerations

The Gmail apps behave differently from the web interface. Touch targets need to be at least 44 by 44 pixels. Test on real devices where you can – emulators don’t always match. Assume slower connections than your office wifi.

The Android Gmail app has partial dark mode support with automatic adjustments you can’t override. Test in it specifically.

Outlook desktop mastery

Classic Outlook with Word rendering requires techniques you wouldn’t use anywhere else.

VML implementation for visual effects

VML is Microsoft’s proprietary markup language. Classic Outlook supports it; the new Outlook for Windows doesn’t need it because it uses web-based rendering, and conveniently ignores conditional comments entirely, so your VML sits there invisible.

VML rounded button example:

<!--[if mso]>
<v:roundrect xmlns:v="urn:schemas-microsoft-com:vml" xmlns:w="urn:schemas-microsoft-com:office:word" href="https://yoursite.com" style="height:40px;v-text-anchor:middle;width:200px;" arcsize="10%" stroke="f" fillcolor="#0066cc">
  <w:anchorlock/>
  <center style="color:#ffffff; font-family:Arial; font-size:16px; font-weight:bold;">
    Button Text
  </center>
</v:roundrect>
<![endif]-->

<!--[if !mso]><!-->
<a href="https://yoursite.com" style="background-color: #0066cc; border: none; color: #ffffff; padding: 12px 24px; text-decoration: none; display: inline-block; border-radius: 4px; font-family: Arial, sans-serif; font-size: 16px; font-weight: bold;">
  Button Text
</a>
<!--<![endif]-->

Table-based layouts

Classic Outlook requires tables. Nested tables create complex structures. Set explicit widths and heights to prevent collapse. Avoid CSS positioning entirely.

<!-- Outlook-friendly two-column layout -->
<table width="600" cellpadding="0" cellspacing="0" role="presentation">
  <tr>
    <td width="300" valign="top" style="padding: 20px;">
      Left column content
    </td>
    <td width="300" valign="top" style="padding: 20px;">
      Right column content
    </td>
  </tr>
</table>

Use valign="top". By default Outlook centres vertically, which looks strange the moment column heights differ. Set exact pixel widths rather than percentages for predictable rendering here.

Test across Outlook versions

Outlook 2016 through 2024 and classic Outlook 365 all use Word rendering with subtle differences between them. The new Outlook for Windows uses web-based rendering and behaves completely differently. Outlook.com renders differently again.

Testing in one Outlook version tells you almost nothing about the others. Outlook also ships updates without warning – a 2024 update introduced image scaling issues, misaligned footers and unwanted underlines that broke templates previously optimised for it. Regular retesting is the only way to catch that kind of silent regression, and if you maintain a template library for a client, put a recurring calendar reminder on it. I learned that the expensive way.

---

Testing framework: your email client compatibility checklist

Testing before a send means covering eight to ten client and mode combinations, not every client that exists.

A checklist is the last step of a testing process, not the whole of it – the full email testing and troubleshooting guide covers the workflow this checklist sits inside.

Essential testing categories

Pre-send testing checklist

• Apple Mail (iPhone) – mobile layout, responsive behaviour, touch target sizes, dark mode
• Apple Mail (macOS) – typography, spacing, retina image display, dark mode
• Gmail (web) – CSS stripping, image loading, responsive breakpoints
• Gmail (mobile apps, Android and iOS) – touch interactions, image caching, dark mode rendering
• Classic Outlook for Windows – VML rendering, table layouts, background images, image scaling
• New Outlook for Windows – web-based rendering, responsive behaviour, modern CSS
• Outlook.com – webmail rendering
• Yahoo Mail – image blocking, simplified rendering
• Dark mode across all of the above – image visibility, text contrast
• Accessibility – alt text, semantic structure, role="presentation" on layout tables, lang and dir attributes

The checklist above covers roughly 90 to 95% of most audiences. If your own analytics shows meaningful traffic from anything else – Samsung Email, Thunderbird, a regional client – add it. Anything above about two percent of your list deserves a look.

Testing tools and methodology

Litmus

Still the reference platform for cross-client previews, spam testing and analytics. Two things have changed and you should know both. Litmus is now part of Validity Engage, and the branding across the product reflects that. And Litmus no longer publishes self-serve pricing – the pricing page routes to a contact-sales form, and the only plan named publicly is Litmus Enterprise, priced by quote. Practically, that means the entry point for a freelancer or a small team is now a sales conversation rather than a credit card, which is a real change in who this tool is for.

Mailgun Inspect (formerly Email on Acid)

Email on Acid is being folded into Mailgun Inspect. Beginning June 2026, existing Email on Acid subscription customers started transitioning; annual-plan customers migrate at the end of their current term. Published pricing sits at $99 a month for Basic (1,000 previews) and $199 a month for Premium (2,000 previews, plus spam and deliverability testing and WCAG 2.2 accessibility checks), with $0.15 per preview over your allotment on both self-serve tiers and a contract tier by quote.

If you’re migrating, the differences that actually affect a workflow: previews are now allotment-based rather than unlimited, users are unlimited, Campaign Pre-check is gone (everything folds into one QA pass), and the Analytics feature has been removed. Inspect is pre-send QA only.

Parcel’s accessibility checker

Free on their Community plan, and it’s the same tool the Email Markup Consortium uses to produce its annual report. Which means you can test against exactly the criteria that generate the industry’s headline failure numbers, at no cost, before you send. In a section where the other two options start at $99 a month, that’s worth knowing.

Manual testing

Create real accounts in Gmail, Yahoo and Outlook.com. Set up desktop clients where you can. Send to yourself and look. Slow and free, and there’s a category of bug that only shows up when you actually scroll an email on a real phone with real thumbs.

Testing workflow

Design phase: test basic layout in the top three clients to catch structural problems early. No point building an entire email before discovering your layout approach doesn’t survive Outlook.

Development phase: test each component – header, content blocks, footer – individually before combining them. Finding out which of eleven modules broke the render is a bad afternoon.

Pre-launch: final QA across all target clients, with real content rather than lorem ipsum, because content length changes rendering.

Post-launch: watch for client-specific patterns in your analytics. If click-through is significantly lower from one client, investigate rather than assume.

Device testing strategy

• Current-generation iPhone with Apple Mail
• Recent Samsung Galaxy with the Gmail app
• iPad with Apple Mail
• Windows 11 with classic Outlook and with new Outlook, separately
• Mac with Apple Mail
• Any browser with Gmail web

You can’t test every combination – there are hundreds. These cover the categories that matter.

Automated testing integration

If you have a CI/CD pipeline, email testing belongs in it. The pattern is straightforward: on every push or pull request, submit the built HTML to your testing provider’s API, retrieve the results, and fail the build if critical issues are found. Set quality gates so a template with a broken Outlook render can’t deploy.

I’m deliberately not printing a copy-paste snippet with a specific endpoint here, because the endpoints keep moving – Litmus is mid-rebrand under Validity, and the Email on Acid API is becoming the Inspect API. Anything I wrote today would be wrong within a year and someone would paste it into a pipeline anyway. Check current API documentation for whichever platform you’re on, and build the pattern rather than the snippet.

Automated testing doesn’t replace human review. Automation catches technical regressions – broken layouts, CSS problems, missing alt text. It won’t tell you whether the email is any good.

---

Advanced email client compatibility techniques

Progressive enhancement is the technique that makes everything above manageable: one foundation that renders everywhere, one enhancement layer for clients that can take it.

Progressive enhancement strategy

Build emails in layers. Each layer improves the experience, and the email works without it.

Foundation layer (works everywhere)

Start with semantic HTML and inline CSS that works in every client, including classic Outlook and Yahoo Mail.

<table width="600" cellpadding="0" cellspacing="0" bgcolor="#ffffff" role="presentation">
  <tr>
    <td style="padding: 20px; font-family: Arial, sans-serif; font-size: 16px; line-height: 24px; color: #333333;">
      <h1 style="font-size: 28px; font-weight: bold; margin: 0 0 20px 0; color: #000000;">
        Universal Compatibility
      </h1>
      <p style="margin: 0 0 15px 0;">
        This content works in every email client because it uses only universally supported properties.
      </p>
      <table cellpadding="0" cellspacing="0" role="presentation">
        <tr>
          <td style="background-color: #0066cc; padding: 12px 24px;">
            <a href="https://yoursite.com" style="color: #ffffff; text-decoration: none; font-weight: bold;">
              Call to Action
            </a>
          </td>
        </tr>
      </table>
    </td>
  </tr>
</table>

The foundation layer above works everywhere. No advanced CSS, just reliable rendering. Note the role="presentation" on the layout tables – that’s the attribute missing from 83.78% of commercial email, and adding it costs nothing.

Enhancement layer (modern clients)

<style>
  /* Enhancements for modern clients */
  @media screen and (min-width: 600px) {
    .enhanced {
      border-radius: 8px !important;
      box-shadow: 0 2px 8px rgba(0,0,0,0.1) !important;
    }
  }
  
  @media (prefers-color-scheme: dark) {
    .dark-adaptive { background-color: #1f1f1f !important; }
    .dark-text { color: #ffffff !important; }
  }
</style>

Apple Mail users get rounded corners and shadows. Dark mode users get appropriate adjustments. Classic Outlook users see the foundation, which still looks professional without them.

Dynamic content adaptation

Client detection (where possible)

Conditional comments let you provide different experiences to different clients without breaking compatibility.

<!-- Outlook-specific content -->
<!--[if mso]>
<div style="background-color: #f0f0f0; padding: 20px;">
  Content optimized specifically for Outlook, including VML workarounds
</div>
<![endif]-->

<!-- Content for all other clients -->
<!--[if !mso]><!-->
<div style="background-image: url('background.jpg'); padding: 20px;">
  Content with background image that works in modern clients
</div>
<!--<![endif]-->

Outlook gets a simplified version, everything else gets the enhanced one. Remember that the new Outlook for Windows ignores these comments entirely, which is exactly what you want.

Performance optimization

Critical path: inline essential CSS in the HTML. Move non-critical enhancements to embedded <style> tags. Minimise file size by stripping unnecessary whitespace and comments – carefully, with a minifier built for email, so you don’t destroy MSO conditional comments. Optimise images aggressively; email images should be significantly lighter than web images.

That 102 KB Gmail ceiling is closer than it feels. A heavily nested template with inline styles on every cell burns through it fast, and the tracking links your ESP injects push you further. If you’re regularly near the limit, the answer usually isn’t minification – it’s a lighter template.

---

Future-proofing your email development strategy

The Word rendering engine is shrinking, privacy features are spreading, and both trends change what’s worth testing over the next few years.

Emerging trends to watch

Privacy measures keep expanding. Apple’s MPP now touches roughly 55 to 60% of opens. Gmail caches images through its own proxy. Expect more of this, not less. Open tracking is already a weak signal and it’s getting weaker; build your measurement around clicks and conversions before the decision is made for you.

New Outlook adoption changes your testing matrix, slowly. As Microsoft moves users off the Word engine, you’ll see less Word rendering in your analytics. That’s straightforwardly good news – fewer VML workarounds, fewer ghost tables. Watch your own Outlook breakdown rather than the announcements, because the announcements have been optimistic and the breakdowns have been stubborn.

Interactive email keeps growing and keeps being awkward. Polls, carousels, accordions. They depend on CSS support that varies wildly, and what works in Apple Mail routinely breaks in Gmail. Build a functional fallback before you build the interaction.

Accessibility is becoming a compliance question, not a nice-to-have. The EAA is in force, enforcement has started in member states, and the EMC data shows the industry is nowhere close. That gap is going to close by force at some point.

Skills development priorities

Essential competencies

Cross-client CSS understanding. Learn the principles – why classic Outlook needs VML, why Gmail strips what it strips – rather than memorising snippets. Snippets rot. Principles don’t.

Mobile-first design. Every email starts with the mobile experience. Desktop is the enhancement.

Accessibility from the start. Semantic HTML, heading structure, alt text, contrast, role="presentation", lang and dir. Retrofitting accessibility is more expensive than building it in, and given that 95.66% of emails are missing a body-level lang, doing it properly is currently a differentiator.

Performance. Image optimisation, HTML weight, staying under Gmail’s clipping threshold.

Testing discipline. Systematic QA, ideally automated enough that a regression can’t ship quietly.

Technology recommendations

Development stack:

{
  "testing": {
    "primary": "Litmus (Validity Engage) or Mailgun Inspect",
    "accessibility": "Parcel accessibility checker (free Community plan)",
    "reference": "caniemail.com, per property"
  },
  "development": {
    "framework": "MJML or Foundation for Emails",
    "preprocessor": "Sass for style management",
    "inliner": "Premailer or Juice"
  },
  "optimization": {
    "images": "imagemin plus appropriately sized assets",
    "html": "email-aware minification, preserving MSO comments"
  },
  "monitoring": {
    "analytics": "ESP client breakdown",
    "performance": "clicks and conversions rather than opens"
  }
}

Frameworks like MJML generate table-based layouts with VML workarounds automatically, which lets you write cleaner source. They’re not magic – you still need to know what the output does and why – but they remove a category of manual error.

Staying ahead of client updates

Subscribe to client release notes where they exist. Follow caniemail.com’s changelog, which is the most reliable early warning system in this space. Participate in the email developer communities – Email Geeks Slack, the Email Markup Consortium – because breaking changes usually surface there before they surface anywhere official.

When a client updates, assess the impact on your templates, prioritise by how much of your audience it touches, test before it reaches saturation, and write down what changed. That last part matters more than it sounds. Half the outdated advice in this industry survives because nobody documented when a workaround stopped being necessary, and people are still shipping hacks for bugs that were fixed in 2019.

---

What to do before your next send

Email client compatibility is a technical problem with direct business consequences. 99.88% of HTML emails contain serious or critical accessibility issues, and almost half ship images with no alt text. These aren’t abstract problems – they’re the reason campaigns underperform in ways that never show up as a line item.

The landscape is more concentrated than it used to be and no simpler for it. Apple and Gmail together account for close to 90% of tracked opens, and neither is a single rendering target. Outlook holds under 6% globally and dominates the enterprise inboxes that pay your invoices. You can’t design for one client and hope.

Core principles for email client compatibility success:

Prioritize your actual audience. Apple and Gmail cover most people globally. Your list is not the global list. Check your own client breakdown before you decide what to optimise.

Mobile-first is the baseline. Build for the phone, enhance for the desktop. Fluid base layout, media queries as enhancement, never as a dependency.

Progressive enhancement works. A foundation that renders everywhere, an enhancement layer for clients that can take it. Your email should function in classic Outlook and look good in Apple Mail, and those don’t have to be the same email.

Verify support per property. caniemail.com, every time, rather than a remembered summary. I found three errors in my own list doing exactly that.

Test systematically. Eight to ten configurations, light and dark, every send. Automate what you can.

Email client compatibility isn’t about making emails look identical everywhere. It’s about making them work and look professional across platforms. A table-based layout in Outlook doesn’t need to match the Apple Mail version pixel for pixel. Both need to communicate the message and drive the action.

Take action today:

• Run your last three campaigns through a preview tool and note what breaks and where
• Pull your own client breakdown from your ESP – not the global chart, yours
• Add role="presentation" to every layout table and alt text to every image, which takes an afternoon and puts you ahead of most of the industry
• Set up a testing workflow covering Apple Mail, Gmail and both Outlooks as the minimum
• Check your template’s HTML weight against the 102 KB Gmail threshold
• Pick one thing on this list and do it before your next send rather than reading a second article

---

Common questions about email client compatibility

Which email client has the largest market share?

Apple is the largest, at 62.26% of tracked opens in Litmus Email Analytics for July 2026, with Gmail second at 27.03% and Outlook desktop third at 5.83%. Apple’s figure bundles iPhone, iPad, macOS Mail and Mail Privacy Protection opens, which is part of why it reads so high. Your own list can look nothing like this – check your ESP’s client breakdown before you set testing priorities.

Does classic Outlook still use the Word rendering engine, and when does that end?

Yes. Classic Outlook for Windows still renders HTML through the Word 2007 engine, and so do the perpetual Office releases built on it. Office 2021 and Office LTSC 2021 lose support on 13 October 2026, but Office 2024 runs to October 2029, and Microsoft supports existing classic Outlook installations until at least 2029. Word-engine rendering is shrinking, not disappearing this year.

Why does the same email look different in Gmail and in Apple Mail?

Different engines, and different filtering on top. Apple Mail runs WebKit and renders close to what Safari would show. Gmail runs Blink but sanitises your HTML before rendering it, dropping selectors and declarations it doesn’t trust and caching images through its own proxy. Same code goes in, two different documents come out. The rendering engines section above covers what each engine does to your markup.

Which CSS properties does Gmail strip?

Gmail blocks external stylesheets outright, and drops selectors and declarations its sanitiser rejects, which is why inline styles survive most reliably. There is no fixed published list – support is property by property, and it differs between Gmail on the web and the mobile apps. Check each property on caniemail.com before you rely on it, then confirm in a real Gmail preview rather than a rendering tool.

Why does Gmail cut an email off partway through?

Gmail clips a message once its HTML passes roughly 102 KB, hiding the rest behind a “View entire message” link. Images don’t count toward the limit – only the code does. The tracking pixel usually sits below the cut, so clipped sends under-report opens as well as hiding content. ESPs add tracking links after you hand off the file, so build under about 100 KB.

Do media queries work in email?

Partly. Can I Email lists @media as supported in Apple Mail and partially supported in Gmail, Outlook and Yahoo Mail. Classic Outlook for Windows ignores media queries entirely and renders at whatever width you set. Build the base layout to work fluidly using percentage widths and max-width, then layer media queries on top as an enhancement rather than a dependency.

How many email clients need testing before a send?

Eight to ten configurations cover most audiences: Apple Mail on iPhone and macOS, Gmail on web and in the apps, classic Outlook for Windows, new Outlook for Windows, Outlook.com and Yahoo Mail, each in light and dark mode. Add anything your own analytics shows above roughly two percent. Testing every client that exists is neither possible nor useful.

Does an email need a separate dark mode version?

No. You want one email that survives inversion, not two builds. Set the color-scheme meta tag and CSS property, pick colours that still work when a client darkens them, use transparent PNGs with a stroke or padded background for logos, and swap logo images with prefers-color-scheme where it’s supported. Classic Outlook for Windows ignores dark mode entirely.

---

Resources for continued learning:

• Litmus Email Client Market Share – updated monthly
• Can I Email – per-property compatibility reference, and the one to trust over any summary table
• Email Markup Consortium Accessibility Reports – annual analysis, plus the client feature support rankings
• Campaign Monitor CSS Support Guide – property-by-property reference

About this guide: this analysis draws on Litmus Email Analytics, the Email Markup Consortium’s 2026 Accessibility Report and Email Client Feature Support Rankings, caniemail.com, Microsoft’s Outlook product and lifecycle documentation, and Mailgun and Litmus product documentation. Figures reflect the most recent published data as of August 2026. Where a widely circulated statistic couldn’t be traced to a primary source, it was removed rather than repeated – which is why a few numbers you may remember from earlier versions of this article are no longer here.