Email Client Compatibility

A simulation email only works if it renders the way you designed it. Unlike a web page — which runs in one of a handful of modern browsers — an email is opened in dozens of clients, each with its own rendering engine, and many of them are years behind the web. This guide covers the practical rules for writing email HTML that survives the trip to the inbox. It pairs with Designing Effective Campaigns, which covers the content side.

You write the email body in the HTML code editor in Step 2 of the campaign wizard (see Campaigns §4.2). Everything below is about what HTML/CSS to put there.

31.1 Why email HTML is not web HTML

There is no single “email standard.” Each client decides how much HTML and CSS it supports:

Client / engine	What to expect
Outlook (Windows, 2007–2021)	Renders with Microsoft Word’s engine. No support for `float`, `position`, background images (without workarounds), modern CSS, or reliable `margin`/`padding` on `<div>`. The single most restrictive target.
Outlook 365 / outlook.com / new Outlook	Webview-based, much better — but still strips `<style>` in some contexts and rewrites CSS.
Gmail (web & app)	Good CSS support, but historically strips `<head>`/`<style>` in some views, clips long messages, and proxies images.
Apple Mail (macOS & iOS)	Best-in-class rendering, near-browser. Honors `@media`. Privacy Protection pre-loads images (affecting open tracking).
Mobile webview clients (Gmail/Outlook apps, Samsung Mail)	Variable; assume narrow viewport and inconsistent `@media` support.

The golden rule: design for the worst client your audience uses, then enhance. In a corporate phishing simulation that almost always means desktop Outlook on Windows. If your email works in Outlook, it works almost everywhere.

31.2 Use tables for layout, not `div`s

Modern CSS layout (flexbox, grid, float) does not work in Outlook. The reliable, decades-proven approach is nested HTML tables with a fixed-width content column (typically 600px) centered in a full-width background table.

<!-- Full-width wrapper holds the background; inner table holds the content. -->
<table role="presentation" width="100%" cellpadding="0" cellspacing="0" border="0"
       style="background-color:#f4f4f4;">
  <tr>
    <td align="center" style="padding:24px 12px;">
      <!-- Fixed 600px content column, centered -->
      <table role="presentation" width="600" cellpadding="0" cellspacing="0" border="0"
             style="width:600px; max-width:600px; background-color:#ffffff;">
        <tr>
          <td style="padding:32px; font-family:Arial, sans-serif; font-size:16px;
                     line-height:24px; color:#333333;">
            Hello {{first_name}}, your account requires attention…
          </td>
        </tr>
      </table>
    </td>
  </tr>
</table>

Key points:

Set cellpadding="0" cellspacing="0" border="0" on every table — Outlook adds default spacing otherwise.
role="presentation" tells screen readers the table is for layout, not data.
Put spacing in <td> padding, not margin on inner elements — margin is unreliable in Outlook.
Use the width attribute and a width/max-width style; Outlook reads the attribute, modern clients read the style.

31.3 Inline your CSS

Many clients strip <style> blocks from <head> (Gmail historically does in several views). The safe default is inline styles on each element:

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

Reserve a <style> block in <head> only for things that must use it — chiefly @media rules for responsiveness (§31.5) and :hover states — and treat them as progressive enhancement that some clients will ignore. Never rely on a class defined in <head> for layout that must work everywhere.

Other inline rules:

Use web-safe fonts (Arial, Helvetica, Georgia, Tahoma, Verdana) with a generic fallback. Custom web fonts work only in a few clients.
Always set explicit font-family, font-size, line-height, and color on text cells — don’t inherit.

31.4 Outlook-specific survival kit

The Windows Outlook (Word) engine causes most “it looked fine in my test but broke for half the recipients” problems. Practical defenses:

Bulletproof buttons. A CSS-styled <a> button collapses in Outlook. Use a table-based button, optionally with VML for Outlook:

<table role="presentation" cellpadding="0" cellspacing="0" border="0">
  <tr>
    <td align="center" bgcolor="#0067b8"
        style="border-radius:4px; mso-padding-alt:14px 28px;">
      <a href="{{landing_url}}"
         style="display:inline-block; padding:14px 28px; font-family:Arial,sans-serif;
                font-size:16px; color:#ffffff; text-decoration:none;">
        Verify your account
      </a>
    </td>
  </tr>
</table>

Note mso-padding-alt — an Outlook-only property that restores padding the Word engine drops.

Conditional comments. Target Outlook specifically with  to add fixes (e.g. fixed widths, VML) that other clients ignore.
Avoid background-image on elements — Outlook ignores most of them. Use a solid bgcolor or a real <img> instead.
Image gaps. Outlook adds whitespace under images. Set display:block; and border:0; on every <img>, and font-size:0; line-height:0; on image-only cells.
Don’t rely on border-radius, box-shadow, gradients, or max-width in Outlook — they’re ignored. Treat them as nice-to-have for capable clients.

31.5 Responsiveness: desktop and mobile

Your simulation must be usable on a phone — a large share of recipients read email on mobile first, and a broken mobile layout reads as “fake.”

Start with a single fixed-width column (≤600px) that already looks acceptable on desktop and degrades gracefully — many mobile clients don’t honor @media reliably, so the base layout must stand on its own.

Enhance with @media queries in a <head> <style> block for clients that support them (Apple Mail, most native mobile apps):

<style>
  @media only screen and (max-width:600px) {
    .container { width:100% !important; }
    .stack    { display:block !important; width:100% !important; }
    .mobile-pad { padding:16px !important; }
  }
</style>

Stack columns on mobile. A two-column desktop row should become two full-width stacked blocks on a phone (the .stack pattern above).
Tap targets: make buttons at least ~44px tall and full-width-friendly on mobile.
Font sizes: body text ≥14px (16px is safer); anything smaller is unreadable on a phone and looks suspicious.

31.6 Images

Host images, never embed them. Base64 data: URIs are stripped by Gmail and Outlook. Upload images to the Media Library §10 and reference the hosted URL. (This is also why the platform serves campaign images from a real URL.)
Always include alt text. Many clients block images by default, so the email’s first impression is often images-off. Meaningful alt text on the logo and key images keeps the message coherent — and a good pretext should still read with images disabled.
Set explicit width and height attributes so the layout doesn’t jump while images load and so blocked-image placeholders are correctly sized.
Retina: export images at 2× the displayed size and constrain with width/height for crispness on high-DPI screens.
Don’t build the whole email as one big image — it triggers spam filters, breaks with images off, and isn’t selectable/personalizable.

31.7 Dark mode

Many clients (Apple Mail, Outlook, Gmail app) recolor emails in dark mode, sometimes inverting your backgrounds and text unpredictably.

Don’t assume a white background — a logo that’s dark-on-transparent disappears on a dark background. Use a logo with a safe background or a version that works on both.
Test in dark mode on at least Apple Mail and the Gmail mobile app.
Avoid pure #000000 text on pure #ffffff; slightly off values invert more gracefully.

31.8 Links and preheader

Keep URLs whole. Don’t break a link across lines or insert it as raw text mid-sentence. In PhishSpot you insert the tracked link via {{landing_url}} (see §30.2) — the platform handles the per-recipient key, so you only place the merge tag behind your button or link.
Preheader text — the preview snippet shown in the inbox list — is the first line of body text by default. Add a deliberate, hidden-or-visible preheader near the top so the inbox preview supports your pretext rather than showing “View in browser” or a stray URL:
```
<div style="display:none; max-height:0; overflow:hidden; mso-hide:all;">
  Action required on your account before Friday.
</div>
```

31.9 Test, every time

There is no substitute for seeing the email in real clients:

Send a test email from the campaign (Campaign Actions → Send Test Email) to real inboxes you control — ideally one each of Outlook desktop, Gmail (web + app), and Apple Mail (Mac + iOS).
Check the per-recipient preview in Reports & Analytics §11.5, which renders the exact email each recipient received with a desktop/mobile toggle.
View with images off and in dark mode at least once.

A pre-send rendering checklist:

Layout built with nested tables, fixed ≤600px content column
All CSS that matters is inline; <style> only for @media/:hover
Buttons are table/VML-based (survive Outlook)
Images hosted (no base64), with alt, explicit dimensions, display:block
Renders on desktop and mobile; columns stack; text ≥14px
Looks acceptable with images off and in dark mode
Preheader set; tracked link inserted via {{landing_url}}