Common email rendering issues and how to fix them

Quick answer: Most email rendering issues come from four places. The Word based rendering engine in classic Outlook for Windows. Gmail’s CSS sanitizer plus its 102 KB clipping limit. Dark mode colour inversion, which behaves differently in nearly every client. And partial media query support everywhere except Apple Mail. Nearly all of them are reproducible and fixable. The trick is identifying which rendering engine is failing, rather than which app is failing.

The email that breaks is almost never the one you were worried about. You test the fancy one. The one with the gradient header and the animated GIF and the four column footer nobody asked for. That one comes back clean. Then a plain text-and-button reminder falls apart in a single client, at one display scaling setting. There goes your afternoon. I have been doing cross-client email layout for years. One pattern keeps coming back. Most email rendering issues get debugged the wrong way round.

People chase the client name. Outlook broke it, Gmail broke it, Apple Mail did something weird. But there aren’t forty email clients to memorise. There are about five rendering engines wearing forty different hats.

Once you know which engine is chewing on your HTML, the fix stops being a guess. It becomes close to deterministic, which is a fancy way of saying you already know what to type.

This guide covers the email rendering issues that actually show up right now, and it will need updating. That’s the honest bit. The Outlook situation moves fast enough that half the advice ranking on Google is quietly wrong, and I mean that specifically, not as a figure of speech. I’ll show you where.

Why the same HTML looks different in every inbox

Email rendering issues happen because your HTML is not rendered by a browser. It is rendered by whatever engine the mail client bolts on. Those engines were built for very different jobs.

Some of them were never meant to render web pages at all. One of them, and I still find this genuinely ridiculous in 2026, was built to lay out documents you print.

The five engines you’re actually dealing with

Engine	Where it lives	What it breaks	Survival rule
Word / MSO	Classic Outlook for Windows (2016, 2019, 2021, LTSC)	No flexbox, no grid, no border-radius, unreliable padding on divs, background images need VML	Tables for layout, HTML attributes for sizing, conditional code for the rest
WebKit	Apple Mail on macOS and iOS, Outlook for Mac	Very little, honestly	The only place full media query support is reliable
Blink / Chromium	Outlook.com, Outlook on the web	Little, but it applies its own dark mode logic	Test it separately from Apple Mail anyway
WebView2	New Outlook for Windows	Chromium underneath, then a post-load step rewrites your CSS	See the new Outlook section below, it is stranger than it sounds
Gmail’s hybrid	Gmail web, Gmail iOS, Gmail Android	Blink rendering plus an aggressive sanitizer that strips and rewrites CSS	Keep the HTML small, keep the CSS boring

That’s the whole map. Five columns, not forty. It is also why I sort email rendering issues by engine rather than by client name.

The framing matters because it changes what “thorough testing” means, and therefore what it costs. You do not need a screenshot of every client on earth. You need one per engine, plus a couple of passes for dark mode. Dark mode is its own separate mess.

What this means for how you test

Pick one representative client per engine and test properly in those. Then spot check the rest.

In practice: classic Outlook on Windows, Apple Mail on iPhone, Gmail web, Gmail on iOS, new Outlook for Windows. Gmail web and Gmail on iOS are not the same environment. Five setups covers most of what will realistically go wrong.

Everything below is organised by engine, because that’s how the fixes are organised too.

Outlook email rendering issues, and what has actually changed

Outlook email rendering issues are still the biggest bucket, but the reason has shifted. It is no longer just “Word engine bad”. There are now two completely different Outlooks for Windows, and they fail in completely different ways.

The Word engine, honestly

Classic Outlook for Windows renders HTML email using Microsoft Word’s rendering engine. Not a browser. Word. The thing you write documents in.

That means no flexbox, no CSS grid, no border-radius, no reliable padding on a div. Background images only work through VML. It is a document layout engine doing a web layout job, and it does it badly.

Here’s the part most articles get wrong. This is a shrinking problem, not an eternal one.

The numbers, as of May 2026: Litmus Email Analytics put Apple at roughly 64.7% of global email opens. Gmail sat at 24.1%, Outlook at around 6.5%. That’s calculated from over a billion opens.

Those figures bounce around month to month, sometimes by a lot. Treat them as a shape, not a precise reading.

Six and a half percent. Globally.

But global averages are useless if you send B2B. Outlook is heavily overweighted in corporate and enterprise lists. There it can easily be a quarter of your opens. That’s why you pull your own client breakdown from your ESP instead of trusting anybody’s blog post, mine included.

The timeline you need on a sticky note. And read this bit carefully, because a lot of articles currently have it wrong, including one I nearly published myself:

Already gone: Office 2016 and Office 2019 dropped out of support on 14 October 2025. Outlook 2016 and 2019 still run. They just don’t get patched.
13 October 2026: Office 2021 and Office LTSC 2021 reach end of support. That takes Outlook 2021 with it, no extension, no paid extended security updates.
1 March 2027: the enterprise opt-out phase starts, when new Outlook becomes the default and users can still switch back. Microsoft originally set this for April 2026 and then postponed it by roughly a year in a Message Center notice, MC949965. If you read somewhere that opt-out already happened, that page hasn’t been updated.
March 2028 at the earliest: the cutover phase, where switching back stops being an option. Microsoft has promised admins at least twelve months of notice after opt-out begins.
At least 2029: existing classic installs on perpetual and Microsoft 365 desktop licences stay supported. Third-party trackers keep quoting Q2 2029 as the hard stop. Microsoft’s own wording is “at least through 2029”, which is not quite the same thing.

Note what that list does not say. Office 2024 and Office LTSC 2024 ship classic Outlook, still on the Word engine, and they’re supported well past all of this. So the sentence “the Word engine dies in October 2026” is wrong. What dies in October 2026 is one generation of it.

The engine is on a clock. It is not gone. Perpetual licence and LTSC installs will sit in conservative enterprises for years. Patched, supported, and rendering your email like it’s 2009.

My working position: keep the MSO fallbacks, but start dating your code. Leave a comment above every Outlook hack with the year you added it. Future you will thank present you.

The classic bugs, with fixes and what they cost

These are the classic Outlook email rendering issues, roughly in the order I hit them. Each gets an effort tag, because the fix is only half the decision. The other half is whether it’s worth maintaining for your list.

Random white lines through images

Symptom: thin white or grey lines slicing through a sliced hero image, usually at 125% or 150% display scaling. Cause: Word’s engine rounds fractional pixel heights and leaves a gap. Microsoft has never fixed it. It has been broken for well over a decade and it still drives me up the wall. Fix: use even pixel heights on sliced images. Add border-collapse: collapse and mso-table-lspace: 0pt; mso-table-rspace: 0pt to your tables. Set display: block on images. If it persists, put a ghost break in the cell. Effort: quick. Retire by: don’t, not yet. Costs almost nothing to keep.

Images rendering at full size

Symptom: your 600 pixel hero renders at its native 1200 pixels and blows the layout apart. Cause: classic Outlook ignores CSS width and height on images. Fix: always set the width and height HTML attributes on <img>, not just the CSS. Both. Every time. Effort: quick. Retire by: never. This is just good email HTML.

Fonts falling back to Times New Roman

Symptom: your carefully chosen web font stack collapses to a serif that looks like a legal notice. Cause: classic Outlook hits a font it does not have at the top of the stack. Then it gives up on the whole chain, instead of moving down it. Fix: the reliable one is an MSO conditional <style> block that forces a websafe stack for Outlook only. Rémi Parmentier worked out why this happens at all: Outlook reads your @font-face, can’t load the file, and falls back to mso-generic-font-family, which defaults to roman. Set mso-generic-font-family and mso-font-alt in the @font-face declaration and you get proper control. The attribute selector trick works too. Keep a real websafe font last in the stack regardless. Effort: moderate. Retire by: monitor from 2027.

Background images not showing

Symptom: your section background is just white. Or worse, white with white text on it. Cause: classic Outlook does not support CSS background images. Fix: VML <v:rect> or <v:image> inside a conditional comment, with the CSS version for everyone else. Effort: expensive. VML is verbose, fragile, and adds real weight to your HTML. Retire by: this is the first one I’d drop. If classic Outlook is under about 3% of your opens, use a solid colour fallback. Spend the time elsewhere. A flat brand colour behind white text is not a failure. It’s a fallback.

Padding and margins ignored on divs and images

Symptom: spacing collapses, everything jams together. Cause: unreliable box model support in the Word engine. Fix: put padding on table cells instead of divs. Use spacer rows where you must. Add mso-line-height-rule: exactly immediately before every line-height declaration. Effort: quick, if you build in tables to start with. Retire by: not soon.

Two column layouts collapsing

Symptom: side by side columns stack, or overflow the container, in desktop Outlook only. Cause: no support for the modern layout properties you’d normally reach for. Fix: ghost tables in conditional comments, with fixed pixel widths inside them. Effort: moderate. Retire by: monitor. Ghost tables are the workaround I expect to become legacy first, but not before 2027.

The new Outlook problem nobody warned you about

This is the section I’d want somebody to send me.

New Outlook for Windows runs on WebView2, which is Chromium. On paper this is great news. Border-radius works. CSS background images work. Gradients work. A decade of hacks becomes unnecessary.

Except.

In April 2026, Mark Robbins wrote up a set of new Outlook rendering issues for Customer.io. He drew partly on DevTools digging by Brian Thies, shared in the EmailGeeks Slack. What they found is that new Outlook appears to run a post-processing step after the email loads. Something rewrites the CSS after the initial render.

The reported symptoms:

border-radius: 20px 20px 0 0 becoming 20px on all four corners
shorthand background properties breaking
<style> blocks disappearing from the DOM and reappearing inlined
media queries not firing

And three characteristics that make this genuinely maddening:

It only happens in the preview pane. Open the same message in its own window and the problems vanish.
Sometimes the correct version flashes first, for a split second, before the broken version replaces it.
It is inconsistent. One email breaks, an identical one doesn’t.

The diagnostic tell: right in a separate window, wrong in the preview pane? That’s this bug, not your code.

I want to be straightforward about the limits of what we know. The community does not fully understand this yet. Nobody has a clean reproduction case. It might be a WebView2 installation issue on some machines, or Outlook’s own inlining routine. Possibly both.

What I’d do about it, in practice:

Prefer single column layouts where the design allows
Use inline images rather than CSS background images for anything that carries meaning
Keep border-radius even on all four corners when you can live with it
Keep desktop and mobile styles closer together, so a dead media query is survivable
Do not rebuild your templates over this

That last point matters. This looks temporary and edge-case. Rebuilding a template library around a bug that may be patched next quarter is a bad trade. But do stop assuming Chromium automatically means safe. That assumption is now wrong.

One more thing worth noting, and I’m including the ending because I hate articles that leave you hanging. After the 12 May 2026 updates, classic Outlook started dropping embedded images in emails, newsletters and signatures, showing the red X and a “linked image cannot be displayed” error. It hit builds from Version 2604 (19929.20164), it was triggered by the Wrap Text Top and Bottom option, and it only affected the legacy client. Microsoft sat on it as INVESTIGATING for a few weeks and then shipped a fix in June.

That one was a composition bug rather than a campaign HTML bug, so it probably never touched your templates. I mention it because of the pattern: new regressions still land on the old client, and they take a while to come back out. That’s what software with a retirement date looks like.

What to retire and when

Workaround	Verdict for 2026	Trigger to drop it
HTML width and height on images	Keep forever	Never, it’s just correct
Even pixel heights, ghost breaks	Keep	When classic Outlook is under 1% of opens
`mso-line-height-rule: exactly`	Keep	Same
Ghost tables for columns	Keep, monitor	Classic under 3% and no legacy enterprise segment
VML background images	Monitor, probably drop	Classic under 3%, or the first time it costs you a deadline
MSO conditional comments generally	Keep	Not before 2028

Pull the actual numbers from your ESP before you make any of these calls. Every list is different. A SaaS company selling to banks does not have the same Outlook problem as a fitness creator. They should not be running the same fallback code.

Gmail email rendering issues, and why half of them are size problems

Gmail rendering issues break into two categories. The CSS it throws away. And the fact that it will cut your email in half if it gets too big.

The second one causes more damage, and almost nobody checks for it.

Clipping at 102 KB, and much lower on iOS

Gmail clips the message when the raw HTML goes past roughly 102 KB. You get a “Message clipped” link, and everything after the cut hides behind it.

Images don’t count towards that limit, since they load externally. But the markup that displays them does. So do your tracking URLs, your inline styles, your head, and every redirect link your ESP rewrites at send time.

The Gmail iOS app clips far lower, around 20 KB. The number everyone quotes, including me, traces back to a single Email on Acid experiment that measured the cutoff at roughly 20,540 characters. Worth knowing that the test is old, from 2014, and nobody has properly redone it since. Two details from it have held up though: the limit is applied inconsistently, with an email clipped on one day of testing not clipped on another, and characters inside your <style> block don’t count towards it. Delightful all round.

Two consequences most people miss:

One: the clipped version strips <style> tags. Klaviyo documents this plainly in their help centre: the “View entire message” link opens a version Gmail generates with all <style> tags removed, so alignment, column styles and table styles can go with them. An email that relied on embedded CSS doesn’t just get cut short. It loses its styling as well. That’s why the full version so often looks like a completely different, much uglier email.

Two: the tracking pixel usually sits at the bottom. If it gets clipped, the open never registers. Your open rate is then wrong, in a direction that looks like a deliverability problem but isn’t.

Fixes, roughly in order of return:

Strip builder-generated bloat. Drag and drop editors produce staggering amounts of redundant markup.
Shorten and deduplicate repeated inline styles.
Minify, but use an email-aware minifier so MSO conditional comments survive.
Encode special characters as HTML entities.
Aim for 80 KB, not 102 KB. Your ESP adds tracking and link rewrites after you hit export.
If the content genuinely has to be long, send a teaser and link out.

Effort: moderate the first time, then quick forever, because you fix the template rather than the email.

The CSS Gmail throws away

Gmail supports embedded <style> blocks in most modern contexts, which surprises people who learned email in 2015. But the sanitizer is strict, and here’s the thing that actually bites: it fails all-or-nothing. Gmail does not skip the rule it dislikes. It throws away the whole block.

Three documented ways to trigger that:

One CSS error. A stray bracket, an invalid property, anything it can’t parse. Whole block, gone.
Over 8,192 characters in a single <style> block. Same result.
A nested at-rule. @font-face or @import inside a @media block. Rémi Parmentier found this one, and it’s still the least-known of the three.

You’ll also see the claim that a background-image: url(...) anywhere in the block nukes it. That was real, briefly. Google rolled it out in July 2023, the email community shouted, and it was rolled back inside a couple of weeks. It’s not current behaviour. I’d still keep background images out of embedded blocks, partly out of superstition and partly because if it ever comes back you’ll want them isolated anyway. Put them in their own <style> block if you must, since Gmail only drops the offending one.

Also stripped or rewritten: external stylesheets and @import, most flexbox sub-properties, CSS grid, transforms, animations, transitions, box-shadow, filter, and clip-path. Class names get prefixed with Gmail’s own namespace.

And one that catches nearly everybody at least once: the Gmail app used with a non-Google account, which the community calls GANGA, doesn’t support <style> blocks at all. Not strictly, not partially. At all.

The practical rule: inline your critical styles. Treat the embedded block as an enhancement layer for responsive behaviour. If losing that block would destroy the email, the email is built wrong.

The Promotions tab and mobile previews

Brief, but it sets up something later.

Gmail’s tabs decide what your email is compared against. In Promotions you sit next to every other offer that arrived that morning. That changes what “good” means for your subject line and preview text.

And the preview text itself is becoming less yours than it used to be. More on that below.

Dark mode email rendering issues: the ones that break quietly

Dark mode email rendering issues are the ones nobody reports. The email doesn’t collapse. It just looks slightly off, or the logo grows a white box. The subscriber deletes it and says nothing.

Around 35% of measured opens now happen in dark mode, per Stripo’s tracking, up from roughly 28% a year earlier. Treat the 35% loosely, mind you. Litmus published a very similar number back in 2022 and it has been quoted secondhand ever since, so the trend is solid and the decimal places are not. On the sender side, Email on Acid’s survey found only about 11% say they always consider dark mode. And an Android Authority survey puts smartphone users with dark mode switched on at system level at 81.9%.

That gap is the whole story. A third of your audience, and one in nine senders paying proper attention.

Three different dark modes, not one

This is why “does dark mode work” is not an answerable question.

Behaviour	Which clients	What happens to your email
No inversion	Some webmail and older clients	Nothing. Your light design stays light.
Partial inversion	Outlook.com, new Outlook, some Gmail contexts	Backgrounds and text shift, brand colours mostly survive
Full forced inversion	Gmail on Android, some Apple Mail configurations	Everything flips, including things you did not want flipped

Apple Mail is the one that gives you real control: it supports prefers-color-scheme properly. The Outlooks support it partially, which in practice means Outlook.com and new Outlook honour it and the older desktop builds do their own thing. Gmail does not support it. At all, on any platform. Can I Email has had it filed under “not supported” for Gmail and Yahoo for years and nothing has changed.

So every dark mode media query you write is an Apple Mail feature with some Outlook spillover. Plan accordingly.

The failures you’ll see in practice

Logos in a white box. A JPG or a non-transparent PNG keeps its white background when everything else goes dark. The single most common one.
Dark text on a now-dark background. Your dark grey body copy stays dark, the background inverts, contrast disappears.
Brand colours shifting. Enough to break visual hierarchy, sometimes enough to be off-brand entirely.
Black logo elements vanishing. The reverse of the white box problem.
Drop shadows doing something strange. Rarely worth fixing, usually worth removing.

Fixes that hold up

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

Those two lines go in the head. Standard advice, and worth doing, but let me be straight about the reach: Can I Email lists the color-scheme meta as only partially supported in Apple Mail and not supported in Gmail, Outlook or Yahoo. So it’s cheap insurance with a narrow blast radius, not the switch that fixes dark mode. Anyone telling you those two tags solve inversion is selling something.

Then:

Use transparent PNGs for logos, with a thin outline stroke or a light version behind a prefers-color-scheme swap
Avoid pure #FFFFFF and pure #000000. Near-white and near-black invert more gracefully.
Check contrast in both modes, not just light
Test dark mode as a standard step, not a bonus round

Effort: moderate to set up in a template, quick per email afterwards.

A note on the glow-behind-the-logo trick that gets recommended constantly. It works, technically. Designers hate it, and they’re right to. A properly prepared transparent PNG with a subtle outline looks intentional. A drop shadow halo looks like a mistake somebody tried to cover up.

Why “just make it all one image” is the wrong answer

I get asked this maybe once a month, and the answer is a firm no.

A single-image email fails accessibility completely. It fails screen readers and looks blank when images are blocked, which is still a real scenario. And also it overrides a display preference the subscriber deliberately chose.

In 2026 it also produces a useless AI summary. The summarisers read body text and ignore alt text. More on that shortly.

It has always been the wrong answer. It’s just more wrong now than it used to be.

Mobile and responsive email rendering issues

Roughly speaking, the inbox is a phone. Building desktop-first and then squashing it is the wrong order, and it produces most of the mobile complaints I see.

Media queries were never universally supported

Here’s the precise picture, because a lot of tutorials are vague about this.

Apple Mail is the only common client with full media query support. That’s it. One.

Gmail supports media queries partially, and behaviour differs between the web version and the mobile apps. Usually enough for basic mobile adaptation.

Outlook for Mac, Outlook for iOS and Android, Outlook.com and new Outlook all support media queries partially.

Classic desktop Outlook for Windows does not need them, because it isn’t responsive at all. It renders at whatever width you set and stays there. Which is oddly restful.

So a media query is an enhancement. If your layout only works when the media query fires, your layout does not work.

The hybrid approach that actually survives

Build a base layout that holds up at any width using percentage widths and max-width. Then layer media queries on top for the clients that support them.

Container at width: 100% with max-width: 600px
Columns as percentage widths, not fixed pixels, wherever Outlook allows it
Ghost tables with fixed widths inside conditional comments, for classic Outlook only
Media queries handling the two-column to one-column stack, for clients that listen

It’s more work than picking one approach. It’s also the only thing I’ve found that behaves predictably across all five engines.

Buttons, tap targets and the small text problem

Bulletproof buttons means a padded table cell with a background colour and a text link inside. Not an image of a button. Images get blocked. Padded cells don’t.

Minimum 44 by 44 points for anything tappable, per Apple’s Human Interface Guidelines. Points, not pixels, which on a modern Retina screen means the physical pixel count is higher. In practice I go larger than the minimum anyway.

Body copy at 16 pixels minimum. Below about 13 pixels, iOS may auto-scale your text and quietly wreck the layout you tested. Add -webkit-text-size-adjust: 100% to the body to stop it.

Full width buttons on mobile. Nobody has ever complained that a CTA was too easy to tap.

The stuff that isn’t rendering but gets blamed on it

This bucket is where a lot of “my email is broken” tickets really live. It all gets reported as email rendering issues. None of it is a CSS problem.

Images blocked by default

Plenty of clients still block images until the recipient allows them. If your email is mostly images, what arrives is a stack of empty boxes.

Style your alt text. Give it a font family, a size and a colour that works against the background. It costs nothing, and a blocked-images open still communicates something.

Your ESP is a rendering step too

GetCourse, Braze, Mailchimp, Salesforce Marketing Cloud, HubSpot. They all do versions of the same thing. They rewrite your HTML on the way in, on the way out, or both.

Link rewriting for tracking. Injected tracking pixels. Occasionally the editor “helpfully” reformatting markup it doesn’t recognise, which is how conditional comments get eaten.

The rule: paste the raw HTML, save, then test again from inside the platform. Not from your local file. The platform is a rendering step. Testing the version you wrote, rather than the version it sends, tests the wrong thing.

Had an email pass every check and still break on send? This is where I’d look first.

AI summaries have replaced your preview text

This one doesn’t look like a rendering issue and absolutely is one.

Apple Mail on Apple Intelligence devices generates an on-device summary. It shows up where your preheader used to be. Gmail has been rolling out Gemini-powered summaries through 2026. The recipient reads a machine’s paraphrase before deciding whether to open.

Knak tested this properly when the feature landed and confirmed something important: Apple Intelligence does not use alt text when generating summaries. Neither does it read text baked into images. Twilio and Inbox Monster ran their own versions of the test and got the same answer, which is about as close to settled as this stuff gets.

So an image-heavy email produces a thin, vague, or actively misleading summary. Your beautifully typeset hero headline might as well not exist. The summariser can’t read it.

What to do: put your core message in real HTML text, near the top. One clear point, plainly stated. Keep the preheader, because it still feeds the summary as input and still shows in non-AI clients.

Semantic structure and live text are now rendering concerns. That’s new, and it’s going to matter more every year.

Apple Mail categories

Primary, Transactions, Updates, Promotions. Same idea as Gmail’s tabs, now on iOS and macOS.

It changes where your email lands, and therefore what it sits next to. Not a rendering issue in the strict sense, but it belongs in the same conversation. It changes what the recipient sees before they open anything.

How to test for email rendering issues without spending $6,000 a year

Some links in this section are affiliate links. I only recommend tools I’d use myself. I’ll say plainly when the cheaper option is the right call.

A testing order that catches most things fast

Do these in order. Each step catches a different class of problem, and the early ones are free.

Render in a browser first. Open the HTML file in Chrome. This catches structural mistakes, broken image paths and unclosed tags in about thirty seconds.
Send to a real seed set. Your own Gmail, your own Outlook, your own iPhone. Real clients on real devices beat any screenshot for the things that matter most.
Screenshot service for the engine coverage you can’t reach. Classic Outlook 2019 and 2021, Gmail Android, the versions you don’t own.
Dark mode pass. One forced-inversion client and one partial-inversion client. Two screenshots, not twenty.
Clipping check. Actual file size in kilobytes, measured after your ESP has done its rewriting. Not perceived length.
The unglamorous list. Every link, alt text on every image, the plain text version, and the unsubscribe.

That order exists because steps one and two are free. They catch most email rendering issues before you’ve spent a penny. Do not start with the expensive tool.

Tools and prices, checked August 2026

Pricing in this category moves constantly, so I re-checked all of it while writing. Two things have changed enough to matter.

Tool	Price	What you get	Who it’s for
Litmus Core	$500/month	5 users, 2,000 previews/month, 100+ clients, QA checks, analytics	Agencies and in-house teams sending constantly
Mailgun Inspect Basic (was Email on Acid)	$99/month	Unlimited users, 1,000 previews/month, $0.15 per overage	Small teams and freelancers who need real coverage
Mailgun Inspect Premium	$199/month	2,000 previews, plus accessibility testing and spam content checks	Teams that want QA automation too
Mailtrap Email Sandbox	Free tier, paid from around $17/month	SMTP sandbox, HTML analysis, pipeline testing	Developers testing in a staging environment
Mailosaur	From $9/month on Starter	Automated inbox testing via API	Anyone testing email inside CI
Your own devices	Free	One iPhone, one Windows machine, three webmail accounts	Everybody, always, first

On Litmus. In August 2025 the $199/month Plus plan became Core at $500/month. That’s a 151% increase for the same feature set. The $99 Basic tier was removed entirely. Litmus was acquired by Validity in April 2025, and the pricing moved a few months later. Draw your own conclusions.

The preview arithmetic is worth doing before you commit. Every individual client screenshot counts as one preview. Test one email across six Outlook versions and three Apple Mail versions, desktop and mobile. That’s around 18 previews gone. Two thousand a month sounds generous until you’re iterating on a template.

On Email on Acid. This changed recently and most articles haven’t caught up. Email on Acid is becoming Mailgun Inspect, with existing subscribers starting to transition in June 2026 and annual-plan customers migrating at the end of their current term. Basic is $99/month with 1,000 previews and $0.15 per preview overage. Premium is $199 with 2,000.

The old “unlimited previews” pitch is gone, and Mailgun’s own migration guide says so in as many words: no more unlimited previews, but unlimited users instead. Existing previews and tests don’t carry across the migration either. If you picked Email on Acid specifically for unlimited testing, go and check what your plan turns into. It’s still better value than Litmus for most people. It’s just not the same deal.

On the developer tools. Mailtrap’s numbers confuse people because there are two products. The Email API plan starts at $15. The one you want for testing is Email Sandbox, which has a free tier of about 50 tests a month and paid plans from roughly $17. Mailosaur starts lower than most comparison articles claim, $9 on Starter, though the seat-plus-volume pricing means the real number depends on your team.

On Putsmail. It’s retired. The page just says so now, one line, no ceremony. A lot of older tutorials still link to it. Better you hear it here than after ten minutes of clicking.

My honest recommendation, tiered:

One email a month, small business: your own devices plus a free tier. You do not need a $500 subscription. You need an iPhone, a Windows laptop and twenty minutes.
Weekly sends, one person: Mailgun Inspect Basic at $99. The previews cap is fine at that volume.
Agency or a real in-house programme: Litmus is still the most complete platform. At agency volume the cost per email is defensible. At solo volume it is not.

If the honest answer is “you don’t need the expensive thing”, that’s the answer. Recommendations only mean anything if they can go the other way.

The pre-send checklist

Twelve items. Screenshot it, print it, tape it to something.

Rendered in a browser, no structural errors
Sent to a real seed set: Gmail, Outlook, iPhone
Classic Outlook checked at 100% and 125% display scaling
New Outlook checked in the preview pane and in a separate window
Dark mode checked in a forced-inversion and a partial-inversion client
HTML size measured after ESP processing, under 80 KB
Tracking pixel positioned so clipping can’t eat it
Every image has a width and height attribute
Every image has styled alt text
Every link tested, including the unsubscribe
Core message present as live HTML text, not baked into an image
Preheader written, and the email still reads sensibly if a summariser rewrites it

What breaks next: email rendering through 2030

Predictions, with confidence levels attached. I’d rather be specific and occasionally wrong than vague and unfalsifiable.

High confidence: the Word engine becomes irrelevant somewhere between 2028 and 2030. The dates keep slipping and I’ve stopped being surprised by it. Slowly and unevenly, with enterprise holdouts dragging the tail past whatever the official date is by then. Ghost tables and VML become legacy code you maintain rather than code you write.

High confidence: dark mode support consolidates but never fully standardises. Designing for both modes stops being a nice-to-have and becomes the baseline. I expect client behaviour to converge somewhat, but not to become identical. It never does.

Medium confidence: CSS support improves faster in the next four years than in the last fifteen. Engine consolidation onto Chromium family renderers is the reason. I think flexbox and grid become genuinely usable in email before 2030 in most clients. Gmail’s sanitizer will be the last holdout, and the reason we still can’t have nice things.

Medium confidence: AI summaries become the primary rendering surface. What the summary says will matter more than what the hero image looks like. That’s a strange sentence to write as an email developer. It’s also where this is going. Semantic structure, real text, clear hierarchy.

Low confidence, but worth watching: interactive email stays niche. AMP for email was announced in 2018 and went live in Gmail in 2019. It still runs in Gmail, Yahoo Mail and Mail.ru, plus FairEmail if we’re being generous about what counts. You register once through a shared sender form, all three providers review you separately, Gmail wants your DMARC policy at quarantine or reject before it’ll even look, and you ship a full HTML fallback anyway. Roughly seven years, three clients. I wouldn’t build a strategy on it.

The constant: testing does not get cheaper. Litmus went up 151% in one move. The unlimited previews plan is gone. Free tools keep getting retired. The email rendering issues change every couple of years, but the need to test them doesn’t. Budget for it as a line item.

FAQ about email rendering issues

Why does my email look different in Outlook than in Gmail?

Because they use different rendering engines. Classic Outlook for Windows uses Microsoft Word’s engine, which ignores flexbox, grid, border-radius and CSS background images. Gmail uses a Chromium-based renderer with an aggressive sanitizer that strips CSS it doesn’t approve of. Same HTML, two very different interpretations of it.

Is the Outlook Word rendering engine going away?

Yes, but slower than most articles suggest. Microsoft pushed the enterprise opt-out phase back from April 2026 to March 2027, so new Outlook is not yet the forced default. Office 2021 and LTSC 2021 lose support on 13 October 2026, but Office 2024 still ships classic Outlook on the Word engine. Existing classic installs stay supported at least through 2029. Keep your MSO fallbacks.

Why does my email render correctly for a second and then break in new Outlook?

New Outlook runs a post-processing step after the email loads. It appears to rewrite your CSS inline, altering or dropping properties. This affects the preview pane only. Open the message in its own window and it renders correctly. It is documented behaviour, not a mistake in your code.

What is the maximum email size before Gmail clips it?

Around 102 KB of raw HTML on desktop. The Gmail iOS app clips much lower, at roughly 20 KB, applied inconsistently, though that figure comes from a single Email on Acid test in 2014 that nobody has redone. Aim for 80 KB before sending. Your ESP adds tracking pixels and rewrites links afterwards, easily another 20 to 30 KB.

How do I stop my logo getting a white box in dark mode?

Use a transparent PNG rather than a JPG or a flat PNG. Add a thin outline stroke so the mark stays visible against both light and dark backgrounds. Declare color-scheme and supported-color-schemes in your head, accepting that support for those is mostly Apple Mail. Then check it in a forced-inversion client, because that’s where it fails first.

Do media queries work in all email clients?

No. Apple Mail is the only common client with full support. Gmail and the modern Outlooks support them partially, usually enough for basic mobile stacking. Classic desktop Outlook for Windows ignores them entirely and renders at the width you set. Build a base layout that works without them.

Why did my email break after I pasted it into my ESP?

Because your ESP is a rendering step. Platforms like GetCourse, Braze, Mailchimp and Salesforce rewrite links and inject tracking code. Some reformat markup they don’t recognise, including conditional comments. Always run your final test on a send from inside the platform, not on your local file.

Do I need Litmus, or is there a cheaper way to test email rendering?

If you send one email a month, no. Your own devices plus a free tier will cover it. Litmus Core is $500/month, which makes sense at agency volume and not much below it. Mailgun Inspect, formerly Email on Acid, starts at $99/month with 1,000 previews.

Where I’d start tomorrow

Identify the engine, then fix the engine. That handles most email rendering issues. Everything above is just the detail of what each engine does when it’s unhappy.

When somebody hands me a broken template, I don’t open the HTML first. I ask which client, which version, which display scaling. Then: preview pane, or separate window? Four questions, and it’s usually narrowed to one of five engines before I read any code.

Keep a note of which workarounds you’re maintaining and why. That’s the part almost nobody does, and it’s how you eventually know when to stop.

Got a template misbehaving in one specific client and can’t work out why? That’s the kind of thing I’m happy to look at. Send the HTML and a screenshot.