Email template

An email template is the reusable shell your messages are poured into. Header, footer, spacing, type, the way a button looks. You build it once so that writing an email becomes writing, instead of designing something from scratch every time. The unusual part is the environment it has to survive, because the code behind email is nothing like the code behind a web page.

In short

• It is a shell for future messages, not a design for one message.
• Mail apps render the same code in very different ways.
• Assume images will not load and write so the message survives it.
• One shell used consistently beats a folder of variations.

Words you will hear

• Client. A mail app, such as Gmail, Apple Mail or Outlook. Nothing to do with your customers.
• Rendering. How a given app turns your code into what the reader sees.
• Inline CSS. Styling written directly onto each element, because many apps discard styles kept in one block at the top.
• Preheader. The line of text shown after the subject line in the inbox preview. Frequently left as whatever the template happened to start with.
• Dark mode. A reader setting that can invert your colours without asking.
• Plain text part. A version of the same message carrying no formatting at all, sent alongside the designed one.

Email is not the web, and Outlook is why

Anyone who has built a website expects code to behave roughly the same way everywhere. Email does not work like that, for one long-running reason.

Since 2007, the Windows desktop version of Outlook has rendered HTML email using the engine behind Word rather than a browser engine. It was never built for layout, and it ignores a great deal of what modern code takes for granted. That single fact is why email is still built on tables and styling written onto every element, decades after websites stopped needing either.

Microsoft is retiring those versions during 2026, and the newer Outlook renders with a web engine like the rest. The transition is genuinely good news and it creates one odd year in the middle, where two colleagues who would both say they use Outlook can open the same message and see two different layouts. Testing matters more during that period, not less.

None of this affects a website, so a designer whose experience is in responsive design for the web can produce something beautiful that falls apart in an inbox.

Design for the version with no images

The safest assumption is that your pictures are not there.

Many mail apps hide remote images until the reader chooses to load them, and a proportion never choose. If the offer, the date and the reason to care are all inside a graphic, those readers receive a rectangle. This is the fault behind most emails that seem to arrive empty.

• Put the message in text. The headline, the offer and the call to action on the button should be real text, not part of a picture.
• Write alt text as a sentence. In email it is not a fallback, it is the first version many people read.
• Give images a background colour. A dark logo on a transparent background disappears the moment a mail app inverts everything for dark mode.
• Keep to one column. Side-by-side layouts are the first thing to collapse awkwardly on a phone, and most of your list is on a phone.

Two lines of the shell do more work than the layout does, and both are usually left wherever the builder put them. The sender name and the preheader are what a reader sees in a crowded inbox before any of the design exists. A preheader still reading “View this email in your browser” wastes that line on every send you will ever make, and correcting it is a change to the template rather than a decision anybody has to take again.

A template is a shell, not a design

The reason to have one is less about how the email looks and more about who is allowed to send it.

A settled shell means the person writing next month’s message is choosing words and a picture, not making layout decisions under time pressure. That is what keeps a year of sends looking like one business, and it is the same argument as brand guidelines make for everything else. It is also what allows an email flow built once to keep looking current while the sends around it change.

The shell itself is a piece of graphic design working under unusually tight rules, which is why it is worth settling properly once rather than adjusting a little with each send.

The constraint is the useful part. When the shell offers one button style and one heading size, nobody has to decide, and nobody invents a seventh variation on a Friday afternoon. Businesses that keep several templates for no strong reason usually end up with sends that do not recognise each other.