Emails

Welcome to the j2 email and landing page "Best Practices" site

Below you will find a resource of tips, specs and practices for emails, landing pages and HTML coding. These recommendations have been culled from leading edge research from across the web and are outlined here to help prevent problems and optimize your project's results.

Best Practices for HTML Email Design

You've mapped out your strategy, your message is clear, and your email design is compelling. The last thing you want is to have a technical oversight negatively impact your email campaign's success. The following guidelines can help ensure that your HTML emails render properly in the widest array of email clients, resulting in better user experiences and higher inbox delivery rates: I. Define your Proportions
Set maximum width to 600 pixels. You don't want to force recipients to scroll horizontally to view your message.

Maximize the area within 576 x 252 pixels (viewed at 72 pixels per inch). Many recipients view email in the preview pane only, which limits the amount of content visible above the fold.

Design for the potential of large and small font types because not all browser-based email clients have their default type set at medium (or 12 points). Aim for a flexible design robust enough to handle font scalability. II. File Size Considerations
Today, most email users have no trouble downloading large files. However, your target email file size should be in line with your recipients' technical capabilities and preferences. Users with dial-up connections may not wait around for large, graphic-heavy files to load.

For best user and deliverability results, email file size (including dependents) should be between 20k and100k. However, if the message supports it, the list is well-maintained, coding best practices are used, and regular testing is done, it is possible to send larger emails (200k max) successfully, and reap the benefits that can come with them. III. What about Style Sheets?
Table-less layouts are not recommended, as it cannot be guaranteed that the email will render correctly in every email environment. Stick with HTML and nested tables—they are still the standard.

Cascading Style Sheets (CSS) work differently in an email body than on a web page. The technique with the widest email client support is inline styles. Inline styles also provide the flexibility to make variations in style throughout your HTML message.

For example:
<td style="font-family: Arial,Helvetica,sans-serif; font-size: 11px; color: #313031;text-align: left;">

» Inline styles used for formatting text should be at the beginning of the <td> cell and not on each paragraph section. Style sheet declarations should always be declared inline, in the immediate containing element.

» Inline CSS should also be used instead of <font> tags to cut down on code length. However, if <font> tags are used, they should be used efficiently and at the top of <td> cells, wrapped around all the copy in the cell.

» Never override the user's ability to customize by specifying "!important" in the CSS.

IV. HTML Coding Tips

There should be adequate testing in popular email clients, such as Outlook, Yahoo Mail, Gmail, Hotmail, and AOL. In addition, always check your code in web browsers, such as Internet Explorer and Firefox/Mozilla as well as on both PC and Mac platforms. For more information, go to: www.w3schools.com/browsers/browsers_stats.asp

Make sure all your HTML code has been validated and ensure no nesting errors are present. Improper tag closing will cause rendering errors in many email clients. Most HTML editors include a validation utility. Otherwise, go to www.w3c.org.

Avoid empty lines of code and spaces in between an <img> tag and </td> tag. Some browsers may read this space as an actual space in the overall layout which can lead to misaligned graphics.

Your code should be: <img src="src.gif"></td>

Instead of: <img src="src.gif"> </td>

Replace ASCII characters, such as smart quotes that may be applied when using word processing programs, such as MS Word.

Add ALT tags to your image tags to ensure the viewer knows its content even if the image is broken upon arrival. Using ALT tags also satisfies accessibility issues, conforms to W3C HTML 4.01 specs, and allows the disabled to read and receive their emails.

Forms in emails are not recommended due to inconsistent user experiences and results capturing. However, they may be used if they don't include JavaScript functionality and are not sent to AOL users. Add a text link to the form on a web page as a back-up.

Avoid using <p> tags; use 2 <br> tags in its place.

Relative values for font sizes are important if you are meeting accessibility requirements -- in which case "ems" are likely the best unit. Control of look & feel is likely the most important driving factor, in which case use pixels. See: webdesign.about.com/cs/typemeasurements/a/aa042803a.htm.

Create complete text versions for those who prefer not to receive, or cannot view, HTML.

Avoid using a DTD tag because web-based email systems will replace such tags with their own definition.

Avoid: <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> V. Further HTML Design Tips
Background images and reverse text treatments should be avoided if possible because they will not appear in some email clients, such as Lotus Notes. However, background images can still be used with caution if they are not critical to your message and can be removed without the email recipient noticing the missing image/tag.

Email clients may render default colors differently than web browsers; it may be important to explicitly define color values in order to override defaults.

To prevent loss of background colors specified in the <body> tag, wrap the entire email inside a larger, 100% wide table, and set a background color to that table.

Use one or two different font types maximum, and provide a sufficient list of alternate fonts in the style sheet specification for a given class of text. The fonts should be listed in terms of: desired, acceptable, generic type (e.g., "Arial", "Helvetica", "Sans-serif").

Rowspans will not display correctly in several email clients, including Lotus Notes and AOL. Use a reasonable set of nested tables (3 deep) instead.

Do not use frames or framesets.

Do not comment out code. Unwanted code should be removed.

Place a link in the pre-header to the web version of the email.

Add an "add-to-address-book" call to action in pre-header to improve inbox deliverability. VI. Browser-based Email Compatibility
For up-to-date browser capability information, go to: www.w3schools.com/browsers/browsers_stats.asp

AOL versions 6 and higher will block any emails that link to external style sheets.

Web-based email client shells (e.g. Yahoo!, Hotmail, etc.) are built using HTML, and therefore two body tags appear when displaying an HTML email message. Some clients attempt to resolve this issue by stripping the body tag altogether. Others append the tag with an "x" (e.g. Changing <body> to <xbody>). Both actions result in the body tag becoming null and void. To avoid this problem, include the entire message content in a <div> </div>container and apply body attributes to the "div" instead.

Similarly, email clients like Gmail, Yahoo! Mail, and Hotmail will eradicate styles in HTML emails utilizing CSS and the following tags: <head>, <title>, <meta>, and <body>, so that email designs do not interfere with the settings of their display pages.

If you're using Internal Style Sheets, the <style> tag should therefore be embedded within the two body tags and not within the header. For example:

<body>

<!—

td.maintext{}

-->

</style>

</body>

VII. Navigating Major Email Clients
AOL: In AOL, CSS will not be blocked, and loading time for styles will not be delayed due to hosting server issues. However, a lengthy set of style sheet rules will have a delaying effect on the complete rendering of the email. Forms are not recommended if you are sending emails to AOL users.

Microsoft Outlook: It is common for corporate users to have images turned off by default as a security precaution, and for preview panes to be used. For this reason, it's important to use system text vs. all graphics, and to have clickable calls to action above the preview pane fold. VIII. Animation and Flash
It's better to use Flash animation on the landing page rather than in the email. FLASH requires the use of either the <OBJECT> tag (Internet Explorer) or the <EMBED> tag (Netscape). Both tags are parsed from web-based email programs as there is a potential security risk in allowing their contents. Most recipients will not be able to view Flash in HTML emails because Apple Mail is the only major email client that uses the operating system's built-in browser to render email.

Animated GIF graphics are not supported in Microsoft Outlook 2007. IX. Beating the Spam Filters
Having clean HTML code can help keep an email from being blocked by spam filters. Web publishing software such as FrontPage, GoLive, or Dreamweaver often add extraneous code that is invisible to the user, but spam filters can detect it and may view the sender as a "sloppy spammer." In addition, ISPs may direct emails with missing table tags, content below the closing </HTML> tag, or empty <title></title> tags, into the junk folder.

Additional "spammy" triggers to avoid:

» HTML comments which obfuscate text
» Fonts in the HTML code sized 2+ or larger
» Links without a "http://" prefix
» Colored backgrounds
» Special font colors outside of the 217 "web-safe" color palette Final Thought: Results, not Rules, are the Order of the Day
With all these best practices to keep in mind for your email designs, it's important to remember that these are recommendations, not rules. But, these are some of the safest and most reliable techniques for coding and designing your email messages. Always keep in mind flexibility of design - and testing to back it up. If you must use a questionable practice, test the results first to determine how your list behaves. If the data or sales you receive outweigh potential functionality issues, proceed with caution and enjoy your success!