Email Design Best Practices for Marketing and CRM Teams

Most guides to email design read as if every email were designed from scratch, by a designer, with time. If your team sends every week, that isn’t your situation. The tenth campaign of the quarter is assembled by a busy marketer on a Thursday afternoon, and it will be read on a phone, in a client nobody tested, with images switched off.

The useful question for a team like that is which decisions to make once, in the template, and which to check on every send. This guide is organised that way. The first half is what to settle in the template, with the numbers that matter. Then a short section on rendering, because that is where most surprises come from. Then what to check each time, with a checklist at the end.

Decide these once, in the template

Width and columns

Build on a single column 600 to 640 pixels wide. It has been the convention for years because it fits the preview pane in desktop clients and scales down to a phone without anything clever. Two-column modules (a pair of products, an image beside its text) are fine as long as they stack on small screens in an order that still makes sense when the right-hand column drops below the left. Decide that stacking order in the template, not per campaign.

Type

Use live text for every word that matters: headlines, body copy, prices, dates and the button label. Text in an image can’t be read by a screen reader, scales badly on a phone and vanishes when images are blocked. Set a font stack with web-safe fallbacks (your brand font, then Arial or Georgia, then the generic family), because Gmail and most versions of Outlook ignore web fonts.

Body text at 16 pixels, or 14 at the very least, with a line height around 1.5. Headlines large enough to be headlines, which usually means 24 pixels or more, so the gap between a heading and its body is obvious at a glance. For contrast, WCAG asks for at least 4.5:1 between text and its background, and 3:1 for large text (24 pixels, or 18.5 pixels bold). Grey-on-grey subheadings are the usual offender.

Colour and dark mode

Dark mode is the one area with no single right answer, because clients do different things with your colours. Some leave them alone, some invert light backgrounds and keep the rest, and Outlook on Windows recolours the whole email its own way. Design so the email survives all of them. Give logos and icons padding and a safe edge, since a transparent PNG with dark text disappears on a dark background. Use a very dark grey rather than pure black for text, because inverted it becomes white on black, which is harsh to read. Check your brand colours after inversion, especially pale tints, and put a visible border on any button whose fill could blend into the new background.

Buttons

Code buttons as HTML and CSS (a padded table cell with a background colour and a link), never as an image, so they render with images off and the label stays live text. Make them easy to hit. WCAG’s minimum target is 24 by 24 CSS pixels, and most teams go well past that, to around 44 pixels tall, because thumbs are not precise. Leave at least a line of space around a button so it isn’t tapped by accident on the way to the link above it. And give the button’s label a character limit in the template, so “Shop the autumn edit now while stocks last” can’t wrap onto three lines.

Images

Set width and height in the HTML so the layout doesn’t jump as images load. Export at twice the display width for high-density screens, then compress hard and check the result still looks fine. Give every meaningful image alt text written for this campaign, and give decorative images an empty alt="" so screen readers skip them. Then open the email with images blocked and check it still makes sense, because classic Outlook blocks images from senders who aren’t in the address book, and plenty of corporate inboxes do the same for everyone.

Outlook, and the other things the template absorbs

Classic Outlook on Windows, still common in corporate inboxes, renders email with Microsoft Word’s engine. That is why email HTML still uses tables for layout, and why background images, rounded corners and a lot of ordinary CSS need workarounds or conditional comments. The point of a template is that someone solves this once. Your developer builds the tables, adds the Outlook conditionals and tests the result; after that, nobody building a campaign should ever see them.

The same goes for Gmail’s size limit. Gmail clips messages larger than about 102 KB and shows a “View entire message” link in place of the rest, which cuts off your footer and, with it, the unsubscribe link. Keep the HTML lean: no unused styles, and no nested tables that aren’t earning their place.

Modules designed for real content

The neat version of a module in the design file is rarely the one that breaks. Before a module goes into the library, test it with the longest headline anyone is likely to write, a product name that runs to two lines, a missing image, a price with a “was” and a “now”, and copy in a language that runs longer than English (German usually does). Decide which parts are optional and what happens when they’re empty: an optional subheading should disappear cleanly, without leaving a band of spacing behind it. This is most of the case for modular email templates. Each module is designed, tested and documented once, then reused rather than improvised.

Write the rules down

If the same decisions come up in every email, they belong in an email design system: the type styles and their fallbacks, the brand and functional colours, spacing, button styles, image ratios and crops, the approved modules and what each is for, how things stack on mobile, and the content limits that protect the layout. Then put as much of it as you can into the template’s HTML, where it applies itself, rather than into a PDF people are meant to remember. A good test of a design system is whether a new starter could build an on-brand campaign in their first week without asking anyone.

The rendering problems that still catch teams out

Problem	Where it shows up	What the template should do
Web fonts ignored	Gmail, most versions of Outlook	A fallback stack that still looks like the brand
Images blocked by default	Classic Outlook, many corporate inboxes	Live text, alt text, background colours that work on their own
Email clipped	Gmail, over about 102 KB	Lean HTML, so the footer and unsubscribe link survive
Colours inverted	Dark mode in Outlook and the Gmail apps	Padded logos, dark grey rather than black, bordered buttons
CSS unsupported	Classic Outlook on Windows	Table layout and Outlook conditional comments
Media queries ignored	The Gmail app with a non-Google account, some webmail	A single column that looks right without them

Don’t test in every client. Test in the ones your subscribers use. Your ESP’s reports will tell you which, and Apple Mail, Gmail and Outlook will usually account for most of a consumer list. That list changes slowly, so settle the test matrix once a year rather than per send.

Check these on every send

One job, stated early

Decide what the reader should do before you pick a single module, and write it down as one sentence. A launch email introduces one product and sends people to it. A monthly roundup helps people scan several stories. They need different structures, and the brief tells you which. The first screen should then confirm whatever the subject line promised: if the subject says “Your invitation”, the date and the button should be visible before anyone scrolls, not under a paragraph about the brand.

Subject, preview text and sender name as a set

They are read together in the inbox list, so write them together. Use a sender name your readers recognise and a subject that says something specific. The preview text should add something the subject didn’t say rather than repeat it, and you should check what shows when it is cut short, because every client truncates at a different point. Leave the preview text empty and the client fills it with the first text it finds, which is often “View this email in your browser”.

A hierarchy that can be scanned

Most people scan before they read. An eyebrow label when context is needed, then the headline, two or three lines of copy, then the button. Size is only one way to show what matters; spacing, contrast and position do as much. If every module has a large heading, a bright image and a bold button, nothing stands out. Headings should say what follows: “What changes in the new plan” rather than “More information”.

One primary action

One button per email that you would be happy to be judged on, placed where a reader who stops after the first screen still sees it. Secondary links can be text. Button copy says what happens (“See the autumn edit”, “Book your slot”) rather than “Click here” or “Learn more”, and the hero image should link to the same place, because people tap images.

Images chosen for this campaign

Crop for the module’s ratio instead of letting the client squash the image into it. Write alt text for the image you actually used, not the one in the template’s example. Check the file sizes before you send a test, not after.

Personalisation and dynamic content

Every merge tag needs a fallback (“Hi there” when there is no first name), and every dynamic block needs checking for each variation it can show, not only the one you happened to preview. A broken tag renders as the tag itself, in front of everyone.

Links, dates and the legal lines

Click every link in the test, including the logo and the footer. Check the tracking parameters match the campaign. Read the dates, prices and offer terms with fresh eyes, or better, someone else’s. Confirm the unsubscribe link and your postal address are present and working: the law requires them, and Gmail’s clipping is one of the ways they go missing.

A real test send, then sign-off

Previews are useful; a real send is the test. Send it to a phone and a desktop, open it with images off, switch to dark mode, and run it through Litmus or Email on Acid if you have them. Then get sign-off in one place, on the email itself, so the comments, the fixes and the approval are recorded together and nobody has to guess which version was approved. Export to the ESP after that, not before.

A pre-send checklist

The message

Subject, preview text and first screen tell one story.
The primary action is obvious without reading everything.
Headings describe what sits under them.

Layout and rendering

Columns stack in the right order on a phone.
Body text is readable without zooming.
Buttons are easy to tap and have space around them.
Nothing important lives only in an image.
The HTML is under 102 KB.

Accessibility

Meaningful images have alt text; decorative ones have alt="".
Text contrast is at least 4.5:1.
Link text makes sense on its own.
Colour is never the only cue.

Content

Every link goes where it should, with the right tracking.
Personalisation has fallbacks, and each dynamic variation has been checked.
Dates, prices and terms are right.
The unsubscribe link and postal address are there.

Testing and sign-off

Sent to real inboxes, on a phone and a desktop.
Checked with images off and in dark mode.
Checked in the clients your audience actually uses.
Reviewed and approved in one place, then exported.

Where Modular Mail fits

Everything in the first half of this guide is a developer’s job, done once. Modular Mail is a CMS for email built around that split. Your developer, your agency or our team marks the parts of your HTML template that should change with a data-mm attribute, and the layout, fonts and spacing stay in the template’s HTML where nobody can move them. Your team gets fields instead: text with character limits, images with an alt text field, and colour and choice fields that offer only the approved options. The second half of the guide happens in the same place, with a test send, comments pinned to the part of the email they’re about, and an approval on record before the HTML is exported to your ESP.

Email design best practices for marketing and CRM teams