Email newsletter design: rules that survive real email clients

Design your newsletter for the worst renderer it will meet, which in 2026 is still an email client that lays out HTML with Microsoft Word. Every rule in this article follows from that fact and its cousins: Gmail strips your fonts, dark mode repaints your colors, and a spam filter reads your text-to-image ratio before any human reads your headline.

These rules come from building the Postcard template our composer ships, the same one that sends our own issues (the full story of running a newsletter this way is in our own-domain newsletter guide). We will use its code as the worked example throughout.

One column, 600 pixels wide

Since Outlook 2007, the classic Windows desktop Outlook has rendered HTML email with Microsoft Word's layout engine. Word was built to print documents. It does not know flexbox, it does not know grid, it mangles floats, and it applies its own ideas about margins to anything ambitious. Microsoft's replacement, the Chromium-based new Outlook, becomes the default in stages through 2026, but users and enterprises can revert, and Microsoft's own rollout guidance (published 2024) keeps classic Outlook supported through at least 2029. Plan for Word.

Under Word rules, exactly one layout is safe: a single column of nested tables, capped at a fixed width. The convention is 600 pixels because it fits every preview pane and every phone while staying readable on desktop. Our template does it with a pattern you can copy directly, a ghost table that only Outlook sees wrapped around a max-width div for everyone else:

<!--[if mso | IE]><table role="presentation" align="center" width="600"
  cellpadding="0" cellspacing="0" border="0" style="width:600px"><tr><td><![endif]-->
<div style="max-width:600px;margin:0 auto">
  <!-- the entire issue lives here -->
</div>
<!--[if mso | IE]></td></tr></table><![endif]-->

The single column is not just a compatibility crutch. It is better design for the medium. Readers scroll email vertically on phones, multi-column layouts force zigzag eye movement at 375 pixels wide, and every newsletter we dissected by mechanism ships one column regardless of how much money is behind it. Our own Broadsheet design direction is a good example of the tension: its browser preview does set two justified columns, because on a wide screen that is what sells the newspaper feel, but the thing that survives into an actual send is the masthead and dateline furniture, not the columns.

Design the fallback font first

Webfonts in email work in Apple Mail and iOS Mail, and mostly nowhere else that matters. Gmail ignores @font-face. Word-engine Outlook ignores it too, and is infamous among email developers for occasionally discarding an unfamiliar stack entirely and setting Times New Roman. So the honest way to choose newsletter type is backwards: pick the fallback that most readers will actually see, confirm the design works in it, then let the webfont be a bonus for Apple readers.

Our Postcard template declares two stacks, inline on every element because Word ignores <style> blocks it dislikes:

font-family: 'Instrument Serif', Georgia, 'Times New Roman', serif;     /* display */
font-family: 'DM Sans', -apple-system, 'Segoe UI', Arial, sans-serif;   /* body */

We proofed the whole issue in Georgia before we ever loaded Instrument Serif. Georgia is the design; Instrument Serif is the garnish. Run the same order of operations and two good things happen: your email weighs less for the majority who never fetch the font files, and there is no ugly surprise when a client swaps stacks, because the swap was your starting point.

Dark mode: pick a policy and test it

Dark mode is where finished-looking newsletters go to die. The failure modes are specific. Gmail's apps apply a full color inversion to light emails, so an ivory background becomes near-black and carefully chosen ink colors get recalculated into something you never approved. Outlook's apps invert partially, which can land brand colors on backgrounds they were never tested against. Transparent dark logos vanish. Baked-in white image backgrounds glow like a torch on an otherwise dark card.

You have two defensible policies. Design a true dark variant and control the swap with prefers-color-scheme, accepting that support is patchy. Or pin your email to light and accept that dark-mode readers get a bright card. We chose the pin for the Postcard template, because its whole identity is paper:

<meta name="color-scheme" content="light">
<meta name="supported-color-schemes" content="light">

Two mitigations help under either policy. Avoid pure white text and pure black backgrounds in your palette, since inversion math treats extremes worst. And give logos a few pixels of padding on a rendered background instead of full transparency.

Keep the 60:40 text-to-image floor

Our deliverability playbook enforces a floor of roughly 60 percent text to 40 percent image, and never image-only, on every send. This rule is not aesthetic. Spam filters have read image-heavy mail as evasion for two decades, because embedding your pitch in a JPEG was historically how you hid it from text scanners, and mail from a domain without a DMARC record and a clean sending history gets even less benefit of the doubt. The rest of our sending rules live in the deliverability handbook; the design-relevant part is simply that a beautiful all-image issue is a spam-folder application.

The floor is also an accessibility rule wearing a deliverability coat. Images off is still a real reading mode, corporate gateways still strip remote content, and a screen reader gets nothing from a JPEG of your headline. Our template keeps every headline, every link, and the entire footer as real text; images carry mood, alt text carries meaning when they fail to load.

Button math

A button in email is a bordered table cell with a padded link inside it, because background images and CSS-only buttons both fail in Word-engine Outlook. Here is ours, from the shipped template:

<td style="border:1.5px solid #8E4A18;border-radius:999px;background-color:#FBF7EE">
  <a href="{url}" style="display:inline-block;font-family:'DM Sans',Arial,sans-serif;
     font-size:14px;font-weight:600;color:#8E4A18;padding:12px 26px;
     text-decoration:none">Read the story &rsaquo;</a>
</td>

The numbers are doing arithmetic, not decoration. A 14 pixel label with 12 pixels of padding above and below, inside a 1.5 pixel border, renders a touch target a shade over 44 pixels tall. Apple's Human Interface Guidelines set 44 by 44 points as the minimum comfortable tap target, and thumbs do not care that this is email instead of an app.

When to use a button versus a text link is a hierarchy question with a blunt answer: one button per issue, for the single action the issue exists to cause. Everything else is an underlined text link in the running copy. Our Postcard direction enforces this shape structurally, one lead story with the only button, then a linked list of secondary items as plain text rows. Two buttons split attention; five buttons are a navigation bar pretending to be an email.

The plain-text part is a design artifact

Every send from our composer is multipart/alternative: an HTML part and a plain-text part in the same message, with the receiving client choosing. Most tools autogenerate the text part by crudely stripping tags, which produces the familiar soup of orphaned URLs and broken spacing. We treat it as a second rendering target. Our renderer builds the text part line by line, in the same pass as the HTML, with its own layout decisions:

YOURNAME  |  The Sunday Dispatch  |  August 7, 2026

FRESH THIS WEEK: The fall line
The fall line arrives in wool and waxed canvas, cut for long winters.
https://yourdomain.com/the-fall-line

ALSO THIS WEEK
- Why we still proof on paper
  https://yourdomain.com/proof-on-paper

- - -
Unsubscribe in one click: https://yourdomain.com/unsubscribe?token=...

Capitalized section labels stand in for headline type. Indentation stands in for card layout. The unsubscribe link is right there in the text, per recipient. Filters read the text part, some readers genuinely prefer it, and a well-set text part is the difference between multipart as a checkbox and multipart as a courtesy. The longer argument is in our piece on plain text vs HTML email.

Stay under Gmail's clip

Gmail truncates messages whose raw HTML exceeds roughly 102KB, replacing the remainder with a "View entire message" link, a threshold documented for years by Litmus and Email on Acid. Clipping hides your footer, and your footer is where the unsubscribe link lives, which turns a design problem into a deliverability problem: a reader who cannot find unsubscribe finds the spam button instead.

The weight budget is a design constraint like any other. Inline styles are verbose, so unused styling costs real bytes; every tracking parameter lengthens every URL; a 40-section mega-issue may need to become a summary that links out. Aim under 90KB of HTML to leave margin. Images do not count against the clip (they load separately), but they count against patience on cellular, so our template ships fixed-dimension, compressed images from our own domain with alt text on each.

The worked example: our Postcard template, annotated

Here is every rule above, as the shipped template applies it:

The footer row deserves its sentence: alongside the visible links, every campaign leaves with RFC 8058 one-click unsubscribe headers stamped on the message itself, so the reader's mail client can offer unsubscribe at the top without the reader hunting for it.

Before your next issue ships, run the five-minute version of this article: send a test to a Gmail account with dark mode on, read it once with images off, read the plain-text part on its own, tap the button with a thumb, and check the raw size against 90KB. Any issue that passes all five is designed for email as it actually exists.