Engineering·8 min·May 6, 2026

The 5 Outlook quirks that break your HTML email

Tables, VML, inline styles, font fallbacks, and image blocking. Here's how to ship HTML that doesn't fall apart in Outlook.

By The MailHyve TeamLast updated Jun 2, 2026

Every email developer eventually discovers the same uncomfortable truth: Outlook renders your beautiful HTML with Microsoft Word. Not Edge, not Chromium — Word. The engine designed to render document files in 2007, still wired up to your inbox in 2026.

Here are the five Outlook quirks that break the most HTML emails, with the actual fixes that work today.

1. Outlook ignores your divs (and a lot of your CSS)

Word's rendering engine doesn't support most modern CSS layout primitives. Flexbox: no. Grid: no. Even divpositioning is unreliable. Outlook will frequently render a stack of divs as one giant blob with no spacing.

The fix: layout everything in tables. Tables are the only layout primitive Outlook handles consistently. Nest tables for columns, use cellspacing/cellpadding for the spacing CSS would normally give you, and treat the entire email as if it were 2004.

<table role="presentation" cellpadding="0" cellspacing="0" border="0" width="100%">
  <tr>
    <td align="center" style="padding: 24px;">
      <!-- content here -->
    </td>
  </tr>
</table>

Our HTML email generator outputs tables for every layout primitive. The result looks identical in Gmail (which supports modern CSS) and Outlook (which doesn't).

2. Buttons need bulletproof markup

A normal <a class="btn"> styled with CSS works everywhere except Outlook, which strips the styling and shows you a plain blue underlined link. The fix is the "bulletproof button" pattern: a table cell with a background color, an anchor with inline padding, and a small VML block for Outlook to actually render the rounded corners and background.

<table role="presentation" cellpadding="0" cellspacing="0" border="0">
  <tr>
    <td bgcolor="#d4ff3f" style="border-radius: 6px;">
      <a href="https://example.com"
         style="display: inline-block; padding: 12px 28px;
                font-weight: 600; color: #0a0a0a;
                text-decoration: none; border-radius: 6px;
                font-family: Helvetica, Arial, sans-serif;">
        Click me
      </a>
    </td>
  </tr>
</table>

For pixel-perfect Outlook rendering with background, optionally wrap the button in conditional VML — but for most cases the table-cell pattern above is enough.

3. Inline every single style

Outlook supports <style> blocks in the <head>, but Gmail famously does not — Gmail strips the <head> tag entirely when an email lands in the inbox. Combined: any CSS that isn't inline on the element gets ignored by at least one major client.

The fix: inline every style. Use a tool like Juice or Premailer in your build pipeline to convert your source CSS into inline styles, or write inline from the start. Keep a small <style> block only for @media queries that you need for mobile — media queries can't be inlined and Gmail does keep the<style> block in some contexts.

4. Font fallbacks are not optional

Outlook desktop falls back to Times New Roman for almost any non-system font. If you write font-family: Inter; and nothing else, your beautifully designed email turns into a serif document at the recipient's end.

The fix: always end your font stack with a web-safe fallback — and use Helvetica/Arial as the workhorse, not as the third choice.

font-family: 'Inter', Helvetica, Arial, sans-serif;

For headlines specifically, consider Georgia (which renders cleanly in Word) as a serif fallback. The base template in our HTML email generator uses Helvetica/Arial throughout precisely because they render consistently in Word.

5. Images are blocked by default

Outlook desktop, Gmail's clipping previews, and most corporate email systems block images by default until the recipient clicks "show images". If your email is image-heavy or — worse — if your call-to-action is an image, your email is invisible by default.

The fix: three things, in order of importance:

Never put the CTA in an image. Buttons are HTML, always. If the image is blocked, the button still works.
Always include alt text. Outlook displays the alt text in the placeholder, so a well-written alt can carry the message even when the image doesn't load.
Style the alt text. Yes, you can — Outlook honors inline color, font-family, font-size, and font-weight on the <img> tag itself. A blocked image with styled alt text looks intentional, not broken.

<img src="hero.png"
     alt="Annual report — read inside"
     width="600" height="300"
     style="display: block;
            font-family: Helvetica, Arial, sans-serif;
            font-size: 18px; font-weight: 600;
            color: #d4ff3f;"
/>

The Outlook tax

Every email developer pays the Outlook tax: a 20–30% increase in markup size and complexity, just to render correctly in a client that hasn't materially changed since the iPhone launched. Templates like the ones our generator produces absorb that tax once, so you don't pay it on every send.

The trade-off is worth it because Outlook still represents a meaningful chunk of B2B email opens. If your audience is purely B2C and skewed-mobile, you can usually get away with cleaner modern HTML — but for anything that touches enterprise, the table-based, inline- styled, conservatively-fonted approach is what ships.

TL;DR: tables for layout, inline every style, font stacks ending in Helvetica/Arial, buttons as HTML never images, and styled alt text on every image. Do these five things and your email renders correctly in every client that matters.