Smashing Newsletter

Email design and development is a beast. Email client vendors haven’t been as progressive as web browser vendors in adopting new standards. Here’s an insight into the world of building and sending email, and a couple of code snippets and resources that are sure to add some hours back into your life.

I’ve spent the past several years building development tools — two of those years as product design lead at Mailgun, an email service for developers, where I learned a lot about how email works and the problems that developers face when building HTML email. In this post, I’ll share some of my knowledge about the topic.

HTML email: Two words that, when combined, brings tears to a developer’s eyes. If you’re a web developer, it’s inevitable that coding an email will be a task that gets dropped in your lap at some time in your career, whether you like it or not. Coding HTML email is old school. Think back to 1999, when we called ourselves “webmasters” and used Frontpage, WYSIWYG editors and tables to mark up our websites.

Not much has changed in email design. In fact, it has gotten worse. With the introduction of mobile devices and more and more email clients, we have even more caveats to deal with when building HTML email.

I’ve spent the past several years building development tools — two of those years as product design lead at Mailgun, an email service for developers, where I learned a lot about how email works and the problems that developers face when building HTML email. In this post, I’ll share some of my knowledge about the topic.

Introduction To Sending Email

As a developer responsible for an email campaign or all of the emails your company sends, you will need to know how email works, the legal requirements and how to actually get email delivered. Companies send a few different types of email. Let’s take a look.

Marketing Email

A lot of email service providers (ESPs) specialize in marketing and promotional emails: SendPulse Email, Campaign Monitor, MailChimp, Emma, Constant Contact, to name just a few. They provide full solutions for managing subscribers, working with email templates, running bulk email campaigns and reporting.

Transactional Email

Transactional email includes receipts, alerts, welcome emails, password resets and so on, and it is typically implemented with development tools and APIs such as SendPulse Transactional, Mailgun, SendGrid and Postmark. These tools are more API-focused, less CMS- and WYSIWYG-based; however, combined with a service such as Sendwithus, they can be made even more powerful.

An alternative to using a service is to roll your own email server with something like Postfix. The downside of this is that it’s up to you to set up and configure it and to understand the technical details of sending email, implementing tracking and unsubscribing, and getting email delivered to inboxes.

Email List Best Practices

Don’t buy email lists. Maybe a handful of legit services are out there, but you’re best off staying away from buying lists altogether.

My experience is that anyone who buys an email list will suffer from a lot of bounces, give their Internet Protocol (IP) address a bad reputation, and get their emails blocked by Internet service providers (ISPs) or sent to spam. 85% of the world’s email is considered spam, according to SenderBase; don’t fall into this bucket.

Double Opt-In

A subscriber having to verify their email address adds an extra step to the process, but it makes sense and stops other people from abusing their email address by signing them up for lists without their permission. It also helps to keep your subscription list clean and is the “100% correct way to validate an email address”.

Analytics And Measuring Performance

Measure everything. You need to measure to know whether your emails are improving. The numbers will differ vastly depending on what you do, your industry, the type of emails you send and the context. However, in general:

20% is a good open rate,

3 to 7% is a good clickthrough rate,

5% is a poor bounce rate,

0.01% is a poor spam rate,

1% is a poor unsubscribe rate.

Also, remember that open rates and clickthrough rates can be vanity metrics (read “they don’t really matter”). At the end of the day, what you really want to track is that end goal or conversion. At Airbnb they track an email quality score, which is a good indicator on engagement quality.

Google’s URL builder can help with tracking if you’re using Google Analytics.

Sending Score And Reputation

Your emails have a reputation and score associated with them. This affects how ISPs and mailbox providers deal with your email, whether they accept or reject it and whether they send it to the recipient’s inbox or straight to spam.

Sending Bulk Email

When you send a lot of emails (imagine a campaign with millions of emails), they are not all sent instantaneously. They can only be sent as fast as the servers and IP addresses can handle them. Keep in mind that your recipients might not receive the emails at exactly the same time.

So, if you’re sending millions of emails at once, you’ll probably want quite a few IPs to handle the load.

Email Clients

Litmus keeps track of the market share of email clients, based on its own internal statistics. Keep in mind that this is probably not the same for your customer base, but it is a good indicator to go by.

Here are the statistics as of December 2016:

iPhone: 33%

Gmail: 19%

iPad: 12%

Android: 8%

Apple Mail: 7%

Bear in mind that not all emails can be tracked. Email tracking is done via pixel-tracking, so only those clients with images enabled will report back.

HTML Templates

Building HTML email templates can be a slog. As a result, a lot of poorly designed email is out there — clunky, themed, verbose, pointless, distracting. If you enjoy a challenge or want a unique look and feel, then building your own can actually be fun and rewarding. Alternatively, some good email templates are available:

Building HTML Email Templates

Now you know how to properly set up and send emails. The next decision you’ll make is whether to code your own HTML template. This is a bit more complex than coding the average web page. Let’s dive in.

Client-Rendering Engines

Email design is still in the dark ages. Due to the numerous email clients and devices, your email will get rendered for users in a variety of ways.

Clients will also add their own flavor of styles on top of yours. For example, Gmail sets all <td> fonts to font-family: Arial,sans-serif;.

Look at your own statistics so that you know what to design for.

Gmail Support for Inline CSS and Media Queries

Only recently did Google announce support for embedded CSS and media queries in Gmail. This is huge for the email development industry.

Now, as of September 2016, Gmail will support a slew of CSS properties, which makes template development for Gmail a lot easier.

Using HTML Tables For Layout

Divs have positioning and box-model issues in different clients — in particular, those that use Microsoft Word to render (i.e. Outlook). You can use divs if you want, but it’s safer to code like it’s 1999 and stick to tables. This means:

<table> instead of <div>,

#FFFFFF instead of #FFF,

padding instead of margin,

CSS2 instead of CSS3,

HTML4 instead of HTML5,

background-color instead of background,

HTML attributes instead of CSS,

inline CSS instead of style sheets or <style> blocks.

These are best practices. You could certainly ignore the safe route and go above and beyond.

When using tables, don’t forget border="0" cellpadding="0" cellspacing="0". If you’re using Premailer, it has special CSS declarations for applying these HTML attributes.

Inline CSS

Some clients (most notably Gmail until recently) will strip any CSS that isn’t inlined. You have a couple of options here:

write CSS inline as you go,

use a web-based CSS inliner,

use a programmatic CSS inliner,

let your ESP handle the inlining for you (if it supports it).

Writing inline as you go isn’t exactly a scalable or maintainable solution, so I tend not to recommend this, but I know that a lot of email developers prefer this in order to maintain 100% control. If you do write your CSS inline manually, then I recommend making use of snippets and/or a templating language with partials and helpers. This will save you from having to repeat yourself.

What’s going on here? The first <td> is a wrapper to help us center the button. The second <td> is the size of the button. Some clients (such as Outlook) don’t recognize the padding on the <a> tag, so we fill in the background color of the table cell. The <a> tag then takes up space available in the second <td>, and the whole area becomes clickable. Check out the code and client tests on Litmus.

This is just one way to implement buttons in email. Admittedly, it doesn’t always look identical in every client, but the web is not always pixel-perfect either. I prefer this because it’s simpler and doesn’t involve using image assets or VML.

What’s VML? If you’ve spent any time developing emails, you’ve likely come across some reference to it. Vector Markup Language (VML) is supported by old versions of Outlook. According to Microsoft, as of Internet Explorer (IE) 10, VML is obsolete, which means that it is no longer supported in new versions of IE. However, as long as Outlook 2007, 2010 and 2013 are around, you will see it being used, typically for background images.

Typography

In general, sticking with standard system fonts is easiest. This includes Helvetica, Arial and so on. However, we can use web fonts, such as Google Fonts. Put them behind a WebKit conditional media query, so that Outlook doesn’t mess them up:

Images And Media

Images in Email

Some clients will show images by default. Some won’t. Keep this in mind when including images in your email content. This also affects tracking metrics, because images will typically be used to track opens.

Outlook blocks image-rendering by default.

Apple Mail doesn’t.

Gmail doesn’t (anymore).

Remember to include good alt text for all of your images. The text could either tell the user what the image says or just describe what it is (for example, “company logo”). You can get creative with alt text for clients that turn off images, as Email Monks does:

Animated GIFs are supported in most clients. Outlook versions 2007 to 2013 do not support animated GIFs, instead falling back to the first frame.

Remember to compress your media assets and upload them to a content delivery network (CDN), such as Amazon Web Services, Cloudinary or imgix. Most marketing ESPs will handle this for you.

Scalable vector graphics (SVGs) have a lot of advantages on the web. As you would expect, email support varies, and SVG requires a couple of fallback hacks or conditionals. I typically recommend staying away from SVG in email, but if you want to get serious about it, then CSS-Tricks has a guide on SVG support in email.

For Retina-ready images, supply a larger image (1.5× to 3×) and resize it. I’ll typically save a low-quality image that has 2× dimensions, which works well. (I’ve written more on this technique.)

Keep in mind that, for Outlook, you need to declare how wide an image should be with the width attribute. Otherwise, Outlook might render the actual width of the image and break your email.

Video in Email

Video is supported in iOS, Apple Mail and Outlook.com. You can use media queries to show or hide a video based on the client. Email on Acid has more on email video support.

For inspiration, check out Kevin Mandeville’s tutorial on coding HTML5 video as a background in an email — impressive stuff and worth a look.

Forms In Email

Support for form elements varies. Try to steer clear, and link to an external form if you need one. Campaign Monitor offers some advice on forms.

Obviously, it depends on your objectives. Staying away from forms is safer, but Rebelmail and Mixmax have done interesting things with forms for surveys and e-commerce, with good fallback support.

Gmail Actions

Getting whitelisted involves a few more steps. You can test Gmail actions with an @gmail.com address.

Preheader Text

Something important but often forgotten is preheader text. Some clients show preview text next to or under the subject line. These clients include iOS, Apple Mail, Outlook 2013, Gmail and AOL.

Clients will grab the first bit of text they find in your email’s body and display it here. Make the most of this and add a hidden element to your body’s content that appears first. This text should provide an extra incentive for the user to open your email. Hide the text like so:

A/B test various types of content, lengths of content and subject lines.

How do you send HTML emails to yourself? Good question. It’s harder than you think. PutsMail lets you do this quite easily, and Thunderbird lets you compose with its HTML editor.

MIME Multi-Part

A plain-text email is just that, plain text. An HTML email is just HTML. Most emails you send or receive are MIME (Multipurpose Internet Mail Extensions) multi-part emails (not to be confused with MIME type). This standard combines both plain text and HTML, leaving it up to the recipient to decide which to render.

When you send an email, whether transactional or bulk, include both the HTML and plain-text versions. Even if, in your mind, every one uses a client that renders HTML, still send plain text.

Also, note that some clients render plain-text email as HTML; for example, Gmail will add some default styles and turn URLs into links. Most ESPs will construct the MIME for you, so you don’t really need to worry about it. Some will also create a plain-text version, based on your HTML.

Pro tip: In Gmail, select “Show original” from the dropdown menu to see the full MIME.

A new MIME part has surfaced: text/watch-html. This content will only be displayed in Apple Watch (and any other clients that support this MIME type going forward).

Accessibility

On the web, if you follow standards and best practices and use semantic markup and valid HTML syntax, you tend to get basic accessibility out of the box. Unfortunately, with email, due to our excessive hacks and the poor support for HTML, accessibility is often ignored.

I’ve seen little discussion on email accessibility, but one that stands out is Mark Robbins’ post on accessibility. He recommends the following:

Add role="presentation" to each table so that it’s clear the table is being used for layout.

Provide alt text with meaningful descriptions.

If you don’t need or want alt text, then use alt="" so that screen readers know it is meant to be blank.

Use semantic HTML tags, such as <p> and <h1>, where applicable.

Use the role attribute for elements such as headers and footers (for example, role="header").

Responsive Email Design

Email opens on mobile are at 50% and rising. The exact metric depends on which report you check and which audience you cater to, but I think we can all agree that this is important.

By marrying fluid, grid-based layouts and CSS3 media queries, we can create one design, that, well, responds to the shape of the display rendering it.

In the email world, we can still make use of fluid design, grid-based layouts and media queries. The problem is that not all clients support these. Therefore, we need some hacks along the way.

Until recently, Gmail did not support media queries. Thankfully, as of September 2016, most of its clients do. However, several mobile clients still do not, including Yahoo, Windows Phone 8 and Gmail for Android.

Several techniques are used in the email world to get around a lack of support for media queries. Some of the terms you’ll hear are “fluid,” “adaptive,” “responsive,” “hybrid” and “spongy.”

Fluid

The easiest solution is to stick to a single column and make your emails fluid. This means that as the viewport shrinks, your content area shrinks.

.container {
max-width: 600px;
width: 100%;
}

Responsive and Adaptive

Using media queries and breakpoints, we can provide alternate styles for different-sized viewports. We can also hide or show elements.

This starts to get complicated once you introduce a grid and columns. You could have a two-column layout and then switch to a stacked one-column layout below a certain viewport width.

Automating Your Workflow

The process of putting together a bulletproof email is complex. There are a lot of steps, and there is room for a lot of things to go wrong.

Like any monotonous task with steps, I recommend automating what you can, so that you build the system once and make it easier for future work.

Brian Graves has a good post on making your email modular. Just as you have a design system and pattern library for a website or application, you should do so for email, making components reusable and emails consistent across your product and company.

Kevin Mandeville recommends using snippets of reusable code to optimize your workflow, so that you’re not constantly rewriting code. In his post, he outlines how to use snippets in modern editors (such as Atom and Sublime), and he points to the community-contributed library of snippets hosted by Litmus.

For my own part, I’ve put together and open-sourced a Grunt workflow for automating email builds. It runs various tasks, such as inlining CSS, compressing images, uploading images to a CDN, sending a preview, and testing with Litmus, all with one command. If you’re new to Grunt, I’ve written a detailed tutorial on how it works. Foundation for Email also has some great automation tools for developers, as does Mailjet with its responsive email framework MJML.

Conclusion

Email design and development is a beast. It is a lot like building a web page… 10 years ago. Email client vendors haven’t been as progressive as web browser vendors in adopting new standards, and we users and companies don’t adopt new email clients like we do with web browsers. Add to that the rise of mobile, and we’re left in this state of having to support a convoluted mix of clients and versions.

My introduction here is a high-level overview; you could dive deep into every one of these points. Hopefully, it’s given you good insight into the world of building and sending email, and the code snippets and resources have added some hours back to your life.