Design approved. Team signed off. You hit send.
Ten minutes later, someone forwards a screenshot from their Outlook inbox – broken layout, oversized images, a two-column block now stacked vertically.
If this sounds familiar, it’s not your team’s fault. It’s Outlook.
The Root Cause
Most email clients – Gmail, Apple Mail, Yahoo — render HTML* using a browser-based engine. CSS* behaves the way web designers expect.
Outlook takes a completely different approach.
Desktop Outlook (2007 through Microsoft 365) uses the Microsoft Word rendering engine*. Word was designed for documents – not the web. It doesn’t recognize many standard CSS properties, and it handles layout according to its own rules.
Unlike Gmail, which understands web standards but picks and chooses what to support, Outlook largely doesn’t recognize them at all. That’s why the same email can fail in both clients for completely different reasons.
That one architectural decision is behind almost every rendering issue teams run into.
5 Ways Outlook Breaks Your Emails
1. Images at the wrong size
Outlook ignores CSS* dimensions on images entirely.
Retina images* – exported at 2x resolution for sharp display – render at their actual file size. One oversized image can push everything else out of position. (Litmus)
The correct approach is to set width and height directly as HTML* attributes on the image tag, not in a stylesheet. It’s a small thing that most design-to-code tools skip.
2. Multi-column layouts fall apart
Outlook has no support for flex box or CSS grid*.
A two-column section that looks clean everywhere else becomes a single vertical column in Outlook. The only layout method that holds up is table-based HTML* – which most modern email builders don’t output. (Email on Acid)
This isn’t a styling problem. It’s a structural one – and it can’t be corrected after the fact with a CSS fix.
3. Unexplained gaps between sections
Thin white or grey lines appear between content blocks – visible only in Outlook, not in any other client.
Outlook injects its own spacing on top of whatever the template specifies, and the behaviour shifts slightly across versions. (Litmus)
Addressing this requires MSO conditional comments* – a block of code written specifically for Outlook that every other client ignores. Standard email builders don’t produce these.
4. Background images become solid colour blocks
CSS background-image* is not supported in desktop Outlook.
The workaround is VML* – a Microsoft markup language that has to be written alongside the CSS, with both versions embedded in the code at the same time. Without it, any section built around a background image falls back to a flat colour. (Email on Acid)
VML is one of the more technical aspects of email development. Very few tools generate it correctly.
5. Brand fonts get replaced
Web fonts* – Google Fonts, Adobe Fonts, custom typefaces – don’t load in Outlook. The client substitutes a system font instead, often without respecting the fallback font* stack the developer specified. (Email on Acid)
Outlook also applies its own line-height defaults, which can shift text spacing independently of anything in the CSS. An email with careful typographic treatment can arrive looking noticeably cruder than intended.
One More Thing: It’s Not One Outlook
Testing against “Outlook” isn’t the same as testing against Outlook.
Desktop versions 2016, 2019, 2021, and 365 each render slightly differently. Outlook for Mac uses a browser engine – much closer to Gmail in behaviour. Outlook on the web is a separate client again.
Sending a test to one person’s machine covers one scenario. Most teams have no visibility into which version the majority of their audience is actually using.
What Actually Helps
The issues above share a common thread: they’re all downstream of template decisions made before a campaign is ever built.
Run pre-send rendering tests.
Tools like Litmus and Email on Acid preview your email across 40+ clients before anything goes out. Finding a layout issue in testing costs far less than finding it after a live send.
Testing surfaces the problem. It doesn’t solve the underlying one.
Use templates built for Outlook from the start.
Table-based layout, hardcoded image dimensions, MSO conditional comments, VML background support – these aren’t things that can be retrofitted. They need to be part of the template’s original structure.
Most teams attempt to patch existing templates. The results are usually inconsistent.
Don’t assume design-to-code exports are email-ready.
Most tools that convert designs into HTML produce browser-grade code. It previews correctly and breaks on delivery. Adjusting the output rarely fixes the root issue – because the output was never designed for Outlook to begin with.
Points two and three are where most teams run out of options without specialist input.
Outlook Is One Piece of a Larger Puzzle
Solving Outlook doesn’t mean your emails render correctly everywhere. Every major client – Gmail, Apple Mail, Samsung Mail, Yahoo — has its own set of constraints. Gmail alone introduces a different category of rendering problems.
Teams that stop firefighting Outlook haven’t found a workaround – they’ve built on templates that handle these constraints before a campaign ever reaches production.
If Outlook is still costing your team time on every send, get in touch. We build email infrastructure designed to hold up across clients – starting with the ones that cause the most damage.
Glossary
HTML – the code that structures your email’s text, layout, images, and links.
CSS – the styling code that controls colours, fonts, spacing, and layout in an email.
Rendering engine – the internal system an email client uses to read and display your email’s code. Different clients use different engines, which is why the same email can look different across inboxes.
Retina images – images exported at twice the standard resolution for sharp display on high-density screens. In Outlook, they display at full file size if dimensions aren’t explicitly set in the HTML.
Flexbox / CSS grid – modern layout tools used in web design that allow flexible, multi-column structures. Not supported in Outlook.
Table-based HTML – an older layout method that builds email structure using rows and columns, similar to a spreadsheet grid. The most reliable approach for email rendering in Outlook.
MSO conditional comments – a code technique that lets developers write Outlook-specific instructions hidden from other email clients. Used to apply fixes that only Outlook needs without affecting other inboxes.
CSS background-image – a standard web property used to set a background image on an element. Not supported in desktop Outlook without a VML fallback.
VML (Vector Markup Language) – a Microsoft-specific markup language required to render background images in desktop Outlook. Needs to be written alongside the CSS and embedded in the template from the start.
Web fonts – custom typefaces loaded from the internet, rather than fonts pre-installed on a device. Not reliably supported in Outlook.
Fallback font – a backup font that displays when the preferred font isn’t supported by the email client.
