Email best practices

With the multitude of email client, browser, and platform combinations, it's not possible to make your messages appear the same to all recipients. However, if you adhere to these proven best practices, you can code to one widely compatible standard for consistently reliable rendering.

Web-based technologies to avoid

For best results, avoid the following tools and technologies. They are not supported and can lead to your email being blocked from recipients.

  • CSS based layouts that rely on DIV tags and positioning
  • Scripting languages

    The presence of any scripting language code is almost always flagged as potentially malicious and leads to your message being kept out of inboxes by any respectable spam filter.

  • Forms

    Forms should be hosted on your website or as a landing page in Acoustic Campaign where they can be linked to from within your emails.

The Document Type Definition (DTD)

At the top of your HTML code, include the document type definition or DTD. The DTD defines the markup language specification that is used and determines how the browser or email client interprets and renders the HTML. Some email clients might strip the DTD, but it should be included during development for code validation.

HTML email can safely be coded as either HTML 4.01 Transitional or XHTML 1.0 Transitional. HTML 4.01 Transitional is recommended because it has fewer coding requirements than XHTML 1.0 Transitional.

XHTML 1.0 Transitional supports the entire HTML 4.01 Transitional specification. It also requires that all tags and attributes are lowercase and that all tags are properly closed. Tags that do not have a separate closing element, such as the <BR> tag in HTML 4.01, require a closing space and slash in XHTML. For example: <BR />.

The following example shows the code for the respective DTDs. Select one of the DTDs to include before the opening HTML tag.


   <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
   <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

Character encoding

In the head of your HTML code, define the character encoding. Character encoding determines what characters can be displayed in your message. There are two types of character encoding:

  • ISO-8859-1 (ASCII)
  • UTF-8

The American Standard Code for Information Interchange (ASCII) is a character encoding standard based on the English alphabet. It is the default character set used in American digital communications. The ASCII character set is represented in the Western European character encoding, which is defined in HTML as:

<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">

For emails that consist of non-English language characters, use the UTF-8 character set because it supports all languages. For example, if your message requires the Chinese character set, you must use the UTF-8 character set, which is defined in HTML as:

<meta http-equiv="Content-Type" content="text/html; charset=utf-8">

UTF-8 is becoming the dominant character encoding of the web with many Internet standards organizations that require full UTF-8 support in email programs. It is also increasingly becoming the default encoding for operating systems, programming languages, applications, and APIs. In fact, UTF-8 can be used for English language emails as well because it supports the entire ASCII character set as well as international characters. It also supports symbols such as ® and © without any HTML conversion required.

Cascading style sheets

Cascading style sheets (CSS) are used to code presentation elements on the web. There are three different ways to include CSS:

  • External CSS points to an externally hosted style sheet file. External CSS is not supported.
  • Embedded CSS is code that is defined in the head of the HTML code. Embedded CSS is poorly supported across desktop email clients.
  • Inline CSS is defined where is it needed, throughout the document. Inline CSS is the only reliable option for styling your email content.

The following list of inline CSS properties are consistently supported among the major email clients. The supported properties are mostly limited to basic font-related definitions. There are no margin, padding, or positioning properties.

  • font-family
  • font-size
  • font-weight
  • color, which is used for defining link colors
  • text-decoration
  • display, which is used in image tags to fix a bug in Gmail and Outlook.com.

For example:

<TD style="font-family:arial,helv,sans-serif;font-size:12px;color:#ff0000;">Sample text.</TD>

Do not to use short values for CSS. For example, use #FFFFFF not #FFF.

Do not use list styles because they are not supported in several clients.

There are two exceptions where embedded CSS can be effectively used:

  • As fixes for well-known bugs in email clients that don’t strip out embedded CSS
  • CSS3 media queries for styling content specifically for mobile devices

Special characters

The following table illustrates the special characters that might require special attention when they are used in email. These characters can’t be typed directly into your message and can be problematic by displaying as blocks or question marks.

Description Character HTML entity ASCII equivalent
Copyright © © (C)
Registered trademark ® ® (R)
Trademark ™ ™ (TM)
En dash – – –
Em dash — — —
Ellipsis … … …
Apostrophe ' ’ '
Open quote « “ «
Close quote » ” »

If you use these characters in your email, replace them with either the HTML entity (in HTML code) or the ASCII equivalents (in text content). It is common practice to use the ASCII equivalents for the apostrophe, quote, em dash, en dash, and ellipsis characters in your HTML, although the HTML entities are the typographically correct characters.

Consider setting the auto-format and auto-correct options in your word-processing application to use the ASCII equivalents of these characters instead.

Note: UTF-8 encoding supports © and ® directly.

Comment tags

Comments are great for labeling or explaining source code. Comments can be used safely, but only if they begin and end on the same line. There should be no hard breaks between the comment start and end tags.

If you comment out sections of your code, remove any content that you don't want displayed before you send. AOL Mail displays content that was commented out if the comment mark-up spans multiple lines.

Email address links

Email addresses that appear in messages are usually converted into links. If you want to retain control of the appearance of your message, code email addresses as mailto links. Then, you can apply a color style to the link and make it consistent with the rest of your design. Apply this link to email personalization strings also. For example:

<a href="mailto:%%email%%" style="color:#ff0000">%%email%%</a>

Spacing issues

Don't use padding or margin styles to control the spacing in your HTML message because these styles produce mixed results across major email clients.

Yahoo! Mail does not handle spacing between <p> tags the way you would expect. Instead of adding a line of white space between paragraphs, it adds only a line break (<BR> tag). Instead of using <p> tags, use two line breaks tags or table cells for consistent content spacing.

More information

For more information, see the following websites: