Why your emails look broken in Outlook — and what to do about it

The root cause: Outlook uses Word to render emails

This is the detail that surprises most people. While every modern web browser uses a purpose-built HTML rendering engine, Microsoft Outlook — from Outlook 2007 all the way through to recent desktop versions — renders HTML emails using the same engine that powers Microsoft Word.

Think about that for a moment. Word is a word processor designed for printed documents. It has no concept of fluid layouts, viewport widths, or the modern CSS properties that web designers and email designers rely on. When you send an HTML email, Outlook hands it to Word and says "display this" — and Word does its best, which is often not very good.

The result is that a significant portion of your recipients — particularly those in corporate environments where Outlook is the standard — may be seeing something completely different to what you designed.

What Outlook strips out of your email

The list of CSS properties Outlook ignores or mishandles is long. These are the most damaging:

On top of stripping CSS, Outlook can also add unwanted spacing between elements, insert gaps below images, and override font sizes you've explicitly set. It's not being malicious — it's just Word doing what Word does.

Who is actually affected?

It's tempting to assume Outlook is a dying platform. It isn't — particularly in Australian business-to-business contexts. Corporate employees, government departments, and professional services firms overwhelmingly use Outlook as their default email client, and many are on versions that predate the newer Outlook builds which have slightly better rendering.

If your email list includes business recipients — clients, partners, prospects at other companies — there's a strong chance a meaningful percentage of them are opening your emails in Outlook. Sending them a broken layout doesn't just look unprofessional; it signals that you don't pay attention to detail.

The old solution: table-based layouts

For many years, the accepted workaround for Outlook's limitations was to build email layouts entirely using HTML tables — the same approach used to build websites in the late 1990s. Because Outlook's Word engine handles table structure reasonably well, a table-based email would generally hold together across clients.

The downside is that writing table-based HTML email by hand is genuinely painful. The code is verbose, difficult to maintain, and hard to make responsive. A simple two-column layout that takes a few lines of CSS on a webpage can require dozens of nested table tags in an email.

It's a legitimate technique, but it requires specific expertise. Someone who builds websites but has never written email HTML will almost certainly produce something that breaks in Outlook, even if it previews beautifully in a browser.

The modern approach to Outlook-safe emails

Today's best practice for HTML email sits somewhere between the old table-based approach and modern CSS. The goal is to write code that uses contemporary techniques where email clients support them — so your email looks great in Gmail and Apple Mail — while including specific fallbacks and conditional code that Outlook receives instead.

This involves a few techniques that aren't obvious if you haven't worked with email HTML before:

Conditional comments for Outlook

HTML emails can include code wrapped in special conditional comment tags that only Outlook's rendering engine reads. Everything inside those tags is invisible to other email clients, but Outlook processes it. This allows you to serve Outlook a table-based layout while other clients receive a cleaner, more modern version.

Inline CSS

Many email clients — including some versions of Gmail — strip the <style> block from your email's header when displaying it. The safest approach is to write all your CSS inline, directly on each HTML element. This is tedious to write by hand but ensures styles survive the journey into the inbox intact.

Client-specific testing

The only reliable way to know how your email will look is to actually render it across a range of real email clients. What passes in one client may fail in another, and the only way to catch issues before they reach your recipients is to test thoroughly before sending.

What this means in practice

If you're building your own email templates using a drag-and-drop email builder, there's a reasonable chance the tool is handling some of this complexity behind the scenes. The quality varies significantly between platforms, and some handle Outlook compatibility much better than others.

If you're having custom templates built — or if you're working with a developer who isn't specifically familiar with email HTML — it's worth asking directly: has this been tested in Outlook? Which versions? What does it look like on mobile?

A well-built email template should render cleanly in:

• Outlook 2016, 2019, and Microsoft 365 (desktop)
• Gmail (web and mobile app)
• Apple Mail (macOS and iOS)
• Outlook.com and Hotmail (webmail)
• Samsung Mail (common on Android devices)

That's a wide surface area to cover, and it's why email template work takes longer — and requires more care — than a comparable amount of web design work.

Getting it right from the start

The most cost-effective approach is to start with code that's built to be Outlook-compliant. Retrofitting a broken template after the fact is nearly always harder than building it correctly the first time — the fixes often cascade, changing the layout for other clients while trying to fix Outlook.

At Leaf Marketing, every email template we produce is built and tested across all major clients before it's handed over. That includes multiple versions of Outlook, mobile clients, and webmail. We don't consider a template finished until we've confirmed it renders correctly end-to-end — because a beautiful template that breaks in Outlook for 40% of your recipients isn't a template you can rely on.

If you've been sending emails and wondering why some recipients aren't engaging, broken rendering could be part of the story. It's worth taking a look.