When an HTML Email Looks Perfect—Until You Open Outlook
So the first time I dropped a custom-designed invoice email into production, it looked clean in browser previews, gorgeous in Gmail, and then—totally mangled in Outlook. I’m talking fonts gone rogue, buttons floating in limbo, spacing borked beyond recognition. Lesson learned: no matter how tight your HTML/CSS game is, you’re still at the mercy of antiquated rendering engines.
This is one of the main reasons template libraries exist in the first place. Not to make your email prettier, but to make it survive 15 email clients with 6 layout engines that all disagree on what display:inline-block means. Litmus has a solid testing cloud if you can stomach the price tag, but email template libraries like MJML, Maizzle, and Cerberus do a lot of the heavy lifting upfront so you don’t get wrecked by obscure `
` behavior.
Just remember: testing on real devices still beats your Chrome mobile emulator. I’ve caught padding offsets on actual iPhones that never showed up anywhere else—iOS Mail is particularly good at wrecking percentage-based layouts if you’ve nested tables more than two deep.
Choosing Between MJML, Maizzle, and Foundation for Emails
If you’re coming from a React or Vue world, MJML feels closest to “component-style” logic: use declarative sugar tags like <mj-button> and MJML compiles down into something bloated but compatible. It’s not tiny. But it works. You trade debugging fluidity for compatibility and time saved. It’s amazing until you try to do something non-standard like fixed-width containers beside fluid images—and then you’re knee-deep in generated code trying to override layout with inlined styles.
Maizzle is more for the Tailwind people—use Tailwind to style the logic and post-process with Tailwind-compatible syntax. Maizzle is opinionated but less abstracted than MJML. You can see the final HTML clearly. Editing inline styles isn’t a fight. But if you’re hardcoding layout logic, it’s not point-and-click easy.
Then there’s Foundation for Emails (Zurb). I used this on an old insurance account rollout and immediately hit a weird padding bug where containers ballooned in Apple Mail but stayed perfect in Thunderbird. Zurb uses a combo of media queries and grid trickery that, while stable, can break easily if you try hand-inserting elements mid-template. This isn’t modern Foundation—it behaves more like Flexbox-emulated with nested tables, and if you don’t keep to its conventions, you’ll bleed.
Transactional vs Marketing: Don’t Use the Same Template
This sounds obvious—but I had to unlearn this the hard way. I once reused a beautiful welcome-email template (with footer menus, social links, CTA banners) for order confirmations. Spam rates quietly climbed. Opens dropped. Deliverability tanked.
Why? Different purpose, different expectations. Transactional emails should be dead simple, fast, and emotionally invisible. Think: subject line is “Your payment receipt” and the content is mostly monospace numbers and a quiet logo. If you wrap that in a marketing-colored layout, Gmail and Outlook start flagging it with more suspicion. Not always—just enough to cost you money.
Template libraries like MJML can handle both styles if you segment your components cleanly. But don’t just strip the banner. Learn what’s in line with user trust. Postmark has great minimalist transactional layout patterns, and if in doubt: strip more than you think.
Embedding Fonts Across Clients is Still a Dice Roll
This one drove me nuts for four days: I had a branding mandate where the client insisted on using a Google Font (not system safe). Looked great in Gmail web, broken in Gmail Android, totally ignored by Outlook 2016 (predictably). Even Apple Mail rendered the backup font instead.
Turns out Google Fonts need @import or <link> plus proper fallback stacking, but many email clients strip or ignore either. Embedded base64 fonts? Nope—too large for most inbox limits. best quote of the week came from a Postmark dev on their forum: “If you read every RFC on email and CSS support and think you understand rendering behavior, you’re already wrong.”
There’s no winning this fully. Best practice: always set fallbacks in this order: "Custom Font", -apple-system, BlinkMacSystemFont, "Segoe UI", Roboto, Helvetica, Arial, sans-serif
Also: test your font email in dark mode. Some clients invert your carefully chosen text colors and then poof—gray on gray, unreadable.
Inline vs Embedded vs Linked CSS: What Actually Works?
I spent a solid chunk of 2022 assuming modern clients cared about embedded CSS. Gmail doesn’t. Outlook doesn’t. Apple Mail… sometimes. But most reliable delivery comes from fully inlining CSS. Template libraries know this and pre-inline styles via build steps or compiler logic.
But here’s the catch: if you use MJML or Maizzle’s automated inliner and then try to override with style blocks in specific instances (say, for a campaign-specific color), it may silently fail. Some clients won’t honor that override because the order of parsing means style tags get cut before inline styles get interpreted.
Related oddity: Yahoo Mail doesn’t always respect inlined !important if it’s buried in a template loop. Not documented anywhere. I only spotted it after manually inspecting emails in the Yahoo desktop portal, which is, by the way, a mess of old and new rendering engines stitched together.
Rendering Bugs That Only Show Up on Specific Device-Client Pairs
This isn’t speculation—the following list emerged from actual broken UI situations I’ve personally debugged:
Gmail Android app ignoring left padding inside nested tables
Outlook thickening horizontal rules on Windows 10 high-DPI screens
iOS Mail resizing 2-column MJML layouts to a single column even on tablets
Samsung Email applying twice the line-height to links styled with underlines
Yahoo webmail collapsing footer spacing if you use universal * { margin: 0 }
Thunderbird displaying transparent PNGs with jagged clipped edges
Ditch your assumptions about client support matrices. Most support charts are outdated or incomplete. Just build a small testing macro around sending a basic MJML layout to 5 burner inboxes you check on actual hardware. Because Gmail-for-iOS and Gmail-in-Safari do not behave the same, even with the same account.
Handling Dynamic Data Without Destroying the Template
I built out a Maizzle template last month for a SaaS digest email. Most values were passed from a JSON payload rendered on the server. Everything worked—except when an ampersand showed up in a user’s name. That’s when the whole row broke. Turns out the system wasn’t escaping & in a nested td > span combo, so the result was malformed HTML that curled the layout unexpectedly across some clients.
If you’re building templates that will be used with real user-replaced values:
Always HTML-escape dynamic content, even inside text blocks
Avoid relying on auto-margin logic to push spacing; use padding + spacer tables
Don’t inject image URLs unless you know they’ll be small, hosted over HTTPS, and width-constrained with inline styles
Write guard logic at the content layer: if description field is null or ~empty, drop the block entirely
Put border styles in inline-tagged tables, not container-divs—it survives better
Also, log your final HTML before sending out. More than once, I’ve fixed a “button not clickable” bug that turned out to be malformed closing tags because someone used triple braces in a Handlebars loop.
Template Caching and The Big Surreal Moment
Okay, this one still makes me uneasy. I was testing a mailer with real data and used SendGrid’s dynamic templates. Tweaked the spacing in the base HTML file, redeployed, triggered a new test—and nothing changed. The email was rendering with old styles. I flushed caches, deleted drafts… nada.
Turns out: SendGrid caches the template logic inside their WYSIWYG engine even after you overwrite the template via API, and it only resets if you publish a new version. There was no mention of this in the UI. Only found out via a quiet support post from 2017. That surreal feeling when your current deploy is clearly reverted and nothing makes sense? Welcome to the world of email templating platforms.
In case you’re using Postmark, SES, or Mandrill instead: they all have similar quirks, just harder to find. SES especially will cache DNS settings longer than expected and silently delay rendering updates by reusing DKIM-invalidated bodies. Honestly, log everything and keep a visual snapshot per version.
