Why the same email looks different in Gmail, Outlook, and Apple Mail
Gmail, Outlook desktop, and Apple Mail don't share a rendering engine. One of them literally uses Microsoft Word — and that changes what you should design.
By Norbelys Chirinos, Co-founder
Founder-reviewed ·How we research and correct articles
Send the exact same HTML to three prospects — one on Gmail, one on Outlook, one on Apple Mail — and you haven’t sent the same email three times. You’ve sent three different renders of one file, because none of those three programs interpret HTML and CSS the same way. This isn’t a quirk or a bug. It’s three completely different pieces of software doing the job, and one of them isn’t even a browser.
Three engines, not one standard
“Email client” implies one category of software with small cosmetic differences. In practice, each major client hands your HTML to a different rendering engine, and that engine decides what actually appears on screen.
Gmail runs a Chromium-based web view, Apple Mail runs WebKit — the same engine as Safari — and classic Outlook desktop still renders HTML with Microsoft Word’s document engine, not a browser at all.
That last one is the one that surprises people. For roughly two decades,
Microsoft’s desktop Outlook clients (2007 through current Microsoft 365
builds running in “classic” mode) haven’t used a web rendering engine for
HTML email at all — they hand the message to Word’s document layout engine,
the same one that renders .docx files. Word was never built to interpret
CSS the way a browser does, so it understands a narrow subset: no flexbox,
no CSS grid, no border-radius, no reliable margin/padding on <div>
elements, and background images applied via CSS get stripped outright,
according to Email on Acid’s developer
documentation.
Table-based layout — the thing email developers have joked about for
years — isn’t a stylistic throwback. In Outlook’s Word engine, it’s often
the only layout method that survives intact.
Gmail sits at the other extreme in one respect and a strange middle ground
in another: its webmail and app clients run on a modern Chromium-based view,
but Gmail’s own processing pipeline strips <style> blocks out of the
<head> before rendering, meaning CSS has to be inlined directly on each
element to reliably apply. It also proxies and caches images through
Google’s own servers rather than loading them from your server directly —
a detail that matters for tracking accuracy as much as design.
Apple Mail uses WebKit, the same rendering engine behind Safari — the
closest thing to full browser-grade CSS support of the three, including
native dark-mode remapping, custom @font-face fonts, and modern layout
properties.
Why Outlook’s engine is still relevant in 2026
Microsoft has been rolling out a new Outlook for Windows built on a Chromium-based web engine — the same rendering approach used by Outlook.com — and that transition eliminates most of the Word-engine’s compatibility problems once someone is actually on it. But the rollout is gradual, and trade coverage of the transition notes that the older, Word-engine-based classic clients are expected to remain in real use inside conservative business environments for years past the cutover — the accounts that update software on their own schedule, not Microsoft’s.
That matters specifically for cold outreach, because B2B recipients skew toward exactly the kind of managed, slow-to-upgrade corporate environments where the old engine lingers longest. Designing only for what looks good in your own personal Gmail account means testing against the client your prospects are least likely to be locked into.
| Feature | Gmail | Outlook desktop (classic) | Apple Mail |
|---|---|---|---|
| Rounded corners / shadows | ✓ | — | ✓ |
| Dark mode auto-remap | ✓ | — | ✓ |
| Background images (div/body) | ✓ | — | ✓ |
| Flexbox / CSS grid | — | — | ✓ |
| Custom @font-face fonts | — | — | ✓ |
| Requires table-based layout | — | ✓ | — |
Why “it looks fine on my screen” is the wrong test
The most common way this goes wrong isn’t ignorance of rendering
differences — it’s testing against only one environment. A founder or
sales rep drafting a sequence typically previews it in whatever they
personally use, which skews heavily toward Gmail or Apple Mail simply
because those are the dominant personal-account clients. The recipients of
B2B cold outreach skew the opposite direction: a meaningful share of
corporate accounts still run on Microsoft 365 with policies that keep
classic desktop Outlook in place well past when a consumer would have
upgraded on their own. A message that looks polished on the sender’s own
screen can arrive at its actual target looking structurally broken —
buttons that don’t read as buttons, images with no fallback text, spacing
that collapsed because a <div>’s padding got silently dropped.
What this means for how you design cold email
The practical rule is the one implied by the comparison above: design for the narrowest engine, and let the more capable ones enhance from there — never the reverse. A layout built with CSS grid and background images will degrade badly the moment it hits a Word-engine inbox; a layout built with simple stacked blocks, inline styles, and web-safe fonts renders acceptably everywhere and better wherever the engine supports more.
A few concrete defaults follow directly from the engine differences above:
- Skip CSS background images on
<div>or<body>. They’re silently dropped in classic Outlook. Use an<img>tag with a solid fallback background color instead. - Don’t rely on rounded corners or shadows to signal a button. In the Word engine they render as plain rectangles — make sure the button still reads as clickable with just color and padding.
- Test dark mode assumptions specifically. Apple Mail and Gmail both attempt automatic dark-mode remapping of your colors, which can produce illegible text if you hard-coded a light background with light text assuming it would only ever render as designed.
- Stack single-column instead of laying out side by side with modern CSS. It’s the one layout approach that survives structurally intact across all three engines.
Common questions about email rendering differences
Does this mean I need to design three different emails?
No — the goal is one email that degrades gracefully. Build for the Word engine's limitations first (simple, table-safe, inline-styled), and the Chromium and WebKit engines will render it fine or better without extra work.
How do I know which engine a specific prospect will see?
You generally can't know in advance, which is exactly why designing for the lowest common denominator matters more in cold outreach than in an email you're only sending to your own newsletter subscribers.
Is HTML email even worth the design effort for cold outreach?
For most cold sequences, minimal HTML or plain text reads as more personal and sidesteps rendering risk entirely — heavier design usually pays off more in nurture or newsletter contexts than in first-touch outbound.
Sending the same message reliably, regardless of the engine
None of this is something you should have to track manually per send. Norbelys renders every campaign through the same template and personalization engine regardless of recipient client, and because the platform defaults toward the lightweight, mostly-text formatting that survives every rendering engine intact, you’re not gambling on how a prospect’s inbox happens to interpret your CSS.
If you’re currently maintaining separate HTML variants to compensate for Outlook quirks, that’s exactly the kind of operational overhead a single outreach platform should remove. See how Norbelys handles templating and personalization across every plan, or start sending and let one well-built template do the work across every inbox it lands in.