Why Designing HTML Emails for Outlook Is Still a Nightmare in 2026 (And How to Survive It)

Someone has just handed you a brief. It says: “Design the new company email signature. It needs to look great.” You nod, open your design tool of choice, and produce something clean — maybe a logo, the person’s name in a nice sans-serif, social icons, a promotional banner. It looks good. You hand it over.

Then someone opens it in Outlook 2016 and sends you a screenshot.

This is that story. Why Outlook HTML rendering is the way it is, what specifically breaks, and what you can actually do about it when you’re the person holding the brief.

The original sin: Outlook 2007 and the Word engine

To understand why Outlook is the way it is, you need to go back to 2006. At the time, Outlook 2003 rendered HTML emails using Internet Explorer’s rendering engine — imperfect, but broadly compatible with the kind of HTML web developers were already writing.

Then came Outlook 2007.

Microsoft made a decision that the email development community has not forgiven: they replaced the IE rendering engine with the HTML engine from Microsoft Word. The reasoning, at the time, was to unify the composing and reading experience — Word was already the email editor, so why not use it for display too?

The consequence was immediate and lasting. Word’s HTML engine was built for word-processing documents, not for web pages. It understood a small subset of HTML 4 and a limited slice of CSS Level 1. Flexbox, CSS Grid, background images, many padding and margin properties, most pseudo-classes — all gone. Overnight, Outlook went from being a reasonable email client to one of the most frustrating rendering targets in existence.

That decision has remained in place through Outlook 2010, 2013, 2016, 2019, and right through to classic Outlook as part of Microsoft 365 on Windows. Nearly two decades of the same engine. Every version of Windows Outlook from 2007 to the present has rendered your carefully crafted HTML through something that was never designed for the job.

What this means in practice

If you’re coming from web design, the mental shift required for Outlook-compatible HTML email is significant. Here’s what doesn’t work, or works unreliably, in classic Outlook for Windows:

CSS layout systems. Flexbox and CSS Grid are completely ignored. If your layout depends on either, Outlook will collapse it entirely. The only reliable layout system is nested HTML tables — the approach web designers abandoned around 2005.

Background images via CSS. The background-image CSS property is not supported in desktop Outlook. If you need a background image — say, a branded banner behind your signature — you need to use Microsoft’s VML (Vector Markup Language), wrapped in MSO conditional comments. VML is an XML-based graphics format that predates SVG, was never adopted as a web standard, and exists in Outlook’s rendering world essentially unchanged since the early 2000s.

div widths and heights. Outlook ignores CSS width and height properties on div elements. The container will collapse to fit its text content. Everything needs to be a td inside a table if you want predictable dimensions.

Margin and padding on images. Desktop Outlook strips margin and padding properties applied to images. If you’re relying on margin: 0 auto to centre a logo, it won’t work. You’ll need to wrap the image in a td with align="center" set as an HTML attribute — not CSS.

Animated GIFs. Outlook 2007 through 2016 displays only the first frame. If you use an animated banner in a signature, anyone on those clients will see a static image. Plan your first frame accordingly.

Custom fonts. If you specify a custom web font, Outlook will ignore it entirely and fall back to Times New Roman — not your defined fallback, Times New Roman. To prevent this, you need to structure your font stack carefully and test every fallback scenario.

The hover pseudo-class. No support. Any interactive hover effects you’ve designed don’t exist in Outlook.

DPI scaling chaos. Windows users can set display scaling above 100% for readability. Outlook applies this scaling inconsistently: text and some elements are enlarged, while pixel-based HTML width and height attributes are not. The result is misaligned layouts and oversized text next to undersized images. The fix involves specifying widths both as CSS properties in points and as HTML attributes in pixels — and testing at multiple DPI settings.

The workaround toolkit you’ll need

Designing for Outlook-compatible HTML means building a parallel universe of techniques that exist nowhere else in web development. Here’s what you’ll be reaching for repeatedly.

Tables for everything

Your layout is a table. Columns are table cells. Padding is achieved with empty spacer cells or cellpadding. Nested tables are normal. This isn’t how anyone would choose to write HTML in 2026, but it is the only reliable structural approach for classic Outlook.

Inline CSS (with exceptions)

Most email developers default to inline CSS because some email clients strip <head> styles. For Outlook specifically, inline CSS is generally safer for properties it does support — but there are exceptions. Certain MSO-specific properties only work when placed in a <style> block, and some layout fixes require embedded styles. Test both approaches for each property.

MSO conditional comments

Outlook respects HTML conditional comments — a mechanism originally designed for Internet Explorer version targeting. The syntax looks like this:

<!--[if mso]>
  <table><tr><td>
<![endif]-->
  <!-- Your content here -->
<!--[if mso]>
  </td></tr></table>
<![endif]-->

You’ll use these to wrap Outlook-specific markup that would break other clients, to inject VML for background images, and to target specific Outlook versions with different rendering fixes.

VML for background images

If you need a background image in Outlook, the canonical pattern looks roughly like this:

<!--[if gte mso 9]>
<v:rect xmlns:v="urn:schemas-microsoft-com:vml" fill="true" stroke="false"
  style="width:600px;height:200px;">
  <v:fill type="frame" src="https://example.com/your-image.jpg" color="#ffffff"/>
  <v:textbox inset="0,0,0,0">
<![endif]-->
  <!-- Content visible in all clients -->
<!--[if gte mso 9]>
  </v:textbox>
</v:rect>
<![endif]-->

It’s verbose, it’s brittle, and it requires hardcoded pixel dimensions. But it’s the only way to achieve background images in Windows Outlook.

The mso-line-height-rule property

Line height in Outlook is interpreted differently from every other client. Adding mso-line-height-rule: exactly; before your line-height declaration forces Outlook to use your specified value rather than its own calculation. Without it, vertical spacing will look wrong, especially in signature blocks with multiple lines of text at different sizes.

Signatures are a special kind of painful

Everything above applies to email design generally. For email signatures specifically, the pain is compounded by a few additional constraints.

You don’t control the rendering context. A marketing email is composed and tested by your team. An email signature is rendered inside every individual email sent by every employee, in whatever version of Outlook they happen to have installed, with whatever DPI setting they happen to be using, in whatever compose window state they’re in. You cannot test all of these combinations in advance.

Signature HTML is injected into a compose window, not delivered as a standalone email. This matters because the HTML rendering context inside Outlook’s compose window can behave slightly differently from the reading pane. Something that looks correct in your test send might look different in the compose view that the sender actually sees.

Social icons are a trap. A row of linked social icons — LinkedIn, Twitter/X, Instagram — looks simple. In Outlook, each icon needs to be an <img> inside a <td>, with explicit width and height attributes on the image element itself (not just CSS), and with display: block applied to eliminate the phantom whitespace gap that appears under inline images in some Outlook versions. If you use a single <img> with icons side by side using floats or inline-block, it will break.

Multi-line layouts collapse. A common signature design: logo and name on the left, contact details on the right. This two-column layout requires a two-cell table row, not a flexbox or float-based approach. Even then, you’ll want to set explicit width attributes on both cells, not just CSS widths, and add valign="top" as an HTML attribute to prevent vertical misalignment.

Promotional banners are particularly brittle. If the signature includes a campaign banner — an image with a link, or a text CTA with a background colour — the background colour needs to be set as a bgcolor HTML attribute on the containing td, not just as CSS background-color. CSS background colours are stripped by some Outlook versions.

The light at the end of the tunnel: new Outlook

There is genuine good news, and it’s been a long time coming.

Microsoft’s new Outlook for Windows, available since 2023 and progressively replacing the classic desktop client, abandons the Word rendering engine entirely in favour of a modern web-based engine — the same one that powers Outlook on the web. This means CSS layout, background images, modern fonts, and the rest of the web standards toolkit work as expected.

Outlook for Mac has always used WebKit. Outlook on the web uses a browser engine. It’s only the Windows desktop client — specifically the 2007-through-classic-365 lineage — that’s been stuck with Word.

Classic Outlook for Windows is scheduled for retirement, with Microsoft’s phased rollout already underway. The exact end date for most users hasn’t been firmly announced, but the direction of travel is clear.

In the meantime, a significant portion of the business email population is still on classic Outlook for Windows. According to Litmus email client data, Outlook desktop remains heavily represented in corporate inboxes — which is exactly the audience an email signature is most likely to reach.

Until the transition is complete, the table-based, MSO-conditional-comment, VML-background-image workaround toolkit isn’t going away. But it has an end date. That’s more than could be said a few years ago.

A practical checklist before you hand anything over

Before any Outlook-targeted signature HTML is considered done, verify each of the following:

  • All layout uses <table>, <tr>, <td> — no div-based columns, no flexbox, no float
  • All images have explicit width and height as HTML attributes (not just CSS)
  • All images have display: block to prevent the phantom gap
  • Background colours are set as bgcolor HTML attributes on td elements, in addition to CSS
  • Background images use VML wrapped in MSO conditional comments
  • Custom fonts have a safe fallback that isn’t Times New Roman
  • mso-line-height-rule: exactly is present on any element with a line-height declaration
  • Social icon images are individually wrapped in their own <td>, not floated
  • The design has been tested in at least Outlook 2016 and new Outlook for Windows
  • Animated GIFs have a usable first frame for clients that don’t support animation
  • The layout holds at both 100% and 120% DPI scaling

None of this is elegant. But it works. And once you’ve built a signature template that passes this checklist, it’ll render reliably across the widest possible range of Outlook clients — including the ones your recipients are almost certainly still using.

#email-signatures#outlook#word#rendering