---

There are email developers all around the world with a few extra gray hairs and wrinkles thanks to challenges that Microsoft Outlook causes us. But take heart my friends! There may be an end to the nightmare of coding emails for desktop versions of Outlook.

Last year, Microsoft announced it plans to release a new Outlook for Windows. The announcement was mainly geared toward Outlook users, and it invited beta testers to start playing around with the updated version. However, there was a line added to the article that was music to the ears of email geeks:

“Today, we are taking our next step by sharing a preview of the new Outlook for Windows, designed to bring consistency across our Windows and web codebases...”

Margie Clinton, Microsoft 365 Insider article

The key word in that quotation above is “consistency.” So, why is that such a big deal? We’ll explain.

Why Outlook for Windows is a huge headache

If you’ve been in the email marketing world for a while, you’re probably aware of the biggest challenge for those who code campaigns: email clients do not render HTML and CSS consistently.

There are varying levels of support for certain forms of HTML and CSS. That means the way something looks on Gmail may look quite different in Yahoo Mail. To see just how complicated this can get for email developers, check out the website CanIEmail.com and compare support among email clients.

The biggest culprit of all has been the desktop versions of Outlook (for Windows 2003 – 2019). That’s why our tongue-in-cheek article on email client stereotypes labeled Outlook “The Troublemaker.”

The main reason for all that trouble is that Outlook for Windows has been using Microsoft Word as its rendering engine for years. And if you think it seems odd to use a word processor to render email code, you’re not wrong. To learn more about this, check out Rémi Parmentier’s post on the current Outlook rendering engine.

It’s likely that Outlook users make up a much smaller percentage of your list in comparison to mailbox providers like Gmail and Apple Mail. But it’s an important email client for B2B brands and big enough that B2C senders can’t ignore it either.

Outlook coding issues are such a big problem that they majorly influence the way we develop emails. Hussein Al Hammad explained why in a post for the Email Markup Consortium (EMC):

“Given the wide use of Outlook for Windows globally, email developers stuck with patterns only needed to ensure their HTML emails render well on Outlook for Windows. Because these patterns are not needed for emails to render well elsewhere, it’s an Outlook-first approach and not a user-first one.”

~ Hussein Al Hammad, Email Markup Consortium

The fact that we’ve often had to code what works for in Outlook rather than what’s best for subscribers has been a bummer – to say the least. But that could change as people and businesses adopt the new Outlook for windows.

What to expect from the new Outlook for Windows

When Microsoft stated that it was going to “bring consistency across our Windows and web codebases,” it signaled that the new desktop version of Outlook would render code in the same way as web-based versions of Outlook.

That means the new Outlook for Windows would use a web-based rendering engine just like most other clients do. So, there will be more support for HTML and CSS, which will solve quite a few problems for email developers. Here are some of the biggest changes to expect:

1. No more using tables to code emails

Once the desktop versions of Outlook are finally laid to rest, the need to use tables to code email layouts will no longer be a necessity. The primary reason email developers have been doing that is because of Outlook and its Word rendering engine.

Tables provided the best way to effectively size and position email elements in Outlook for Windows. But they also created a lot of extra work for email coders who may prefer to use <div>s instead. Unfortunately, since Outlook ignores inline styling, we can’t style <div>s with CSS.

The good news is, with the new Outlook for Windows and its web-based rendering engine, we can expect fewer broken layouts and the ability to use more CSS. It would also mean the end of using ghost tables to fix Outlook alignment issues.

2. Coding margin and padding gets easier

Among the many problems Outlook caused for email coding, issues with spacing were some of the most frustrating.

For starters, with the exception of Outlook 2003, developers are unable to use CSS properties like “margin” or “padding” in code for the other desktop versions. Outlook removes padding in some situations. That can include image padding, which when ignored may cause text to appear flush against an email graphic.

Since the margin and padding CSS properties have better support in Outlook web and mobile applications, it’s safe to assume that we’ll be able to use them for the new Outlook for Windows.

3. Support for CSS background images

Because Outlook.com and Outlook 365 use a web-based rendering engine, CSS background images are no problem at all. But it’s been a different story for the desktop versions. While Outlook does support the background-color property, email developers have been forced to use table background image attributes instead of the CSS property background-image.

The other option has been to use vector markup language (VML) for background images in Outlook emails.

Once the new Outlook for Windows replaces its outdated ancestors, we’ll be able to size and position email backgrounds and use larger images for retina displays.

4. Fewer conditional statements in emails

When email developers want to include code that is only for certain versions of Outlook, or they want to hide content from Outlook subscribers (because it won’t work), conditional statements have done the trick.

As the current desktop versions fade away and make room for a new Outlook for windows, email coding won’t require as many of those <!--if [mso]> statements. In fact, this is something to keep in mind as things progress, because you’ll want to remove those MSO conditional statements to simplify your code and reduce bloat.

What does this mean for the future of email coding and testing?

There are many other rendering issues that may disappear along with adoption of the new Outlook for Windows. But don’t get too excited just yet. First, businesses and email users will need to update their versions of Outlook. And it should come as no surprise that this won’t happen automatically. After all, that’s why we’re still making sure emails look okay in Outlook 2010 right now.

The date to mark on your calendars is October 2026. That’s when Microsoft says it will officially end its support for desktop versions that use the Word rendering engine. Once that happens, those who are slow to adopt will have to start using the new Outlook for Windows.

Since its earliest days, Sinch Email on Acid has taken on the mission of simplifying the complexities of email development. We’ve done that by providing email testing tools including email previews that show you how your campaigns render on dozens of clients and live devices.

Of course, finding and fixing Outlook issues before hitting “send” are among the biggest reasons people use our platform. But the truth is, we’re excited that this change is coming. Just like everyone involved with the EMC, we believe that the email industry needs defined standards, and this is a big step in the right direction.

In the meantime, desktop versions of Outlook will live on, and other email coding and design challenges such as dark mode and accessibility will still need to be addressed. So, if you’re ready to start putting your best email forward, give Email on Acid a try.