Outlook doesn’t render HTML with a browser engine. Desktop Outlook (2016 and later, still widely used in enterprise) renders email using Microsoft Word’s layout engine, which means CSS you’d never think twice about — flexbox, grid, even basic background-image — silently breaks or gets ignored. Design for that constraint first, then progressively enhance for clients that support more.

Tables, not flexbox or grid

This feels like going backward, and it is — but it’s the layout method every email client reliably supports, because it predates all of them.

<table role="presentation" width="600" cellpadding="0" cellspacing="0" border="0">
  <tr>
    <td style="padding: 24px; background-color: #ffffff;">
      <table role="presentation" width="100%">
        <tr>
          <td width="50%" style="vertical-align: top;">Left column</td>
          <td width="50%" style="vertical-align: top;">Right column</td>
        </tr>
      </table>
    </td>
  </tr>
</table>

role="presentation" tells screen readers to skip the table semantics since you’re using it for layout, not tabular data. Nest tables for multi-column layouts — it’s verbose, and it’s what actually holds together across a 20-year-old rendering engine and a modern one.

Inline every style

Many email clients strip <style> blocks in the <head> entirely, or apply them inconsistently. Inline styles survive everywhere:

<td style="font-family: Arial, sans-serif; font-size: 14px; color: #333333; padding: 16px;">

Write your template with normal CSS during development, then run it through an inliner (juice in Node, or MJML’s build step) before sending — don’t hand-write inline styles on every element, that’s how a template becomes unmaintainable within a month.

Background images need a fallback

Outlook doesn’t render CSS background-image at all. If a background image matters for the design, use Outlook’s VML conditional comments as a fallback, or — much simpler — just don’t depend on a background image for anything the email needs to communicate. Put the image as a real <img> in the flow instead.

<!--[if mso]>
<v:rect fill="true" stroke="false" style="width:600px;">
  <v:fill type="tile" src="bg.png" />
  <v:textbox inset="0,0,0,0">
<![endif]-->
<div>content</div>
<!--[if mso]>
  </v:textbox>
</v:rect>
<![endif]-->

Reach for this only if the design genuinely requires it — most transactional emails don’t, and it’s not worth the fragility for a marketing flourish.

Buttons should be bulletproof, not divs

A <div> styled to look like a button is one of the most commonly broken elements in email — padding and border-radius render inconsistently across clients. Use a real table cell with a background color and generous padding, which every client renders the same way:

<table role="presentation" cellpadding="0" cellspacing="0">
  <tr>
    <td style="background-color: #2563eb; border-radius: 6px;">
      <a href="https://example.com" style="display: block; padding: 12px 24px; color: #ffffff; text-decoration: none; font-weight: bold;">
        Confirm email
      </a>
    </td>
  </tr>
</table>

Test on real clients, not just a browser preview

The gap between “looks right in Chrome” and “renders correctly in Outlook” is the single biggest source of email bugs. A browser preview tells you nothing about Word’s rendering engine, Gmail’s clipping of long emails, or how dark mode auto-inverts your colors on iOS Mail. If you don’t have budget for a paid testing service (Litmus, Email on Acid), the cheap version is: keep a real Outlook desktop install, a Gmail account, and an iPhone around, and send yourself the actual email before every template change ships — not a preview, the real send.

The rule that saves the most pain

Keep the layout simple. One column, generous padding, a single clear call-to-action button built as a table. Every extra layout trick you add is another thing that breaks in Outlook, and the emails that convert best are usually the plainest ones anyway — nobody unsubscribes over unused CSS grid.