CSS in email: which properties survive each client, and what to use instead

Three places your CSS gets read

Support questions sound endless until you split clients into three groups. The first is Outlook for Windows (the desktop versions 2007 to 2019 in caniemail's data), the column with the most "No" answers: it skips many of the layout properties you reach for first and has its own quirks for sizes and line height. The second is Gmail, which does read CSS but filters it. Per the style element entry, Gmail does not support a style element inside the body, caps the style tag at 16 KB, and in the iOS and Android apps does not support it at all for non-Google accounts; the same non-Google-account limit appears on class selectors, @media, object-fit, calc(), clamp() and text-decoration. The third group is everything else: Apple Mail, Outlook.com, Samsung Email and Yahoo accept most things with scattered exceptions.

That grouping gives you the working rule. A property is safe when it is supported in all three groups, "enhancement only" when it is supported in Apple Mail and some others, and off limits when its absence would break the message. The next two tables apply it to the properties that cause most debates.

Fixes for the usual Outlook problems

Outlook's line-height problem is one line to fix. The line-height entry says em and px behave weirdly there and to use mso-line-height-rule:exactly, which every other client ignores:

<td style="font-size:16px; line-height:24px; mso-line-height-rule:exactly; font-family:Arial, Helvetica, sans-serif;">
  Order 4812 shipped today.
</td>

Images need the same belt-and-braces approach. The width attribute entry notes that percentage widths on images are based on the file's physical width in some clients, and the CSS width entry says Outlook ignores it on img. So put the pixel size in the attribute, add the fluid rule in style, and keep display:block to avoid the stray gap under the image:

<img src="https://example.com/img/hero.jpg" width="600" height="300" alt="Autumn range"
     style="display:block; width:100%; max-width:600px; height:auto; border:0;">

Modern CSS: Apple Mail only, so enhancement at best

The features designers ask for after reading a browser changelog share one trait in the data: Apple Mail renders them and most others do not. That makes them useful as progressive enhancement and dangerous as a foundation.

Five ways CSS fails silently

The nastiest email bugs delete rules without a visible error. These are documented in the data rather than folklore:

• Whitespace colour syntax. Per the rgba entry, rgb(0 128 0 / 1) makes Gmail strip the entire style attribute, or the entire style block if it appears there.
• Modern colour spaces. The modern colour entry says that in Gmail one oklch() value removes all inline styles on that element.
• Nesting in Yahoo. The nesting entry records that the nested selectors are removed, so the nested properties apply to the parent selector. A hover rule can end up colouring the whole button.
• !important spacing. The !important entry says Gmail accepts it only in lowercase, Outlook for Windows only with a space before it (and not inline), and Yahoo drops it when there is no space and the rule sets a background image. Write color: #fff !important exactly like that.
• Declaration order in Outlook. The style entry says Outlook for Windows needs a style element declared before its rules are used, which breaks designs that inject CSS late.

/* Do: hex, with a plain fallback line before any enhancement */
color: #1f2937;
background-color: #0a58ca;

/* Don't: whitespace colour syntax. caniemail notes Gmail strips the whole style attribute or style block */
color: rgb(31 41 55 / 1);

/* Don't: lab(), oklch(). Gmail removes every inline style on the element that uses them */
background-color: oklch(55% 0.2 260);

A separate habit worth keeping: write the plain version first, then the enhancement. A hex colour line before a gradient, a fixed pixel size before a clamp, a block level default before a media query. Clients that drop the enhancement fall back to the plain line.

Where to put the CSS

Use both places, each for its own job. Inline holds layout and typography; the head block holds what cannot live inline (pseudo-classes such as hover, media queries, dark-mode rules). The :hover entry shows why you cannot count on interactivity: hover is not supported in Gmail iOS or Outlook for Windows and is partial in Outlook.com. Keep that block short, because of the 16 KB cap, and put it in the head, since Gmail does not read style in the body.

<head>
  <meta charset="utf-8">
  <meta name="viewport" content="width=device-width, initial-scale=1">
  <style>
    /* Keep this block small: Gmail webmail limits it to 16 KB */
    .stack { display: block !important; width: 100% !important; }
    a.cta:hover { background-color: #0848a3 !important; }
  </style>
</head>
<body>
  <!-- Everything that must survive also sits in style="" on the element -->
  <table role="presentation" width="100%" cellspacing="0" cellpadding="0" border="0">
    <tr>
      <td class="stack" width="300" style="width:300px; padding:16px; font-family:Arial, Helvetica, sans-serif; font-size:16px; line-height:24px; color:#333333;">
        Your plan renews on October 21.
      </td>
    </tr>
  </table>
</body>

Which tool writes this CSS for you

A framework, an inliner or a visual builder each takes a different part of the job. The table says what each documents for CSS, nothing more; none of the four documents a promise of identical rendering across clients.

In MJML, the two-block pattern looks like this: one mj-style inlined for rules that must survive, one left in the head for the media query.

<mjml>
  <mj-head>
    <mj-style inline="inline">
      .note { color: #5b6470; }
    </mj-style>
    <mj-style>
      @media (max-width: 480px) { .note { font-size: 14px !important; } }
    </mj-style>
  </mj-head>
  <mj-body>
    <mj-section>
      <mj-column>
        <mj-text css-class="note">Prices include VAT.</mj-text>
      </mj-column>
    </mj-section>
  </mj-body>
</mjml>

With Juice on its own, inlining is a single call, shown in its README. Maizzle wraps the same engine, so the options it lists (such as removing inlined selectors from the style tags, or a safelist to keep selectors) carry over:

import juice from 'juice';

const inlined = juice(sourceHtml); // rules in <style> are copied into style="" attributes

import { inlineCss } from '@maizzle/framework'

const out = inlineCss(html, {
  removeStyleTags: true,
  preferUnitlessValues: true,
})

React Email inlines at render time through its Tailwind component, and its documentation says the component wraps the email content and takes a config object. The preset line is the CSS decision that matters, since it replaces rem with pixels:

import { Tailwind, pixelBasedPreset, Button } from "react-email";

<Tailwind config={{ presets: [pixelBasedPreset] }}>
  <Button href="https://example.com" className="bg-black px-3 py-2 text-white">
    Open the invoice
  </Button>
</Tailwind>

Visual builders such as Stripo and Beefree generate the CSS for you and hand over HTML at export. Whether the export inlines styles or keeps a style block is a question to answer by exporting a real template and reading it, as the builder guide recommends. Rendering services such as Litmus and Email on Acid show the result in clients; the Litmus vs Email on Acid page covers how they count previews, which decides how many CSS iterations a plan can afford.

A CSS test plan that finds these bugs

1. Build four fixtures. One plain-text-heavy transactional email, one image-led promotion, one data table, and one with a button and a hero background. Most CSS regressions show up in one of those four shapes.
2. Add the hostile inputs. A 40-character first name, a missing image, a product title that wraps to three lines, and a right-to-left sample if your list needs one.
3. Check the three groups. Outlook for Windows, Gmail web plus Gmail app with a non-Google account, and Apple Mail or iOS. If all three pass, the others almost always follow.
4. Diff the compiled HTML, not the source. After each tool upgrade, compare the output of the four fixtures; an inliner or framework change shows up as a diff before a subscriber sees it.
5. Re-read caniemail when a client updates. Each feature page shows the date it was last tested, so a gap of years is a reason to check.

For how these limits shape layout, read the responsive email design guide; for colour-mode rules, the dark mode guide; and for the access side, HTML email accessibility.