Design & UX
By Lauren Ribando

Rules for Best Practice Email Design: Coding Practices

By Lauren Ribando
A Mail UI

Photo: alykat

In part one of this ‘Best Practice Email’ series we talked about email layouts. In part two we focused on email content. In this final installment of “Rules for Best Practice in Email” we get under the hood, and look at the best coding practices.

Now that you know how to create a well-designed graphic email that accommodates differences in email clients and web browsers, it’s time to make your emails work in every inbox.

As we mentioned in Part 1, a graphic email might look and feel like a webpage, but is it coded just like a webpage? Well sure – if that webpage was coded in the 1990s.

Writing markup for email takes HTML back to the old school. These tips will help those of you who don’t recall the days of flannels, pagers, and the Discman, or who think of tables only as something to eat off or store data in.

1) Use tables for layout

To ensure that your layout renders correctly across all inboxes, use tables–lots of tables–all nested together. This tip defies modern-day web development, in that tables are now primarily used for tabular data–not for webpage layout.

Since CSS became a suitable and more flexible way to layout webpages, using tables – the old-school way of coding webpages – has been rightfully railed against by web developers. However this isn’t the case when marking up HTML for a graphic email where tables are not only acceptable but still the preferable method.

As much as our instincts might tell us otherwise, the sobering facts are that tables seem to be the only surefire way to get multicolumn layouts working across all likely inboxes.

Using divs for very simple layouts can work well, but test the divs thoroughly to ensure they behave as intended. Outlook, Yahoo and Hotmail don’t offer great support for position and float, so it’s wise to make sure that your other CSS properties don’t fail in different clients.

Tables offer the most consistent support across all clients and have long-since been the standard for coding emails. However outdated or unfamiliar they might feel when being employed in laying out templates, it is likely you will achieve the best results in all inboxes using tables over divs or other methods.

2) Bring your styles inline

Gmail and other email clients, inevitably strips some (if not all) of the CSS out of the tag in HTML documents. For this reason–plus the fact that external stylesheets are not an option in email—place your CSS styles inline.

This makes for a lot of repetitive styles applied to each element and completely eliminates the luxury and convenience of classes, but it will offer the most consistency and preserve a well-designed template. Some email service providers like MailChimp and CampaignMonitor now offer conversion tools to bring your CSS inline and relieve the headache of having to repeat styles for each element.

The exception to this rule: Media queries aimed at layouts for mobile devices. Media queries are always written as topline CSS and contain classes, when supported they enable a different experience for mobile users to view email designs on smaller screens.


3) Always avoid shorthand CSS

When coding email there aren’t a lot of shortcuts to make life easier, and unfortunately using shorthand CSS does not seem to be an exception.

Support for shorthand CSS in font, padding and defining hexvalues is generally inconsistent (although using the shorthand format with borders does sometimes work). As is always the rule with coding email: If you are going to try it, test it–everywhere. Make sure that shorthand properties behave the way you intend them to, and do not rely on default values – define them.

In short, the benefit of shaving a few characters off your CSS is unlikely to be worth the new rendering headaches it creates.

4) Wrap your background color in its own table

Similar to stripping out style tags, some email clients will strip out the body tag as well. For this reason, it is wise to define the background color in a separate table wrapped around the rest of the template and set the width to 100%.

By default, most email clients display messages on a white background. The amount of background displayed varies across clients, and other factors such as banner ads, toolbars and menus can affect the message pane’s overall size.

Another good approach to ensure that an email template displays clearly within the message view pane: add a border either around the whole template or to the template’s sides. If the content within the template appears on a white background, this will enclose the design and create some space between the message and the pane.

Background in email

5) Slice your images

Images are key to a great email design and usually link to a webpage or several.

Unfortunately, image maps are not well supported everywhere (and may not link your images at all). Once again, taking the long road is the best solution: Slice all those images, and link each one separately. This will enable you to verify that each link works, and will also download smaller images faster.

While the list of constraints may seem daunting, email clients have come a long way, and will continue to change and grow. Once upon a time, there was simply no CSS support at all for email, and markup required a lot of empty cells and spacer gifs to get the padding just right.

Lately, achieving standardization of HTML for email has become an internationally recognized goal.The Email Standard Workgroup, a W3 group, will meet in September to discuss a new HTML syntax standard for long-term use.

Email has a proud history and a long legacy, but it is shuffling in the right direction.

  • Jeroen Meeus

    A good tip for testing in outlook without having outlook is to check how it looks in word. Because of measures agains the monopoly of Microsoft. Microsoft isn’t allowed to tightly couple his office products with IE. For that reasin the html rendering is now done by word (in outlook) as opposed to IE in the earlier days. For this reason Outlook07+ will have a harder time rendering things correct then older Outlooks.

    A good email template can be found at that addssome nice resets accross the different platforms. For a list of supported css accross different platforms:

  • Great piece, Lauren.

    I have to work with HTML emails too often, and while it can be a pain in the behind, there’s a bizarre sense of satisfaction when beating the obstacles in-place by Outlook and whatnot and producing something decent.

    One note: I’ve personally found Mailchimp’s inliner-tool to be unreliable; it often arbitrarily fails to insert some bits of CSS, meaning I’d have to go and pop them in afterwards. Not sure if this is a universal problem. Also, it doesn’t compile the code too well I’ve noticed. I’d recommend MailerMailer’s tool ( – it’s served me well so far and does what it says on the tin.

  • This is really an awesome article. Great explanation..

  • YNWA

    Such great info! Thanks.

  • madmac10

    I am sorry to say that this inliner does NOT convert my email. It keeps throwing an error (hard to see in tiny text below the “results” box) “Warning: no CSS was found.”

    A fairly reliable inline is Zurb’s Ink Inliner:

    The only trouble I found with it is that it converts special characters to UTF characters in the code—so you have to comb through the code and put them all back (a little bit of a pain.)

    • Lauren Ribando

      Thanks Simon! I haven’t actually tried any of the tools myself, it has been instilled in my brain for so long to code everything inline that it is the norm to me. Sorry to hear MC’s inliner isn’t the best. I was going to recommend Zurb as madmac10 has as well.

      Hoping to discuss common bugs in a future article – stay tuned!

    • It’s becoming clearer and clearer that certain inliner tools favour certain developers over others, ha. :f

  • Lauren Ribando

    Thanks for the tip Jeroen! I never heard of that one and I am sure it is a great time-saver since Outlook gives he biggest headaches. In a future article I hope to tackle all the pain points and bugs each Inbox brings – stay tuned…

  • George

    Now, how about an article on what you need to do to override all of the annoying styling that the various browsers and webmail clients add? For example, GMail and others will try to turn anything they think are dates into calendar links (which is really funny if your sentence is “Yeah mon, we be wed now!”) – makes it awkward to see the real links and messes with my colouring. For some reason, the Zimbra mail client in Firefox will resize the body of my emails and only show a small strip of it, so have had to add a hard-coded height with important to force it open. And for the life of me, I cannot get Hotmail to not add an inordinate amount of padding to each and every paragraph, list and other items. making my emails even longer than they need to be.

    • Lauren Ribando

      Hi George, for my next article I am hoping to tackle various bugs each inbox brings. I will definitely be offering suggestions for the unnecessary linking issue, so stay tuned!

      I am not familiar with the Zimbra mail client but it looks like you found a workaround. For the Hotmail spacing issue, I know that is very aggravating – each inbox tends to set their own margins. You can probably get around it by explicitly defining your own or what I do is avoid tags all together and use rows with padding to get the spacing just right.

  • Thanks, top list of subject about practice email coding.

Get the latest in Design, once a week, for free.