Email Design Best Practices for Higher Engagement
The constraints that make email design different from web design, and the eleven rules that follow from them.
On this page
The short version
- Email rendering engines are not browsers. Several strip the head, ignore external stylesheets and reset your margins, which is why email design still relies on tables and inline styles.
- Design for the images-off state first. If the email is unreadable without images, a meaningful share of your list receives nothing.
- Single column, around 600px, inline styles, real text for anything that matters. Almost every other rule follows from those four.
Email design looks like web design from twenty years ago because the constraints are from twenty years ago. Outlook on Windows renders with Word's layout engine. Several webmail clients strip the entire head, taking your stylesheet with it. Others rewrite your CSS, block your images by default, or apply their own margins on top of yours.
None of that is going to change, and designing against it is not a matter of taste. The rules below all exist because a specific client does a specific thing.
What breaks, where, and what you do instead
| Constraint | Because | Do this instead |
|---|---|---|
| No external stylesheets | Several clients strip the head entirely | Inline every style that matters |
| No flexbox or grid | Word-based rendering does not support them | Tables for structure |
| Roughly 600px wide | Outlook's reading pane is narrow | One column at 600, fluid below |
| No web fonts, mostly | Support is patchy and silent when absent | A stack ending in a system font |
| No background images alone | Blocked or unsupported in places | A background colour underneath |
| Real text, not text in images | Images are off by default in several clients | Live text with styled markup |
| Explicit image dimensions | Missing sizes collapse the layout | width and height on every img |
The images-off row is the one that costs the most when ignored, because it fails silently — the email looks perfect to the person who built it.
Design the images-off version first
A significant share of recipients see your email with images suppressed, at least on first open. If the headline is baked into a hero graphic and the button is a sliced image, those readers get a stack of empty rectangles and no reason to load anything.
The working method is to design the plain version first — live text, coloured blocks, styled links — and treat images as enhancement layered on top. That inverts the usual order and produces an email that degrades to something readable rather than to nothing.
This is also where alt text stops being an accessibility checkbox and becomes a rendering decision. With images off, your alt text is the design.
One column, always
Multi-column layouts have to collapse on narrow screens, and the mechanisms that do that reliably in a browser are the ones email cannot use. Media queries help in some clients and are ignored in others, which means a two-column design has to be built so that it is acceptable when it does not collapse.
Single column removes the problem rather than managing it. Where you genuinely need side-by-side content — a product grid, a two-up comparison — build it so each cell is wide enough to read at 320px without collapsing, or accept that it will not collapse everywhere.
Type and colour
Web fonts work in some clients and fail invisibly in others, so the font stack has to end in something universally available and the design has to hold up in that fallback. Test with the fallback, not with the font you hope loads.
Body text below about 14px gets scaled up by iOS anyway, which breaks layouts that assumed the smaller size. Start at 16px and let the design breathe rather than fighting a correction the phone is going to apply regardless.
Contrast matters more in email than on the web because you do not control the surrounding background — a client in dark mode may invert your palette, and low-contrast grey on white becomes low-contrast grey on dark. Aim well above the minimum rather than at it.
Before a template ships
- Readable and actionable with images blocked
- Every style that matters is inline
- One column, around 600px, fluid below that
- Buttons are table cells with background colours, not images
- Every image has width, height and alt text
- Body text starts at 16px
- The font stack ends in a system font, and was tested in it
- Rendered in Outlook on Windows, not only in webmail
Frequently asked questions
Can I use a CSS framework or a modern email framework?
Frameworks that compile down to tables and inline styles are fine and save real time. Anything that outputs flexbox or grid and relies on the client to cope will fail in the exact place you cannot afford it, which is Outlook.
How wide should an email be?
Around 600px is the convention because it fits Outlook's reading pane without horizontal scrolling. Some senders go to 640 or 680 successfully; beyond that you are betting on window width.
Do I need a separate mobile version?
No. Build one fluid single-column template that works from 320px upward. A separate mobile version doubles the maintenance and is a common source of the two versions drifting apart.