Email Development Best Practices 2017


Email development can be a very confusing undertaking. Many new email developers, or web developers who are new to email, find that the complex and multi-layered email client ecosystem causes endless paradoxes. A fix for one client breaks their email in three others. A simple float functions in only half of the email clients available.

The best practices that I’ll outline below cover both email design and email development. Starting with these best practices in mind can save you hours of hair pulling down the road!

Email Design

Single column design

Keep the design simple to make life easy! A single column design is sufficient for most emails (other than product based or newsletter style) and will help make it much easier to accommodate mobile devices. It’s also easier for your readers to scan a single column of material than it is to jump around a lot.

Use 600px for default width

We recommend that you keep your email’s maximum width close to 600px. This width should give you plenty of space and will fit nicely on most web and desktop clients. You can scale it down to fit better on mobile screens using media queries or fluid design (see below).

Keep mobile users in mind

With the rise in popularity of mobile devices, some email designers have embraced “mobile first” design. This means that they design the email with mobile primarily in mind, and then make sure it also looks good on desktop. This approach is the opposite of what many designers have been doing; designing it on desktop and then adapting it for mobile. By putting mobile users first, designers hope to increase engagement and click-throughs on mobile devices. We recommend this approach especially for simpler emails like password resets, transactional emails and account updates.

Every email client is different

When designing an email, keep in mind that it’s going to be very difficult (if not impossible) to achieve “pixel perfection.” Instead, try to achieve an email that maintains your branding while being easy to read (and click) on all email clients.

The only way to know how your email will look across the board is to test it.

Plan for missing/blocked images

Some clients will block images by default, and some users will change their settings to block images so that they can save on data usage. If images aren’t downloaded, it may be impossible to get your message across. To prevent this, include descriptive alt text for your images. You should style alt text to improve its appearance.

Use email safe fonts

You can use Google Fonts, but you’ll find that many clients don’t support them. For this reason, having a good fallback font is key. Your fallback font ensures your design still looks good without custom web fonts. You’ll also want to make sure that you use a font-stack compatible with Outlook. One of the many quirks of Outlook is that an unrecognized font in the stack will cause it to fall back to Times New Roman. Address this annoying bug using one of the four fixes we covered.

Here is a short list of fonts that should be supported universally: Arial, Arial Black, Comic Sans MS, Courier New, Georgia, Impact, Times New Roman, Trebuchet MS, Verdana, Σψμβολ2 (Symbol), and Webdings. MailChimp also has an excellent list of email safe fonts.

Avoid entirely image-based emails

If image blocking is on, your carefully crafted email won’t communicate anything! With image blocking on, your whole message may be lost. If text must be contained in an image, use styled alt text to make sure your message gets across.

Image-based emails are also very hard on your recipients’ data plans and can be very difficult for the visually impaired. Use HTML text where possible, instead.

Don’t forget to add an unsubscribe link!

And don’t try to hide it. You don’t want to be emailing people who don’t want to read your emails. It’s also illegal to leave an unsubscribe link out of commercial email. The unsubscribe usually appears in or below the footer. If you want to go for extra credit, set up a “manage preferences” center, which can help reduce the number of unsubscribes you see.

Email Development


Tables are your friend. When in doubt, table.

Forget divs and floats. Yes, I know it seems like we’re forcing you to code in the dark ages of the internet, but tables are by far the most reliable way to achieve a consistent layout. They also enable us to replicate something that many email clients otherwise don’t allow: floats. Okay, not really CSS floats. Tables allow us to take advantage of the align attribute, which was the progenitor of modern CSS floats.

Using align=”left”, we can cause tables to stack on top of each other on smaller screens. This technique is the basis of responsive and fluid design. At a basic level, it works like this: We have two tables that are each 300px wide, with align=”left”, inside the same container. If the screen is 600 or more pixels wide (as it would be for most desktop clients) then the tables will appear side by side. If the screen is only 400px wide, then the two tables will stack on top of each other.

Nested tables are totally safe, so feel free to nest away. You can also use colspan and rowspan, as long as you count your columns/rows carefully. Watch out for empty TDs, as some email clients don’t handle these as you’d expect. Usually this issue can be fixed by adding an ” ” or non-breaking space character. You can control the size of this character using CSS so that it doesn’t mess with your layout.

Know your framework

There are a two popular approaches to coding an email layout. The most popular framework is usually called “responsive.” The basis of this technique is to start with a 100% width table (to which you can apply styles that will affect the whole email) and then floating (using align=”center”) a fixed-width table in the center of this wrapper. Using media queries, the width of this fixed-width can be adapted to various screen sizes. Our free Seashells template is a great example of this coding technique.

The other popular framework is called hybrid fluid or “spongy” design. This technique uses container tables that are set to width=”100%” and constrained by a max-width style. On screens wider than the max-width, the table will reach its max and become no wider. On smaller screen, like tablets and phones, the table will naturally fill the available space. The “hybrid” part of this technique is that each table must be surrounded by a conditional table visible only to Outlook. The hybrid table has a fixed width, which solves the main problem with fluid design: Outlook ignores max-width statements. The main advantage of this technique is that it works pretty much everywhere, regardless of support for embedded styles or media queries. For more on hybrid fluid design, check out our primer. We also have a few free hybrid fluid templates, including the Coffee Shop template.

Make sure code is well commented

Keeping our code well commented will allow for ease of editing templates. This is true of any kind of coding, really, but shouldn’t be neglected for email. Because email development is full of hacks and fixes for client quirks, it can be invaluable to note why a particular style or element was added.

Encode special characters

If your ESP uses a different kind of encoding from the kind you selected for your email, it may cause your special characters (like ©) to appear incorrectly, often as a black square or a diamond. This can even affect quotation marks and apostrophes. To avoid this problem, use a character encoder like this one, or the one that is included with the Email Editor.


Keep email file size under 100kb

There are a couple good reasons to keep your email under this limit. One is that it will pass through more spam filters by staying light. Keeping your email under 102kb will also prevent Gmail from “clipping” your email, as shown in this Adestra article.

To keep your email under the limit, consider removing redundant or unused styles, moving some of the content of the email to a landing page, or minifying your code before sending it out. Just make sure to test any changes before the final send!

Code for high DPI displays

High DPI displays such as Outlook 2010 on a laptop that is defaulted to high DPI can often cause issues when scaling email designs. This is because it will scale certain parts of the email (those with height, width, font-size and so on coded in px) but not other parts. To make sure your whole email scales properly, just follow the steps in our Coding for DPI Scaling in Outlook blog.

Include preheader text

Preheader text is what you see after the subject of the email in many inboxes. This text is easy to code and can make a huge difference in open rates. Just make sure you don’t hard-code “default” preheader text into your template!

Avoid Javascript, Flash, forms and other complex CSS/HTML

Javascript and Flash are completely unsupported in email clients, so don’t use them at all. Newer code, such as HTML5 and CSS3 have limited support, but are sometimes possible (and fun!) to use. These enhancements should be used with caution. As always, test thoroughly when using any advanced code!

Use cellpadding for spacing

Cellpadding provides reliable spacing across all email clients. If you need spacing only on one side of an image or container, you may want to use another spacing technique. Check out our blog on spacing techniques in email for more info.

Test test test!

Email coding is hard! Every email client has different quirks when it comes to rendering code. Outlook for desktop (2007, 2010, 2013 and 2016) can be especially challenging. The only way to know your email will look great everywhere is to test it. Email on Acid can help you test by generating over 70 screenshots of all the most popular email clients in less than 30 seconds.


Make images retina ready

Many devices now include “retina” displays. This means that they have more physical pixels than their CSS dimensions would otherwise indicate. A 10px wide image might use 20 or more physical pixels to display it. By using extra large images, we can make sure that they appear extra crisp on these displays. For more on this technique, read our articles about retina images in email and fluid retina images for email.

If you include hard coded preheader text (usually in a field that can be modified), you will at some point forget to customize it and you’ll send out an email with preheader text like, “PREHEADER TEXT HERE.” What a faux pas!

Instead, just include the “default” preheader text as an HTML comment. This way, other marketers and developers you work with can tell what purpose of that part of the code serves, but no recipients will see it if you forget to customize.

Use absolute addresses for images

You may be using local image references for your testing, but when you do your final send absolute image references are an absolute must!

Seeing strange spacing around an image?

Use display:block and it will usually remove this extra spacing. This is actually a doctype issue.

Don’t use image maps

If you need to connect one image to multiple locations, you’re going to have to slice it. Put each slice in its own table cell, and then link the images. This can cause all kinds of havoc trying to get the slices to line up perfectly, so I would only do this as a last resort.

Background images take some extra work

This is because Outlook can’t handle the background attribute or backgrounds set through CSS. You’ll have to use VML to get backgrounds working in Outlook, and even then it can be finicky. If you’re having a hard time, try using Stig’s button and background generators so that you don’t pull all your hair out.


Use inline styles

Even with Gmail’s recent changes to support embedded styles, including classes, IDs and media queries, you still need to inline styles. Some Gmail clients, like Gmail Android App for Non-Gmail Accounts (GANGA), still don’t support embedded styles. In addition to this, there are quite a few smaller email clients like Yandex and Telstra that still require inline styles.

To achieve this, you can code using classes and IDs and then make use of a CSS inliner. Email on Acid offers an inliner that you can use from any email test, or from within the Email Editor.

Avoid shorthand CSS when possible

If you see problems with a client interpreting your CSS, check to make sure you’re not using a shorthand declaration. For example, “margin-top: 5px” may work where “margin: 5px 0 0 0;” does not. Especially avoid three-digit hex codes. Some clients don’t react well to these, so you’ll want to make sure you always use the full six-digit code.

Get used to !important

If you are a web developer, you may have been trained to avoid !important at all costs. When coding email, though, you’ll find this declaration can be invaluable. You can use it to override styles added or modified by the email client (especially web clients). You’ll also get a lot of use out of !important when writing media queries, where this declaration will let you override a default style with a mobile-specific one.

Get comfortable with media queries

Media queries are commonly used to create custom styles for different clients or screen sizes. The basic format of a media query for email is:

@media only screen and (max-device-width: 640px){ styles here }

This will cause the styles contained in the query to trigger only on screens of 640px or smaller. “Min-device-width” would do the opposite, triggering on screens of 640px or larger.

The most common uses of this technique are to control font sizes, image sizes, and to make some tables become 100% width so that they will fill a mobile screen. You can also use media queries to hide content that isn’t necessary for mobile users. Just make sure that you use !important on styles within the media query, so that they will overwrite existing styles. Click here for more on using media queries in HTML email.

What best practices do you follow?

We’re always looking for more tips to add to our list! What best practices do you follow when developing emails?

Original Source