Email is the only place in digital design where you are still building for a rendering engine from the mid-2000s. It is genuinely annoying, and the annoyance leads people to either ignore it or to design as if it were a web page and then be surprised.
The productive position is the third one: treat the constraints as the brief. A template built for them from the start does not look compromised. It looks like an email that works.
The central fact
Outlook on Windows does not use a browser engine. It renders HTML through Microsoft Word. That single fact explains most of what goes wrong.
Word does not support flexbox or grid. It does not support the background-image property on most elements. It ignores max-width in the places you would want it. It applies its own margins around block elements. It will not respect border radius. Animated GIFs show only their first frame. Padding on anchor elements is unreliable, which means a button styled as a link often has a hit area the size of the text and nothing else.
Depending on your audience, Outlook for Windows can be anything from two per cent of your list to well over a third. For business-to-business senders in particular it is frequently the largest single client. So the first thing to do is look at your own client-share data rather than at an industry average, and set your testing priorities from that.
What this means structurally
It means tables. Not because tables are good, but because a table cell is the one layout primitive every client agrees on. Nested tables for structure, fixed pixel widths on the outer container, and content inside table cells rather than floating in divs.
It means inline styles. Several clients strip or ignore a <style> block, Gmail historically among them, so the reliable approach is styles written on each element, with a style block in the head as a progressive enhancement for clients that do support it. Most email platforms will inline your CSS automatically at send time; check that yours does before relying on it.
It means spacing lives in table cell padding rather than in margins. Word's handling of margin on block elements is its own thing, and fighting it wastes hours. Cell padding behaves predictably everywhere.
It means a single column, most of the time. Multi-column layouts are possible and they degrade acceptably if you build them as tables with a stated width, but the honest observation after enough campaigns is that a single column at around 600 pixels performs as well and breaks in fewer places.
Buttons
A button is where the Outlook problem becomes commercial rather than aesthetic. Style an anchor with padding and a background colour, and in Outlook the padding is ignored, the background collapses to the text, and your call to action becomes a small piece of coloured text that people do not click.
There are two dependable approaches. The first is a table-cell button: a single-cell table with the background colour on the cell, padding on the cell, and the anchor inside it set to display block. The second is a VML-based button, written inside a Microsoft conditional comment so only Outlook sees it, with a standard cell button as the fallback for everything else. It is more code, and it produces a button with correct dimensions and a proper hit area in every major client.
What you should not do is use an image of a button. A meaningful proportion of recipients have images off by default, and a button that is invisible until images load is a button that does not get pressed.
Dark mode
Several clients now apply their own dark treatment to email, and they do not all do it the same way. Apple Mail and Outlook will, in various configurations, invert colours you specified. Gmail on Android does its own thing. You cannot fully control this, and a template that only looks correct in light mode will look broken for a growing share of your list.
Three practices cover most of it. First, avoid pure white backgrounds with pure black text, because the inversion of those is harsh and it is where the ugliest results come from. A warm off-white and a soft near-black invert more gracefully. Second, do not use logos on transparent backgrounds where the artwork is a dark colour, because it will vanish on an inverted background; either place the logo on a solid patch of its own or supply a light variant swapped in via a media query where supported. Third, test with dark mode on as part of the standard pass rather than as an afterthought, because it is easier to design around than to patch.
Gmail clipping
Gmail truncates a message once the HTML passes roughly 102 kilobytes, replacing the remainder with a view entire message link. Most recipients do not click it. If your call to action or your unsubscribe link falls past the cut, you have a conversion problem and potentially a compliance one.
The weight is almost always CSS rather than content. Repeated inline styles add up quickly, comments and generated whitespace add more, and platform tracking code adds some. Keeping the template modular, stripping generated comments, and reusing a small set of styles usually gets a long campaign comfortably under the limit. Check the final weight of the rendered HTML, not the template, since merge tags and tracking are added at send time.
Accessibility, which is also deliverability
Use real text rather than text inside images. It is readable by screen readers, it survives images being blocked, it is searchable, and spam filters treat image-heavy messages with little text less kindly. Write alt text that says what the image conveys. Set the language attribute on the html element so screen readers use the right pronunciation. Keep the contrast between your text and background at accessible ratios, remembering that a dark-mode inversion will change both.
Write the preheader deliberately. It is the line of text that appears after the subject in most inboxes, and left alone it will be filled with whatever your first line of markup happens to contain, which is frequently view this email in your browser. Writing it is thirty seconds of work and it is the second most visible piece of copy in the whole message.
A workable testing matrix
You do not need to test forty clients. For most senders, the list that matters is: Outlook 2016 through Microsoft 365 on Windows, Outlook on macOS, Gmail in the browser, the Gmail apps on iOS and Android, Apple Mail on macOS and iOS, and whichever one your own data shows is unexpectedly large. Test in both light and dark mode, and test with images disabled at least once.
Then send yourself a real message through your actual platform before every campaign. Not a preview render, an actual send. Merge tags, tracking wrappers and link rewriting all happen at that stage, and they are responsible for a decent share of the breakages that a preview tool will never show you.