Microsoft Outlook 2026: What Every Email Sender Needs to Know Before October

What is actually changing in October 2026?

Microsoft is retiring the desktop versions of Outlook that use the Word HTML rendering engine. The timeline has three phases:

Why the Word rendering engine has mattered for 19 years

Microsoft made a technical decision in 2007 that shaped an entire industry: they embedded Microsoft Word as the HTML rendering engine inside Outlook for Windows. The reasoning made a certain kind of sense at the time — Word already handled rich text, so why not use it for email too?

The problem is that Word is a word processor, not a browser. It does not render HTML and CSS the way web standards intend. The result has been 19 years of email developers writing code specifically to work around Word's limitations — code that no other email client needs and that makes templates significantly more complex than they should be.

To illustrate the scale of the problem: a simple email layout that takes 10–20 lines of code to build for all other email clients requires an additional 40–50 lines of code just to make it work in Outlook desktop. That is email code that is 3–4 times more complex and larger purely because of the Word engine.

The specific limitations that have driven this complexity:

• No support for CSS margin and padding on div elements — developers must apply padding to table cells td instead
• No support for div-based layouts — every layout must use HTML tables, an approach deprecated everywhere else since the mid-2010s
• No CSS background images — requires VML (Vector Markup Language), a proprietary Microsoft format from the 1990s
• MSO conditional comments required — <!--[if mso]> blocks to target Outlook-specific code
• 120 DPI scaling issues — Windows users with high DPI displays see broken layouts caused by Word's point-to-pixel upconversion
• Random white lines — caused by Word's rendering of decimal values in the DPI conversion — one of the most frustrating recurring bugs in email development

Every one of these limitations disappears in the new Outlook's Chromium engine.

The dual-Outlook problem: why right now is the hardest period

Here is what makes 2025–2026 uniquely difficult. You are not in a before-and-after scenario. You are in a during scenario — and during is the hardest part.

As of now, you have subscribers using both classic Outlook (Word engine) and new Outlook (Chromium engine) simultaneously. These two versions of Outlook behave fundamentally differently. Code that works in one breaks in the other in specific ways.

The most critical difference: MSO conditional comments. In classic Outlook, these are interpreted and executed — they are how you deliver Outlook-specific fallbacks. In new Outlook, they are treated as regular HTML comments and completely ignored. This is not a bug. It is by design. New Outlook is a web-based Chromium client and does not parse MSO directives.

This means your ghost tables and VML code — which you need for classic Outlook — are harmlessly invisible in new Outlook. New Outlook simply sees your modern HTML and renders it with its Chromium engine. This is actually good news. But it means you need to ensure your modern HTML fallback is solid, because that is what new Outlook users are seeing.

What breaks when you ignore this transition

There are two failure modes — and they affect different audiences.

Failure mode 1: Templates that only work in classic Outlook

If your templates were built Outlook-first — heavy use of table layouts, inline styles only, no modern CSS — they may render correctly in classic Outlook but fail or look degraded in new Outlook. As adoption of new Outlook grows, more of your audience sees a broken email.

What "broken" looks like in new Outlook with Outlook-first templates:

• VML buttons may not render at all — new Outlook ignores VML entirely
• Ghost table padding may produce unexpected spacing
• Table-heavy layouts may render wider or narrower than intended
• Background images set via VML won't appear — the CSS fallback shows instead

Failure mode 2: Templates that only work in modern clients

If your templates were built for Gmail and Apple Mail using modern CSS — flexbox layouts, CSS grid, div-based structure — they may look perfect everywhere except classic Outlook, which a significant portion of your B2B audience still uses.

Classic Outlook with modern-only templates:

• Flexbox and grid layouts collapse entirely — Word engine does not support them
• Background images disappear — no VML fallback means no image
• Margins and padding on div elements are ignored
• Multi-column layouts stack incorrectly or break the design

What finally improves after October 2026

The end of the Word engine is not just a burden to manage — it is a genuine improvement in what email templates can do. Here is what becomes available once your audience has fully migrated to new Outlook:

Cleaner code means smaller file sizes. Smaller file sizes mean better performance and fewer spam triggers. Modern CSS layouts mean more flexibility in design without compromising deliverability. This is a structural improvement for every sender who builds their own templates.

How to code email templates right now — for both engines

The approach for 2025–2026 is progressive enhancement with legacy fallback. Build modern HTML first, add Outlook fallbacks via MSO conditional comments where necessary.

Background images — the correct dual-support approach

This is the most common breaking point. Here is the structure that works in both:

<!-- VML for classic Outlook (Word engine) -->
<!--[if mso]>
<v:rect xmlns:v="urn:schemas-microsoft-com:vml"
  fill="true" stroke="false"
  style="width:600px; height:300px;">
  <v:fill type="tile"
    src="https://example.com/bg.jpg"
    color="#2D6A4F"/>
  <v:textbox inset="0,0,0,0">
<![endif]-->

<!-- Modern CSS for new Outlook + all other clients -->
<div style="background-image:url('https://example.com/bg.jpg');
  background-size:cover; background-color:#2D6A4F;
  width:600px; min-height:300px;">
  Content here
</div>

<!-- Close VML for classic Outlook -->
<!--[if mso]></v:textbox></v:rect><![endif]-->

Layout approach — the current best practice

Use a hybrid approach: table structure for overall layout (classic Outlook requires this), with modern CSS for components that new Outlook can handle cleanly.

• Outer structure: Table-based at 600px max width — works in both engines
• Inner components: Use div elements where possible with CSS fallbacks
• Padding and spacing: Apply to td elements for classic Outlook compatibility, add div padding via MSO conditional comments for new Outlook
• Buttons: Use bulletproof button approach — table cell with background colour, link inside — this works in both engines without VML
• Typography: Specify web font with system font fallback stack — new Outlook renders the web font, classic falls back gracefully

Testing requirement for this period

You must test in both rendering environments before every significant send. Not one or the other — both. Use Litmus or Email on Acid to render in classic Outlook 2016/2019/2021 AND new Outlook simultaneously. A template that passes in Gmail and Apple Mail but fails in classic Outlook is still a broken template if 20% of your list is on enterprise Outlook.

Action plan for enterprise and high-volume senders

Here is what to do in the correct sequence:

The deliverability impact nobody is talking about

Most articles about the Outlook 2026 transition focus on design and rendering. Almost none address the deliverability implications. This is the gap worth understanding.

In 2026, ISPs weight engagement signals more heavily than ever before. Opens, clicks, replies, scroll depth, and deletion speed all feed into inbox placement decisions. The algorithm is not static — it adjusts to individual subscriber behaviour patterns.

A template that renders broken in Outlook produces predictable behaviour: the recipient sees a visually damaged email, concludes it is low quality or spam, and either deletes it without reading or marks it as junk. Either response is a negative engagement signal. Accumulate enough of these signals and inbox placement suffers — not just for that campaign but for subsequent sends.

The transition period — now through late 2026 — is when this risk is highest. You have subscribers on both rendering engines. A template that was thoroughly tested for classic Outlook but not for new Outlook may render correctly for 70% of your audience and broken for the 30% who have migrated. That 30% contributes negative engagement data that affects your overall sender reputation.

The fix is the same as the design fix: dual-support templates, tested in both environments. But the reason to prioritise it is not just design quality — it is inbox placement stability through the transition.