Most organizations choose to send commercial email messages in HTML format opposed to plain text because HTML allows for flexibility in custom design elements such as fonts, colors, images, and layout components. CSS language is frequently used to accommodate advanced styling in web design, but even the most experienced web designers will find that using CSS in an email template can be difficult. While most major web browsers try to respect certain standards to ensure that web pages appear the way their designers intend, the email clients that will render an email template are far less consistent.
The following article recommends best practices for styling HTML email messages with CSS from code view. Be sure to check out the Additional Resources section at the end of this article for links to helpful online tools.
When sending emails individually via the Emails module, to groups of recipients via the Campaigns module, or by automatic trigger via Admin > Workflows, email templates are responsible for what the message will look like to the recipients. Sugar’s email template composer features a WYSIWYG (pronounced wiz-ee-wig: What You See Is What You Get) interface that enables users to create HTML emails using familiar formatting tools from a design toolbar. For more granular control of the code, users can toggle from this design view to a code view. The code view button is one of the first options on the design toolbar, represented by the letters “HTML”:
- Basic knowledge of HTML and CSS is required.
- You must have access to the Emails module to create regular email templates.
- You must have access to the Campaigns module to create and send campaign email templates.
- You must have administrator access in order to create workflow email templates and workflows.
For more information on these items, please refer to the Role Management, Campaigns, Emails, and Workflow Management documentation.
Here are ten important best practices for styling HTML email messages from code view.
Avoid external style sheets or style declarations between the <head> tags. Instead, use inline CSS. Some email clients strip out <head> and <style> tags from emails, and external style sheets are largely ignored. Therefore, every HTML element must be styled using inline CSS by virtue of the “style=” declaration. Inline CSS is a method of using CSS within your HTML content instead of storing it in an external CSS file. For example, each paragraph of text will have an independent style declaration, such as:
<p style="color:#ffffff;font-family:arial,'sans-serif';">This text is white and Arial.</p>
This is the most basic and important rule of CSS styling in emails, but it is also tedious and repetitive. Thankfully, there are several free tools available online to convert traditionally styled HTML content to inline styles; we have included links to some of these in the Additional Resources section below.
Declare all font styles within the element closest to the words you are styling. This will often be inside the <p> tags. If you want hyperlinks to display in a style other than the default blue underlined style, you must use CSS to declare the preferred style inside the <a> tag.
Avoid layout-specific CSS in the <body> tag. Instead, create nested tables to control layout design. While tables are generally reserved for presenting tabular data in web layouts, HTML design for email requires the use of tables for just about everything when it comes to layout. Ignore what you learned about the evil HTML table and get ready to nest tables inside of tables inside of even more tables. HTML table attributes (instead of CSS) should be leveraged for table design and layout purposes: width, height, bgcolor, align, cellpadding, cellspacing, and border. Limit inline CSS table styles to padding, width, and max-width.
Avoid using CSS inside the <img> tag to position images. Instead, position images using table cells. There are many rules for using images in HTML email templates, but making sure images appear where you intend them to appear will depend on properly nested tables. The only CSS you may need to declare inside the <img> tag is
style="display:block;", which will eliminate unwanted gaps between stacked images in some email clients.
Always use full paths for image links, never relative paths. Unlike traditional web pages that are often stored on a shared file server, HTML email content will be rendered in remote email clients, thereby losing any relationship to local file directories. For this reason, relative link paths like
/graphics/image.png cannot be used. Instead, write out the entire absolute path to the image. Absolute paths will include the website URL before the specific directory location of the image file (e.g.
Note: Unfortunately, not even absolute paths will protect your images from email clients that block the display of images in incoming emails. That is why it is essential to also include a descriptive HTML “alt” attribute inside design-centric image tags. The text defined in this attribute will be displayed for the viewer even when images are blocked by their email client.
Avoid background images. Instead, embed HTML images directly on the page. It is true that some email clients will respect the HTML “background” attributes in the body tag and others may allow the attribute in table cells. However, support for background images is so inconsistent that it is best practice to avoid using background images altogether. If your email design is background-image dependent, it is time to reconsider the design.
Desktop email client usage is diminishing as tablets and smartphones take over. In fact, more than half of all emails opened in 2013 were rendered in a mobile client, and checking email was found to be the most popular activity on smartphones. With such diversity of device size, it is essential to design HTML emails using responsive web design techniques that will adjust content to the screen size of the reader’s device. One of the easiest ways to create responsive content is to use only percentage widths (opposed to fixed pixel widths) for tables, but we have included links to more complete tutorials in the Additional Resources section below.
Because it is virtually impossible to create an HTML email that will render identically in every email client, satisfy the most finicky clients with a plain-text alternative to your message. If the recipient has specified that they only want to receive plain-text email or if the recipient’s email client rejects your HTML version, the plain-text version will be delivered instead. A plain-text message will contain no images or text formatting. It is not the prettiest option, but it will at least ensure that your message is reaching the widest audience possible. Sugar’s email template wizard allows you to craft an entirely plain-text message or to include a plain-text alternative with your more robust HTML email campaign. For more information on creating HTML and plain-text email templates in Sugar, please refer to the Emails documentation.
No matter how many rules you follow, you will probably never get an email message to render identically in all email clients and devices. That is why thorough testing of your message over multiple platforms is essential. Pay particular attention to the email clients that are most popular overall (highest email client market share) and the ones that are popular with your audience. Consider using an email analysis tool or create multiple email accounts for receiving test messages. Remember that any change to the template to accommodate one client may break the design in another client.
Always abide by CAN-SPAM regulations (or the relevant laws in your country). All commercial email messages sent to or from the United States must comply with the law known as the CAN-SPAM Act. Compliance guidelines are exhaustively outlined on the FTC’s Bureau of Consumer Protection website. Some (but not all) of the required message elements to include in your business emails are:
- A message identifying the correspondence as an advertisement
- Your valid physical postal address
- A clear and conspicuous method to opt out of getting email from you in the future
In addition to the CAN-SPAM law, you must also comply with the anti-spam laws of the countries in which your recipients live. For example, if your email subscriber list contains recipients in both the US and Canada, you must check the Canadian spam laws to confirm that your message and sending practices are also compliant for your Canadian audience.
Failure to comply with these laws could result in steep fines and sending penalties including blacklisting of your sending domain. For more information about the CAN-SPAM Act and the spam laws in other countries, please refer to the Additional Resources section below.
- The Ultimate Guide to CSS for Email : Campaign Monitor’s exhaustive list of supported CSS elements for any email client.
- CSS Inliner Tool : Quickly convert <style> declared CSS to inline CSS in your template.
- Email Client Market Share : View the most recent email client usage statistics.
- Can Email Be Responsive? : A List Apart’s rules for designing and developing HTML emails.
- Mobile Email Resources : A collection of tools and resources for responsive email design.
- Web Fonts in Emails : Campaign Monitor’s guide to using web fonts in email design.
- CAN-SPAM Act : The US Government’s official overview of anti-SPAM regulations.
- Email SPAM Legislation by Country : A list of countries that have adopted anti-SPAM legislation.