Why Outlook Still Breaks Your Signature in 2026 (Deep Technical Dive)

The unlikely story of Microsoft Word's rendering engine, the mso-conditional-comment escape hatch, and the specific reasons your signature looks fine everywhere else.

By Engineering Team, Engineers, Gas Alley Studios · Updated 2026-06-28 · 11 min

A working-engineer's explanation of why Microsoft Outlook renders HTML email using Microsoft Word's engine, what that means for your signature, and the specific techniques we use in SignatureCraft to make signatures survive.

The one design decision that shaped twenty years of HTML email

In 2007, Microsoft made a decision that shaped the technical trajectory of HTML email for the next two decades. Outlook 2007 for Windows switched from rendering HTML using Internet Explorer's engine (as it had done since Outlook 2000) to rendering HTML using Microsoft Word's engine. The stated reason was security: Word's HTML rendering was more restrictive and less exploitable than IE's at a moment when email-borne malware was becoming a major concern.

The consequence was that from 2007 onward, the desktop version of Outlook — for years the single most-used business email client on the planet — has rendered HTML email using a codebase originally designed to lay out Word documents. Word's HTML support is essentially a mid-1990s dialect: no proper CSS box model, no float, no flexbox, no grid, unpredictable margin handling, and — the detail that makes email designers cry — background images that require conditional VML markup to render at all.

This decision has been reaffirmed by Microsoft several times since. Outlook 2010, 2013, 2016, 2019, LTSC 2021 and 2024 all use the same Word-derived rendering engine. The web version (Outlook on the Web, or OWA), and the new 'One Outlook' client that Microsoft has been rolling out since 2022, both use much more modern engines — but every corporate Windows install of desktop Outlook, which is still enormous in absolute terms, does not.

What Word's engine actually does to your signature

Six specific behaviours account for the majority of signature breakage in Outlook. First, the Word engine ignores most block-level CSS margins, treating them inconsistently or dropping them entirely. If your signature uses margin: 8px 0 on a paragraph to space out contact lines, Outlook flattens the spacing.

Second, the engine does not support display: block, display: inline-block, or display: flex. Anything that depends on modern CSS layout collapses to Word's default flow behaviour. This is why table-based layout is not an aesthetic preference in email — it is the only layout mechanism that renders consistently.

Third, images are laid out according to Word's image-in-document rules, which include a rendering behaviour where images with no explicit width and height attributes get sized to their intrinsic dimensions at 96 DPI, then scaled to the current display DPI. On a high-DPI monitor, a 200px logo can render as a 400px logo. The fix is explicit width and height attributes on every image, at the target rendered size.

Fourth, background colours applied via CSS to table cells work; background images do not, unless wrapped in a VML conditional block that only Outlook parses. This is the single most obscure workaround in HTML email and the reason banner images in signatures often need duplicate MSO-specific markup.

Fifth, web fonts do not load. Any font-family declaration that is not one of the Word-installed fonts falls back to Times New Roman, regardless of what was intended. This is why signatures set in Google Fonts render fine in Gmail and look broken in Outlook — Outlook cannot fetch the font and cannot use it if it could.

Sixth, and most annoyingly, the Word engine applies its own paragraph-spacing rules to any consecutive text inside a table cell. If you have three lines of contact info stacked in a cell, Outlook will often add roughly 12 points of space between the first and second lines, and none between the second and third, based on rules that only Word's document model understands. The reliable fix is to use br tags rather than paragraph tags, and to explicitly zero margins on any surrounding elements.

The mso-conditional-comment escape hatch

MSO conditional comments are HTML comments that Outlook — and only Outlook — parses as executable markup. They look like an HTML comment beginning with [if mso]. Every other email client and every browser sees them as inert comments; Outlook opens them and runs the contents.

This is the mechanism used to add Outlook-specific fallbacks without polluting the rendering in other clients. If you want a banner image that shows a background image everywhere and a solid colour fallback in Outlook, you wrap the fallback in an [if mso] block and the modern version outside it. If you want to reset the font family for Outlook specifically, you use an MSO-conditional style block. If you want to disable Word's auto-quotation behaviour on a link, you use an MSO-conditional inline style.

The catch is that MSO conditional comments only work in Outlook for Windows. Outlook for Mac uses WebKit and ignores them. Outlook for iOS/Android uses their own renderer and ignores them. Outlook Web ignores them. The mental model that works: MSO conditionals are for desktop-Outlook-only patches, and you should keep the rest of your markup working without them.

How SignatureCraft handles Outlook

Our export pipeline runs every signature through a specific set of Outlook-safety transformations before producing the final HTML. Every image gets explicit width, height, display:block and border=0 attributes, plus a presentation role on wrapping tables to keep screen-reader semantics clean. Fonts are constrained to a set of web-safe families (Arial, Helvetica, Georgia, Verdana, Tahoma, and Calibri) with a fallback chain that guarantees a reasonable render even when the primary font is unavailable.

Colour values are always inline, never in a style block, because Outlook's handling of style blocks is unreliable. Padding is applied on td elements rather than via CSS margin, because Word's box model respects table cell padding more consistently than it respects CSS margin.

For banners and awards — the parts of a signature most likely to include images — we generate both a modern responsive markup path and an MSO-conditional fallback that uses fixed-width table layout and explicit dimensions. The modern path is what Gmail, Apple Mail, iOS Mail and Outlook Web use; the MSO fallback is what desktop Outlook uses.

The final step is validation. Before you export, we run the composed HTML through a small in-browser validator that flags anything known to break in Outlook: unsupported CSS properties, images without dimensions, style blocks that need to be inlined, and font-families outside the safe list. The validator is the one that catches the accidentally-pasted emoji that would render as a broken box in Outlook, or the accidentally-included div where a td was needed.

What Microsoft is doing about this — and why it does not help you yet

Microsoft has been slowly migrating Outlook toward a single, unified codebase — the 'New Outlook' project that started rolling out in earnest during 2022. New Outlook uses the same rendering engine as Outlook Web, which is modern Chromium-based and handles HTML email like any current browser. On the New Outlook, table-based signature workarounds are unnecessary.

The problem is deployment. Enterprise IT departments are slow to migrate off the classic Outlook desktop client, partly because add-ins written against the classic COM API do not work in New Outlook. Microsoft has said repeatedly that classic Outlook will be supported through at least 2029, and internal Microsoft documentation suggests it will be available even longer as an optional install. Any signature you build in 2026 needs to work in classic Outlook for at least the next three years.

The practical implication: build signatures that work in the constrained model, and let the modern clients render the modern subset gracefully. This is not a Microsoft-hostile position — it is just the empirical reality of a client that hundreds of millions of business users still open every day, whose rendering rules were locked in twenty years ago and whose replacement is still on a five-plus-year runway.

Put these tips into practice

• Email Signature Style Guide
• Installation guide and recommended tools
• Signature Grader

Gas Alley Studios engineers build the SignatureCraft editor and export pipeline, and spend an unreasonable amount of time inside Outlook 2016 debugging table layouts.