Get Started

Why Outlook, Gmail, and Apple Mail Render the Same Email Differently

Published

The one email, three inboxes problem

You build an email, it looks perfect in your own inbox, you send it — and then a colleague on Outlook forwards you a screenshot where the buttons are square, the spacing is gone, and a background image simply isn’t there. Nothing changed except the client that opened it.

This is the defining frustration of email development. Unlike a web page, which is rendered by a handful of modern browsers that mostly agree on the rules, an email is rendered by dozens of clients — desktop apps, webmail, and mobile apps — each with its own rendering engine, its own quirks, and its own decades of legacy behavior. The HTML you send is a suggestion. What each client shows is its own interpretation.

Why the clients disagree

The differences come down to which rendering engine sits underneath each client:

ClientRendering engineNotable behavior
Outlook (Windows, 2007–2021)Microsoft WordNo modern CSS layout; needs table-based structure and conditional comments
Outlook (Microsoft 365 / new)Chromium-based (WebView2)Much better, but rolling out unevenly across accounts
Gmail (web + app)Custom, sanitizedStrips <style> in some contexts, clips large emails, ignores many CSS properties
Apple Mail (macOS + iOS)WebKitThe most standards-compliant; supports most modern CSS
Yahoo / AOLCustom webmailIts own sanitizer and class-prefixing rules

The headline issue is desktop Outlook. For over a decade it rendered email using the Microsoft Word HTML engine — not a browser. Word has no concept of float, flexbox, grid, max-width, or background images on a <div>. Ask it to lay out columns with modern CSS and it collapses everything into a single stack or ignores your styles entirely. This single fact is why the entire email industry still builds layouts with <table> elements. (For the full story, see Why HTML Emails Still Use Tables for Layout.)

Gmail is a different kind of adversary. It doesn’t render badly — it sanitizes aggressively. It can strip or rewrite CSS, it ignores properties it considers unsafe, and it famously clips messages larger than ~102KB, hiding the rest behind a “View entire message” link. (More on that in Why Gmail Clips Your Emails.)

Apple Mail, by contrast, is the client email developers wish everything behaved like: it’s built on WebKit and honors most modern CSS, including media queries and even some dark-mode features.

The specific things that break

When an email “looks broken,” it’s usually one of a predictable set of failures:

  • Layout collapse. Multi-column rows built with float or flex stack vertically or overlap in Outlook.
  • Missing spacing. Margin is unreliable across clients; padding on the wrong element gets dropped.
  • Square buttons. border-radius is ignored by older Outlook, so rounded CTAs render as sharp rectangles.
  • Vanished background images. Outlook needs special VML markup to show a background image; plain CSS won’t do it.
  • Font fallback. A web font that loads in Apple Mail silently falls back to a system font in Outlook and Gmail.
  • Broken dark mode. Some clients auto-invert colors, turning a carefully chosen palette into mud. See Dark Mode Email Design.

None of these are bugs in your design. They’re the gaps between what CSS promises and what each client actually implements.

How professionals design around it

There’s no way to make every client render identically, so the goal is graceful consistency: the email should look great where it can and remain readable everywhere else. The techniques are well established:

  1. Build layouts with tables, not div + CSS. Tables are the only structure Outlook lays out predictably.
  2. Inline your CSS. Move styles from a <style> block onto each element’s style attribute, because several clients strip <style>. See CSS Inlining in Email.
  3. Add Outlook conditional comments. These <!--[if mso]> blocks feed Outlook-only markup (like VML backgrounds and bulletproof buttons) that other clients ignore.
  4. Use web-safe font stacks with fallbacks. Specify your preferred font, then a safe system fallback, so text stays on-brand where possible and readable everywhere.
  5. Design mobile-first and let columns stack. Most opens are on phones; a layout that reflows cleanly to one column survives the widest range of clients. See Mobile-First Email Design.
  6. Keep the total size small so Gmail doesn’t clip it.
  7. Test in the real clients, not just your own inbox.

Done by hand, that list is a lot to remember on every single email — and easy to get wrong.

How Temway handles it for you

You don’t have to memorize Outlook’s quirks to ship email that renders everywhere. Temway is a visual, drag-and-drop builder that compiles every design into HTML that renders consistently across clients. You compose with semantic blocks — text, images, buttons, layouts — and Temway outputs the Outlook-safe, responsive HTML that email clients actually need. Outlook-specific workarounds, bulletproof buttons, and responsive column stacking are all handled for you.

The result is that the design you see in the Desktop and Mobile preview is what your readers get — without you hand-writing the fragile markup email clients demand. When the design is ready, export the HTML or push it straight to your ESP. To learn more about the markup language doing the heavy lifting, read What Is MJML?.

Where to go next