Pixel-Perfect Email Templates: How to Code Emails That Hold Up in Every Inbox

You send an email. It looks right in your preview. Then a colleague forwards a screenshot from their work laptop: the two-column layout has collapsed into a stack, the button has lost its background color, and your logo is glowing on a black card you never designed.

Every email developer has had that morning. It happens because an HTML email is not one document rendered once. It is one document rendered by dozens of different engines, and each one strips, rewrites or ignores part of your code before a person ever sees it.

That is what people are really after when they search for pixel-perfect email templates. Not identical output everywhere, which no amount of skill can buy, but predictable output: layouts that hold their shape, buttons that stay clickable, and type that stays readable whether the email opens on an iPhone in dark mode or on a locked-down office PC.

The timing matters. On October 13, 2026, Microsoft ended support for Outlook 2021, and a wave of posts declared the Word rendering engine finished. It isn’t. Classic Outlook in Microsoft 365 and Office 2024 still renders email through Word and stays supported until at least 2029, and Microsoft has pushed the default switch to the new Outlook for enterprise customers back to March 2027. This guide covers HTML email template coding for that split reality: what still works, what you can start retiring, and how to decide using your own data instead of a headline.

Key takeaways

• Only Outlook 2021 lost support on October 13, 2026. Classic Outlook in Microsoft 365 and Office 2024 still renders email with Word and is supported until at least 2029.
• New Outlook for Windows renders like a browser and ignores MSO conditional comments, so plan to code for both engines through at least 2027.
• Retire Word-engine fallbacks per audience segment once classic Outlook drops below about 10% of opens, not on a support date.
• Keep the body 600 to 640 pixels wide, inline critical CSS, add role="presentation" to layout tables and build buttons in HTML, never as images.
• Judge template changes on clicks and conversions, because Apple Mail Privacy Protection inflates opens.

What Pixel-Perfect Means for an Email Template

A pixel-perfect email template is one that keeps its layout, hierarchy, brand colors and clickable actions intact in every inbox your audience actually uses, even when individual clients strip styles, resize images or invert colors. In email, pixel-perfect describes controlled degradation, not identical rendering.

The term comes from fixed-width web design, where every element sat exactly where the designer put it. Email never offered that. A two-column layout that looks sharp in Apple Mail can stack unevenly on some Android devices, spacing shifts when Gmail drops certain styles, and a brand color that reads well on white can turn muddy once a dark mode engine gets to it. So the practical test is not whether the email matches the mockup to the pixel. It is three questions: does the structure hold, does the main action still work, and is the copy still readable?

That framing protects your brand too. Readers judge consistency across every touchpoint, which is why consistent visual branding matters as much in the inbox as it does on your site. A template that degrades predictably looks deliberate. One that breaks differently in every client looks careless.

Know Which Inboxes You Are Actually Coding For

Before you optimize anything, look at where your list actually opens mail. Most teams never check, and they end up spending an afternoon fixing a client that accounts for less than one percent of their opens.

The global email client market share picture is lopsided. In September 2026, Litmus tracking of more than 1.5 billion opens put Apple at about 77% of opens and Gmail at about 16%, with desktop Outlook at roughly 3.5% and Outlook.com under 1%. Desktop Outlook is the client behind most rendering complaints in email developer forums, yet it carries a small fraction of the volume.

That ratio should change how you budget your time. If nine in ten opens happen in a WebKit or Blink-based renderer, most of your template already behaves like a normal web page. The heroics are reserved for a minority client.

A few caveats before you act on the global average:

• Your list is not the global average. B2B lists skew heavily toward Outlook and corporate mail servers, and a SaaS list aimed at enterprise IT can show several times the global Outlook share. Pull the client breakdown from your own sending platform before deciding what to ignore.
• Apple’s share is inflated by Mail Privacy Protection. MPP pre-fetches images on Apple’s servers, which registers as an open whether or not a person looked at the message. Treat Apple’s number as a rendering signal, not an engagement signal.
• Monthly figures swing. Apple’s reported share moves sharply from month to month as privacy-affected opens shift, so read the leaderboard as a direction, not a constant.
• Your analytics may not split Outlook versions. Litmus notes that desktop opens from Outlook 2016 and newer share the same identifiers, so it cannot tell those versions apart. Send seed tests to both classic and new Outlook rather than trusting a single Outlook bucket.
• Corporate clients lag consumer clients by years. A regulated-industry list will run older software long after the consumer market has moved on.

Your sending platform decides what analytics you get here, and platforms differ more than their marketing suggests. If you are still choosing one, our comparison of the best email marketing tools breaks down which ones give you usable client-level reporting.

Classic Outlook vs New Outlook: What Changed in October 2026

Since Outlook 2007, the first thing anyone learned about email development was that Outlook for Windows renders HTML through the Microsoft Word engine. Word was built to lay out documents, not web pages. It ignores flexbox, grid and CSS background images, ignores widths and floats on divs, and drops margin and padding in places you would never expect. Almost every strange pattern in email code exists because of it.

Today there are two Outlooks for Windows, and they behave like two different email clients.

Classic Outlook for Windows covers Outlook 2016, 2019 and 2021, Outlook in Office 2024, and the classic desktop app in Microsoft 365. All of them still use the Word engine.

New Outlook for Windows renders through Microsoft Edge WebView2, the same Chromium-based approach behind Outlook on the web, and handles modern CSS the way a browser does. It has been generally available since August 2024 and has already replaced the old Windows Mail and Calendar apps for consumers.

The real support timeline

Outlook version	Rendering engine	Support status as of October 2026
Outlook 2016 and 2019	Microsoft Word	Ended October 14, 2025
Outlook 2021 and Outlook LTSC 2021	Microsoft Word	Ended October 13, 2026
Outlook in Office 2024 and LTSC 2024	Microsoft Word	Supported until October 9, 2029
Classic Outlook in Microsoft 365	Microsoft Word	Supported until at least 2029
New Outlook for Windows	Edge WebView2 (Chromium)	Current, with the enterprise default switch planned for March 2027
Outlook on the web (Outlook.com)	Browser	Current
Outlook for Mac	WebKit	Current

Two facts in that table matter more than the dates. First, end of support is not end of use. Microsoft stops shipping security fixes, but Outlook 2021 keeps opening and keeps rendering your email through Word on every machine where it is still installed. Second, Microsoft states that classic Outlook stays supported until at least 2029 for existing installs and rolls out the new client in three stages: opt-in, opt-out, then cutover. Enterprise tenants were due to reach the opt-out stage in April 2026, and Microsoft has since moved that to March 2027.

What stops working once your audience migrates

The new engine ignores MSO conditional comments. Every fallback you wrapped in <!--[if mso]> becomes invisible to those readers. That is fine, because the problem the fallback compensated for now works natively, but it means you cannot use conditional comments to hide anything from new Outlook.

Ghost tables, VML buttons and VML background images become dead weight in those inboxes. They do not break anything. They just add bytes to a message that Gmail is already measuring against its clipping limit.

What this does not mean

It does not mean you can delete your Outlook workarounds this quarter. Classic Outlook has a supported runway to 2029, Office 2024 installs will sit on corporate desks until then, and the enterprise default switch has already slipped once. Plan for at least two more years of dual-engine coding.

The practical position is progressive enhancement rather than replacement. Code a layout that works without the fallbacks, then layer the MSO fallbacks on top for the audience that still needs them. That is a healthier habit than the one the industry has had since 2007, which was to design everything down to the weakest renderer and call it caution.

How to test classic and new Outlook side by side

You do not need two computers to see both engines. A Windows machine with a Microsoft 365 license covers most of it:

• Use the toggle. Classic Outlook shows a Try the new Outlook switch in the top-right corner, and new Outlook has a matching switch to go back. Open the same test email in each. If the switch is missing, your IT admin has probably hidden it by policy.
• Test classic Outlook at 125% or 150% display scaling. DPI scaling bugs only appear on scaled Windows displays, which is exactly where most office laptops sit.
• Use Outlook.com as a quick proxy for new Outlook. Both render through a web engine, so an Outlook.com seed account catches most new Outlook issues. Treat it as a first pass, not the final check.
• Check your testing platform’s client list. Confirm that new Outlook appears as its own client, separate from Outlook for Microsoft 365. If it does not, your own seed accounts are the only reliable check.

Which Outlook Workarounds to Keep, and When to Retire Them

Not every Outlook fix ages the same way. Some only matter to the Word engine and can go once your classic Outlook share drops. Others are good practice in every client and should stay. Here is how the common ones sort out.

Workaround	What it fixes in classic Outlook	Needed in new Outlook?	Keep or retire
Ghost tables around fluid-hybrid columns	Holds column widths, since Word ignores max-width on divs	No	Retire with your classic Outlook audience
VML rounded-rectangle buttons	Rounded corners and a fully clickable padded button	No	Retire with your classic Outlook audience
VML background images	Background images, which Word will not render from CSS	No	Retire with your classic Outlook audience
MSO font stack override	Stops a fallback to Times New Roman when a web font is declared	No	Retire with your classic Outlook audience
PixelsPerInch set to 96	Stops images and tables scaling on high-DPI Windows displays	No	Retire with your classic Outlook audience
A width attribute on every image	Stops high-resolution images rendering at their native size	Harmless	Keep permanently
role="presentation" on layout tables	Not an Outlook fix: it keeps screen readers from announcing tables	Yes	Keep permanently
Bulletproof HTML buttons instead of image buttons	Buttons that survive image blocking	Yes	Keep permanently

The retire decision should come from your data, not from a support date. A workable rule of thumb: once classic Outlook falls below about 10% of opens for a given audience segment, strip its fallbacks from sends to that segment and keep them in the master template for everyone else. Consumer newsletters will cross that line long before B2B lists aimed at finance, government or healthcare, which may not cross it before 2029.

There is a size argument for doing this per segment as well. Every VML block and ghost table adds weight, and Gmail clipping kicks in at around 102KB. A consumer send that no longer carries Outlook scaffolding has more room for actual content before it gets cut off.

Design and Coding Habits That Keep Templates Stable

Stable templates come from designing for flexibility and coding defensively. Most of the rules below exist because some client will strip, resize or override something, and a responsive HTML email has to survive it without help.

• Structure with tables, constrain with max-width. Tables are still the most reliable layout skeleton across clients. Keep the body between 600 and 640 pixels wide and let it shrink fluidly below that.
• Inline the CSS that matters. Styles that must survive go inline. Keep the style block for media queries, dark mode and enhancements that are allowed to fail.
• Use font stacks that degrade well. Treat web fonts as an enhancement with a system fallback such as Arial or Helvetica, and override the stack for classic Outlook so it never lands on Times New Roman.
• Give every image a width attribute and real alt text. The width attribute keeps classic Outlook from blowing a 2x retina image up to its native size. Alt text keeps the message readable when images are blocked.
• Put the message in the first frame of any GIF. Classic Outlook shows only the first frame, so a GIF whose punchline arrives in frame six shows those readers nothing useful.
• Avoid fixed heights and text inside images. Fixed heights clip text when fonts substitute. Text baked into images disappears when images are blocked and means nothing to a screen reader.
• Lead with the action. Put the primary call to action high in the layout and give it generous white space, especially on 375 pixel phone screens.

Simple, predictable HTML is what makes templates durable across both modern and legacy email clients. The clever work can come later, layered on as an enhancement.

A Starter HTML Email Skeleton You Can Copy

Most rendering bugs are decided in the first 30 lines of the file. This boilerplate bakes in the head settings experienced email developers add by default, so every template you build starts from a stable base.

<!DOCTYPE html>
<html lang="en" xmlns="http://www.w3.org/1999/xhtml" xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office">
<head>
  <meta charset="utf-8">
  <meta name="viewport" content="width=device-width, initial-scale=1">
  <meta name="x-apple-disable-message-reformatting">
  <meta name="color-scheme" content="light dark">
  <meta name="supported-color-schemes" content="light dark">
  <title>Your subject line</title>
  <!--[if mso]>
  <noscript>
    <xml>
      <o:OfficeDocumentSettings>
        <o:PixelsPerInch>96</o:PixelsPerInch>
      </o:OfficeDocumentSettings>
    </xml>
  </noscript>
  <style>
    table, td, p, a, span { font-family: Arial, Helvetica, sans-serif !important; }
  </style>
  <![endif]-->
  <style>
    :root { color-scheme: light dark; }
    body { margin: 0; padding: 0; }
    @media (prefers-color-scheme: dark) {
      .body-bg { background-color: #121212 !important; }
      .body-text { color: #e8e8e8 !important; }
    }
  </style>
</head>
<body class="body-bg" style="margin:0;padding:0;background-color:#ffffff;">
  <div role="article" aria-roledescription="email" aria-label="Your subject line" lang="en">
    <!-- Preheader goes here -->
    <table role="presentation" width="100%" cellpadding="0" cellspacing="0" border="0">
      <tr>
        <td align="center">
          <!--[if mso]><table role="presentation" width="600" cellpadding="0" cellspacing="0" border="0"><tr><td><![endif]-->
          <div style="max-width:600px;margin:0 auto;">
            <!-- Content rows go here -->
          </div>
          <!--[if mso]></td></tr></table><![endif]-->
        </td>
      </tr>
    </table>
  </div>
</body>
</html>

What each part is doing:

• The VML and Office namespaces on the html tag let classic Outlook read the VML button and background code further down the file.
• x-apple-disable-message-reformatting stops Apple Mail from rescaling your layout on its own.
• The color-scheme meta tags tell clients that support them you have planned a dark version. Their limits are covered in the dark mode section below.
• The MSO block fixes DPI scaling and forces a safe font stack in classic Outlook only. New Outlook and every other client ignore it.
• The wrapper div with role="article" gives screen readers a named landmark and carries the lang attribute for correct pronunciation.
• The ghost table around the 600 pixel container keeps classic Outlook from stretching the layout to the full window width.

The Code Patterns That Actually Survive

Four patterns do most of the work. They are unglamorous and they are still correct.

The bulletproof button

Never build a call to action as an image. If images are blocked, and many corporate clients still block them by default, an image button is an invisible button. Build it in HTML with a VML fallback for classic Outlook:

<table role="presentation" cellpadding="0" cellspacing="0" border="0">
  <tr>
    <td align="center" bgcolor="#1a73e8" style="border-radius:6px;">
      <!--[if mso]>
      <v:roundrect xmlns:v="urn:schemas-microsoft-com:vml"
        href="https://example.com" style="height:48px;v-text-anchor:middle;width:220px;"
        arcsize="12%" strokecolor="#1a73e8" fillcolor="#1a73e8">
        <w:anchorlock/>
        <center style="color:#ffffff;font-family:Arial,sans-serif;font-size:16px;">
          Read the guide
        </center>
      </v:roundrect>
      <![endif]-->
      <!--[if !mso]><!-- -->
      <a href="https://example.com"
        style="display:inline-block;padding:14px 28px;font-family:Arial,sans-serif;
        font-size:16px;color:#ffffff;text-decoration:none;border-radius:6px;">
        Read the guide
      </a>
      <!--<![endif]-->
    </td>
  </tr>
</table>

The bgcolor on the cell is deliberate. If every style declaration gets stripped, the recipient still sees a colored block with white text instead of a floating link.

Preheader text

The preheader is the gray line of text the inbox shows beside your subject line. Leave it out and the client grabs whatever comes first in your HTML, which is usually “View this email in your browser.” It is the cheapest open-rate fix available and most teams still miss it:

<div style="display:none;max-height:0;overflow:hidden;mso-hide:all;
  font-size:1px;line-height:1px;color:#ffffff;">
  Three code patterns that stop your emails breaking in Outlook.
  &#847;&zwnj;&nbsp;&#847;&zwnj;&nbsp;&#847;&zwnj;&nbsp;
</div>

The string of invisible characters at the end stops the client from pulling body copy in after your preheader runs out. Write the preheader and the subject line together, as one message split across two lines. Our guide to writing email subject lines that get opened covers the first half of that pairing.

Layout tables that do not confuse screen readers

Every table you use for layout needs role="presentation". Without it, a screen reader announces “table with 3 rows and 2 columns” before reading your content, which turns a newsletter into a data-entry form:

<table role="presentation" width="100%" cellpadding="0" cellspacing="0" border="0">

One attribute. It costs nothing, and it is the difference between an accessible email and a hostile one.

Fluid-hybrid columns

Gmail’s mobile apps strip <style> blocks in some account setups, which takes your media queries with them. The fluid-hybrid approach stacks columns without needing media queries at all, using max-width on a div inside a ghost table:

<!--[if mso]><table role="presentation" width="600"><tr><td width="300"><![endif]-->
<div style="display:inline-block;width:100%;max-width:300px;vertical-align:top;">
  <!-- column content -->
</div>
<!--[if mso]></td><td width="300"><![endif]-->
<div style="display:inline-block;width:100%;max-width:300px;vertical-align:top;">
  <!-- column content -->
</div>
<!--[if mso]></td></tr></table><![endif]-->

Classic Outlook reads the ghost table and holds the two columns side by side. Everything else, new Outlook included, reads the divs and lets them wrap naturally when the viewport narrows.

Check before you assume

Do not trust a blog post about CSS support, including this one. Can I Email maintains support tables for more than 300 HTML and CSS features across every major client, tested and updated by the email developer community. It is the closest thing the field has to a reference standard, and it takes ten seconds to check a property before you ship it.

Dark Mode Is a Rendering Mode, Not a Preference

Dark mode is where most templates fall apart. Litmus reports that more than a quarter of the audience it tracks now reads in dark mode, so this is not an edge case, and clients handle it in three different ways:

• No changes unless you code them. Apple Mail and iOS Mail apply your dark mode styles if you provide them and otherwise leave your design alone.
• Partial inversion. Outlook.com, the Outlook mobile apps and the Gmail app on Android darken light backgrounds and lighten dark text but often leave brand colors and images untouched. That is how you end up with a navy button on a near-black card.
• Full inversion. Classic Outlook on Windows and the Gmail app on iOS rewrite your colors whether you asked or not.

The skeleton above already carries the baseline dark mode CSS. The part worth adding is targeting for Outlook.com and the Outlook apps, which tag dark-mode elements with data-ogsc and data-ogsb attributes you can style directly:

<style>
  @media (prefers-color-scheme: dark) {
    .body-bg { background-color: #121212 !important; }
    .body-text { color: #e8e8e8 !important; }
  }
  [data-ogsb] .body-bg { background-color: #121212 !important; }
  [data-ogsc] .body-text { color: #e8e8e8 !important; }
</style>

Treat the color-scheme meta tag as a hint, not a switch. Can I Email’s September 2026 retest lists it as only partially supported in Apple Mail and Gmail, with Gmail’s mobile apps honoring nothing but the light only value, and unsupported in Outlook and Yahoo Mail. Gmail gives you no dependable CSS hook for its own dark mode, so design the Gmail experience to survive inversion rather than control it.

Three things that trip people up beyond that:

• Transparent PNG logos disappear. A dark logo on a transparent background becomes a dark logo on a dark background. Give logos a solid light background baked into the image, or supply a light variant that only loads in dark mode.
• Pure black is the wrong dark background. Use something near #121212. Pure black with pure white text produces halation that makes body copy harder to read on OLED screens.
• Contrast still has to clear 4.5:1. Inverting a palette does not make it accessible. Mid-gray text that passed on white can fail on dark.

Test dark mode separately from light mode. They are two designs sharing one file, and a template that passes one can fail the other badly.

The Constraints Nobody Warns You About

A template can be perfectly coded and still fail. These four limits catch more campaigns than rendering bugs do.

Gmail clips messages over roughly 102KB. Past that threshold, Gmail truncates the body and shows a “View entire message” link. Your unsubscribe footer ends up behind that link, which is both a conversion problem and a compliance one. The usual culprits are bloated inline CSS, base64-encoded images, unneeded Outlook fallbacks, and tracking parameters repeated across dozens of links. Minify, and move long content to a landing page.

Authentication is no longer optional. Since February 2024, Google and Yahoo have required SPF, DKIM, DMARC alignment, one-click unsubscribe and a spam complaint rate under 0.3% from anyone sending 5,000 or more messages a day. Microsoft applied comparable requirements to Outlook.com, Hotmail and Live addresses from May 5, 2025, and non-compliant mail is rejected outright with a 550 5.7.515 error rather than filtered to junk. No amount of template quality survives a rejection at the gateway.

Images are blocked more often than you think. Many corporate clients still block remote images by default. Every image needs alt text that carries meaning, and no critical information should live only inside an image.

Open rates have been unreliable since 2021. Apple’s Mail Privacy Protection pre-loads tracking pixels whether or not the recipient opened anything, which inflates opens and makes open-based A/B tests close to worthless on Apple-heavy lists. Judge template changes on clicks, click-to-open rate and downstream conversions instead.

That last point has a knock-on effect on measurement. If your email analytics and your site analytics disagree, the fix usually lives on the site side of the stack, and privacy-focused platforms handle email-sourced traffic differently from GA4. Our roundup of Google Analytics alternatives covers which ones report referral traffic from email cleanly.

Tools and Testing: Getting Close to Pixel-Perfect Without Guesswork

Frameworks such as MJML, Maizzle and React Email turn component-style code into the table-heavy HTML that email clients need, which takes most hand-written ghost tables and conditional comments off your plate. Visual builders do the same for teams without a developer, usually at the cost of heavier output. Whichever you use, read the compiled HTML at least once. That is where file weight and forgotten Outlook fallbacks hide.

Testing platforms are the other half. Litmus, now part of Validity Engage, and Email on Acid, whose previews now sit inside Mailgun Inspect, render your template across dozens of real clients, including classic and new Outlook, dark mode and image-blocked views, so you catch problems before subscribers do. Previews are not a substitute for a live send, though. Before any major template change, send to your own seed accounts on a real Gmail app, a real iPhone and a real Windows machine running classic Outlook.

Choosing between all of these is a stack decision more than a feature decision. A builder nobody on the team likes will be bypassed within a quarter. Our martech stack guide to choosing tools that actually get used walks through how to audit and pick without bloating the stack.

AI-assisted builders can now suggest fixes, adjust spacing and rewrite code for better client compatibility, though the output still needs a developer’s eye before it ships. The same shift is reshaping campaign operations more broadly, which we covered in AI-driven campaigns and how automation is changing performance marketing.

Measure templates on clicks, not opens

Reliable templates come from a steady cycle of testing and adjustment. A/B test layouts, button styles and content blocks, but judge the results on clicks, click-to-open rate and conversions, because privacy-inflated opens hide real differences.

Clicks and conversions are also what connect email to acquisition cost, the number leadership actually reads. Email is one of the few channels you own outright, so a template that converts better lowers the cost of every customer it touches. If you are auditing that side of the equation too, we covered it in performance marketing solutions that lower B2B acquisition costs.

Re-run rendering previews whenever a major client ships an update, and watch per-link clicks and the mobile versus desktop split to see where a template underperforms. Email cannot report true scroll depth, since no client runs scripts, so if you want a reading signal, use the read-time estimate from your analytics tool and treat it as approximate.

Rendering is only half the job. The landing page your CTA points to has to carry the same design language and load as fast as the email promised, or you lose the click you just earned. Our guide to the best tools to create landing pages for high-converting campaigns covers the builders that handle that handoff well.

Build It In-House or Buy It

There is a point where hand-coding templates stops being worth the salary hours, and most teams pass it without noticing.

Coding in-house makes sense when you send a small number of layouts on a repeating schedule, when you already have a front-end developer who understands email quirks, and when brand control matters more than turnaround time. Build one modular master template, maintain it, and reuse the blocks.

Buying makes sense when your campaign calendar outpaces your development capacity, when you need consistent quality across a dozen locales or brands, or when you are migrating an entire template library to a new platform. Specialist email template coding services will already have solved the Outlook edge cases you are about to spend a week rediscovering, and they test across client matrices that would cost you a testing platform subscription to replicate. The Outlook split makes that math more pressing: a library that has to carry dual-engine code until at least 2029 costs more to maintain than one built once and audited properly.

The hybrid most mature teams land on is to outsource the master template build and the client testing matrix and keep content assembly in-house. You get engineering rigor where it compounds and speed where it counts. Content assembly is also where personalization lives. Modular blocks let you swap offers, products and copy per segment without touching the layout, which is how behavioral data turns into a personalized customer journey instead of one more batch-and-blast send.

Whichever way you go, ask for the same three things:

• A modular template rather than a single monolithic file.
• A documented client test matrix showing what was checked and where, with classic and new Outlook listed separately.
• Source files you own outright rather than output locked into a vendor’s builder.

Editorial note: Growwwth has no commercial relationship with Email Mavlers. It is named as one example of a specialist email coding team, and the same three checks apply to any vendor you shortlist.

Pre-Send QA Checklist

Run this before every send. It takes about ten minutes and catches most of what goes wrong.

Structure

• Body width between 600 and 640 pixels
• Every layout table carries role="presentation"
• All critical CSS inlined, with a <style> block only for media queries and dark mode
• Every image carries a width attribute
• Total HTML weight under 100KB
• lang attribute set on the html element

Content

• Preheader text written, not left to chance
• Alt text on every image, meaningful rather than a filename
• Primary call to action visible without scrolling on a 375px screen
• Body copy at 16px minimum, 14px absolute floor
• Tap targets at least 44 by 44 pixels
• Text contrast clears 4.5:1 in both light and dark mode
• Any GIF still makes sense as a single first frame

Technical

• All links tested, including the unsubscribe link
• UTM parameters applied and correct
• Plain-text version generated and readable
• SPF, DKIM and DMARC passing for the sending domain
• One-click unsubscribe header present

Rendering

• Previewed in Apple Mail, Gmail web, the Gmail app, classic Outlook and new Outlook
• Checked in dark mode separately
• Checked with images blocked
• Checked at 320px width

The Short Version

Pixel-perfect email templates are less about matching a mockup and more about controlling how a design degrades. The creative side is the branding, layout and hierarchy that make an email feel intentional. The technical side is knowing which engine will render it and coding so each one fails gracefully.

For the next two years, that means coding for two Outlooks at once. Keep the Word-engine fallbacks in your master template, strip them from segments that no longer need them, and recheck your own client-share numbers every quarter rather than letting a support date make the decision for you. The next date worth putting in the calendar is March 2027, when Microsoft plans to make new Outlook the default for enterprise users.

How this guide was checked: support dates come from Microsoft’s lifecycle notices and its new Outlook availability guide, market share figures from the Litmus Email Client Market Share report for September 2026, and feature support from Can I Email’s tables. Last reviewed October 22, 2026.

Quick Answers on Outlook Rendering, Gmail Clipping and Email Width