I have built over 200 HTML emails at Cvent. I have stared at the same newsletter render broken in Outlook at 11pm while it looked perfect everywhere else. I have written <!--[if mso]> so many times it appears in my dreams. I have done things to a <table> tag that would make a web developer weep.
And I’m here to tell you that email development — real, cross-client, works-in-Outlook-2016-and-Apple-Mail-and-Gmail-and-Yahoo-email-development — is one of the most underrated technical skills in design. It is also, quietly, becoming a lost art.
Most people don’t know it exists. The ones who do usually don’t understand why it has to be so complicated. So let’s fix that. This is the full story of VML, HTML email, and why building compliant emails for every client is genuinely hard — and genuinely worth understanding.
First: Why Is Email HTML So Different?
Before we get to VML, you need to understand the core problem. Email clients are not browsers. They look like browsers. They display HTML. But they do not behave like browsers, and they never agreed to follow the same rules.
Here’s the brutal reality of the email client landscape in 2025:
Apple Mail — 58% market share. Uses WebKit, the same engine as Safari. Broadly standards-compliant. Supports CSS Grid, Flexbox, animations, web fonts, background images, border-radius. If it works in a modern browser, it almost certainly works in Apple Mail. It is a joy to build for.
Gmail — 29% market share. Uses its own sandboxed renderer. Strips <head> styles. Ignores <link> stylesheets. Has improved over the years but still aggressively sanitises your CSS. Building for Gmail means inline styles for almost everything, and accepting that some things simply won’t work.
Outlook desktop (Windows) — around 4% global market share, but often 40–60%+ of your audience if you’re in B2B enterprise. And here is the thing about Outlook: it does not use a browser engine at all. It uses the Microsoft Word rendering engine. The same engine that formats your quarterly reports. Applied to HTML email.
That last point is why everything about Outlook email development feels like fighting the wrong battle. You are not writing HTML for a browser. You are writing HTML for Word. And Word has a completely different mental model for what HTML means.
No CSS background images. No border-radius. No CSS positioning. No max-width. No Flexbox. No Grid. No SVG. No padding on most elements unless you use mso-specific properties. No margin: auto for centering. Tables, nested tables, more tables, and conditional comments everywhere.
This is the world VML was born into.
What Is VML?
VML stands for Vector Markup Language. It was developed by Microsoft in the late 1990s as an XML-based standard for rendering vector graphics — shapes, fills, backgrounds, and drawing elements — inside Internet Explorer and Microsoft Office applications. It predates SVG. It was submitted to the W3C as a web standard and promptly rejected in favour of SVG, which became the actual standard the rest of the web moved to.
The rest of the web moved on. Microsoft Office did not.
Because Outlook uses the Word/Office rendering engine, and because Office never dropped VML support, VML became the only way to do certain things in Outlook that CSS handles trivially everywhere else. Background images. Rounded buttons. Filled shapes. Layered content. Things that take one line of CSS in any browser take 15 lines of VML in Outlook.
Microsoft has made no official announcement about deprecating VML support in Outlook desktop. It is still supported in every Windows version of Outlook that uses the Word engine. Which, as of today, is still most of them.
To use VML in an email, you first have to declare the namespace at the top of your HTML document:
<html xmlns="http://www.w3.org/1999/xhtml"
xmlns:v="urn:schemas-microsoft-com:vml"
xmlns:o="urn:schemas-microsoft-com:office:office"
lang="en">Without that xmlns:v declaration, Outlook won’t recognise a single VML tag. Everything that follows depends on it.
The Conditional Comment System
VML never lives alone. It lives inside conditional comments — a special syntax that targets specific versions of Microsoft software and is completely invisible to every other email client.
The basic structure looks like this:
<!--[if mso]>
This content is ONLY shown in Outlook (all versions)
<![endif]-->
<!--[if !mso]><!-->
This content is HIDDEN from Outlook, shown everywhere else
<!--<![endif]-->You can also target specific versions:
<!--[if mso 16]> Outlook 2007 only <![endif]-->
<!--[if mso 17]> Outlook 2010 only <![endif]-->
<!--[if mso 18]> Outlook 2013 only <![endif]-->
<!--[if mso 19]> Outlook 2016 only <![endif]-->
<!--[if gte mso 9]> Outlook 2007 and above <![endif]-->This system is what allows you to write parallel code — one version for Outlook using VML, one version for everyone else using normal CSS — and have each client see only its own version. It’s ugly. It doubles your code. It is also genuinely clever, and it works.
VML in Practice: The Four Things You Actually Use It For
1. Background Images
Outlook does not support CSS background images on table cells. Full stop. If you want a background image behind content in Outlook, VML is the only way.
Here’s a real-world example — a hero section with a background image that works everywhere:
<!--[if mso]>
<v:rect xmlns:v="urn:schemas-microsoft-com:vml"
fill="true" stroke="false"
style="width:600pt; height:300pt;">
<v:fill type="tile"
src="https://yourdomain.com/hero-bg.jpg"
color="#1a1a2e" />
<v:textbox inset="0,0,0,0">
<![endif]-->
<!-- Your actual HTML content goes here, visible to all clients -->
<table width="600" cellpadding="0" cellspacing="0" border="0">
<tr>
<td align="center" style="padding:60px 40px; background-image: url('https://yourdomain.com/hero-bg.jpg'); background-color:#1a1a2e; background-size:cover;">
<h1 style="color:#ffffff; font-family:Arial,sans-serif;">Hero Headline</h1>
</td>
</tr>
</table>
<!--[if mso]>
</v:textbox>
</v:rect>
<![endif]-->What’s happening here: Outlook reads the VML block, ignores the CSS background-image on the <td>, and renders the VML rectangle with the image fill instead. Every other client reads the CSS background-image, ignores the VML entirely, and renders correctly. Same visual output. Two completely different code paths.
2. Rounded Buttons
CSS border-radius does not work in Outlook. If you want a button that looks like a button — not a rectangle — in Outlook, you need VML. This is the most common VML use case and the one you’ll encounter in almost every professional email template.
<!--[if mso]>
<v:roundrect xmlns:v="urn:schemas-microsoft-com:vml"
xmlns:w="urn:schemas-microsoft-com:office:word"
href="https://yourdomain.com/cta"
style="height:44pt; width:200pt; v-text-anchor:middle;"
arcsize="10%"
fillcolor="#E8431A"
stroke="f">
<w:anchorlock/>
<center style="color:#ffffff; font-family:Arial,sans-serif; font-size:16px; font-weight:bold;">
Get Started
</center>
</v:roundrect>
<![endif]-->
<!--[if !mso]><!-->
<a href="https://yourdomain.com/cta"
style="background-color:#E8431A; border-radius:6px; color:#ffffff; display:inline-block; font-family:Arial,sans-serif; font-size:16px; font-weight:bold; line-height:44px; text-align:center; text-decoration:none; width:200px; -webkit-text-size-adjust:none;">
Get Started
</a>
<!--<![endif]-->Outlook gets the <v:roundrect>. Everyone else gets the styled <a> tag with border-radius. The arcsize="10%" controls how rounded the corners are in VML — it’s a percentage of the shortest dimension, not a pixel value like CSS.
3. Solid Background Colors on the Body
Even something as basic as a full-width background color on the email body can fail in Outlook without VML. The <v:background> element solves this:
<!--[if gte mso 9]>
<v:background xmlns:v="urn:schemas-microsoft-com:vml" fill="t">
<v:fill type="tile" color="#f5f0e8"/>
</v:background>
<![endif]-->Pair this with bgcolor="#f5f0e8" on your <body> tag and you have belt-and-suspenders coverage across every client.
4. Layered Content (Advanced)
Stacking multiple VML layers — a background image layer, a color overlay layer, and a content layer — lets you build hero sections with overlay effects that are fully Outlook-compatible. This is the hardest VML technique and the one most email developers never attempt. It involves multiple nested <v:rect> elements with careful mso-position-horizontal and mso-position-vertical styling to control stacking order.
When it works, it feels like actual magic. When it breaks, it breaks in ways that are genuinely mysterious.
The Full Stack of Email Compliance
VML is just one piece of the puzzle. Building a genuinely compliant HTML email means navigating all of this simultaneously:
Table-based layouts — Forget CSS Grid. Forget Flexbox. Your layout is tables. Nested tables. Tables inside tables inside tables. This is 2003-era HTML structure, deliberately, because it’s the only layout system that works consistently across all clients including Outlook.
Inline styles for Gmail — Gmail strips your <style> block in certain contexts. Every style that matters needs to be inline. This means your clean, readable CSS becomes style="font-family:Arial,sans-serif; font-size:16px; line-height:1.5; color:#333333;" repeated on every single element.
The mso- property family — Microsoft’s proprietary CSS extensions for controlling Outlook-specific behavior. mso-padding-alt, mso-line-height-rule, mso-element, mso-font-alt. None of these exist in the CSS spec. All of them exist in Outlook.
Dark mode — Outlook 365 and iOS Mail both invert colors in dark mode, but not always in predictable ways. Black text becomes white. But background colors may or may not follow. Logos on transparent backgrounds can vanish entirely. You need explicit @media (prefers-color-scheme: dark) overrides, and you need to test them.
Image blocking — Outlook blocks images by default until the user clicks “Download pictures.” Your email needs to communicate even with all images hidden. Alt text on every image. Background colors on image containers. A layout that doesn’t collapse when images disappear.
Web fonts — Supported in Apple Mail and some versions of Outlook.com. Not supported in Outlook desktop, Gmail app, or most email clients. Every font stack needs a robust system font fallback.
Fluid vs fixed width — Desktop emails are typically fixed at 600px wide. Mobile needs to be fluid or responsive. Getting that transition right across clients requires media queries for the clients that support them, and max-width tricks for the ones that don’t.
Why This Knowledge Is Disappearing
Here’s the part that concerns me as someone who has lived in this space for years.
Drag-and-drop email builders — Mailchimp, HubSpot, Klaviyo, Beefree, Stripo — have made it possible to produce serviceable HTML emails without knowing any of this. You pick a template, drag in your content, hit send. For many use cases, that’s entirely sufficient.
But “serviceable” and “compliant” are not the same thing. The templates these builders generate are often bloated, poorly optimised for specific clients, and built to the lowest common denominator. They handle the basics. They rarely handle the edge cases — the enterprise Outlook 2016 user, the aggressive Gmail CSS stripping, the dark mode inversion, the image-blocked inbox.
When you need a custom email — a one-off campaign, a branded experience, something that actually looks like your design and not like a template — the knowledge gap shows up fast. And increasingly, there are fewer developers who know how to bridge it.
I built 200+ Marketo newsletters at Cvent, many of them heavily customised, built from scratch or heavily modified from base templates. The 84% CTR lift we saw on those newsletters wasn’t just from the content — it was from emails that rendered correctly across every inbox, that loaded fast, that worked with images blocked, that looked intentional rather than assembled. That kind of result requires understanding the technical layer most email tooling is trying to abstract away.
The New Outlook — And What It Changes
There is one significant development worth noting. Microsoft has been rolling out a new Outlook for Windows that, unlike its predecessors, uses a Chromium-based rendering engine instead of the Word engine. Once this version becomes the default across enterprise environments, VML will no longer be necessary for the new Outlook.
That transition is already underway — but it is slow. Enterprise environments lag years behind on software updates. Outlook 2016, 2019, and 2021 (all Word-engine based) are still widely deployed. For B2B email — which is most of what people with Marketo and Pardot and HubSpot are sending — the Word engine is still very much your audience’s reality. Conditional comments and VML are not going away soon.
And even when they do, the broader principle doesn’t change: email clients render HTML differently from each other, and building email that works everywhere requires understanding how each client thinks, not just how browsers think.
A Starting Point
If you want to understand this space properly, here’s where I’d start:
Caniemail.com — The email equivalent of caniuse.com. Tells you which CSS properties and HTML features are supported in which email clients. Essential reference.
Litmus — The industry standard for email testing across real clients. Sends your email to actual instances of 90+ email clients and shows you screenshots. Non-negotiable for serious email work.
Email on Acid — Similar to Litmus. Good for testing across clients and catching accessibility issues.
Really Good Emails (reallygoodemails.com) — A curated gallery of well-designed HTML emails. Study the ones that look good and ask what they must have done to achieve that in Outlook.
The Cerberus templates — Open source responsive email templates built with the correct techniques. Good foundation to build from rather than starting from scratch.
Email development is not glamorous. It is table tags and pixel pushing and testing across 15 clients for a layout that took 20 minutes to design and 3 hours to build correctly. It is writing VML fallbacks for things that should take one line of CSS. It is arguing with Outlook about why it thinks a 20px padding should be 14px.
But it is also the kind of knowledge that makes you genuinely valuable in a world of people who assume email just works. It doesn’t. And the people who know how to make it work — really work, everywhere, for everyone — are rarer than they should be.
That’s worth something.
Built emails professionally and have a war story? I’d love to hear it. Find me on LinkedIn — the VML community is small but the trauma is shared.