How I Build Bulletproof HTML Emails — Without Breaking My Soul

You haven’t truly tested your patience until you’ve coded an HTML email meant to look beautiful in Outlook 2016 and Gmail on iOS — at the same time. For years, I treated email as the annoying cousin of real development. Now? It’s a test of craft, precision, and restraint. I’ve learned to build bulletproof HTML emails that deliver consistently across platforms — and still sleep at night.

Page 1: Accept the Rules (Even the Dumb Ones)

Let’s get one thing straight: HTML email is not the web. It pretends to be, but behind the scenes, it’s held together with 2005-era glue and duct tape. No flexbox. No grid. Limited media queries. And CSS support that varies more than fashion trends.

Instead of fighting that, I accept it. I choose predictable over perfect. Tables over divs. Inline styles over external stylesheets. Because the goal isn’t innovation — it’s reliability.

What I do by default:

  • Use <table> layouts with fixed widths
  • Inline all critical styles
  • Use fallback fonts (e.g., Arial, Georgia)
  • Strip anything experimental unless fully tested
  • Write styles in style="" for each element, not in <style> blocks

The less I assume, the more control I keep. That means managing my expectations — and client expectations too. I tell them early: this won’t behave like their website. But it will reach people where they live: their inbox.

Page 2: My Workflow (Step-by-Step)

Every bulletproof email starts with structure. I don’t design blindly. I sketch first. If the content is complex, I map it into modules — hero, body, CTA, footer. Then I follow this:

  1. Design it simply. I start in Figma or Sketch, but I stay conservative. I avoid full-bleed background images, large SVGs, or hover states that won’t translate.
  2. Slice and prep assets. I export web-optimized images and double-check retina displays.
  3. Code in HTML tables. My base layout is always a centered <table> with nested rows. Margins become padding. Spacing becomes rows. I comment every section.
  4. Style inline. I keep all critical visual cues — font, color, padding, alignment — inline. It might be ugly, but it’s clear.
  5. Test religiously. I run previews in Litmus or Email on Acid, check mobile versions, and test dark mode if needed.

If I’m working with clients, I send screenshots or interactive previews — not just code — so they see what matters: the rendered result, not the source.

Page 3: Common Pitfalls That Break Everything

Even now, some bugs still catch me off guard. Here are two that live rent-free in my brain:

1. Gmail strips <style> in the head

It doesn’t matter if your styles are perfect — if they’re not inline, Gmail (especially on Android) will drop them. This breaks layout, alignment, and type. I solved this by using tools like Premailer or MJML for consistent inlining.

2. Outlook adds spacing to <p> and <div>

Outlook treats <p> tags like block-level boxes with extra margin. Same with <div>. So instead of <p>, I use <td> with style="font-size: 16px; line-height: 24px;" and pad accordingly. Ugly, yes. Stable? Always.

My personal “do not touch” list:

  • No background images with text on top
  • No video embeds (use thumbnails + play icon)
  • No JavaScript or <form> elements
  • No Google Fonts unless base64-encoded with fallbacks

The key? Embrace constraints. Don’t try to outsmart the client. Make the message clear, not clever.

Page 4: Tools, Mental Models & Sanity Savers

Building HTML emails isn’t glamorous. But it can be sustainable — if you use the right tools and mindset.

My Go-To Toolkit:

  • MJML: For writing modern syntax that compiles to bulletproof HTML
  • Litmus / Email on Acid: For rendering tests across 90+ clients
  • Postmark / Mailtrap: For staging and previewing transactional emails
  • Inline Style Generators: Like Premailer to automatically inline CSS

My Mental Rules:

  • If I can’t test it, I won’t ship it
  • Every inbox is a battlefield — don’t assume peace
  • Simple always wins

Some developers scoff at email. I treat it like a craft. It’s where UX, reliability, and accessibility collide. And when done right, it’s the most consistent way to land in your user’s world.

Still thinking it through? Contact me here and I’ll help you get it right.