Home Resources Blog

Whether I’m developing a website or an HTML email, I spend a good deal of time testing. I run my files through a large suite of browsers and email clients, and my process is thorough. There are some things I test for globally and others which are specific to the target audience. In any case, my process is extensive because my goal is to maximize accessibility.

I am often asked how I test emails. This article will outline that process including what I look for when I test, how I test for various viewing scenarios, what techniques/utilities I use for debugging and what email clients I use in my suite. You might recognize the process as part of your own, learn something new about testing or even curse my efforts as useless. I feel that my testing process is efficient and effective, but I’d love to learn something new about how my peers are testing. Comments are a good thing.

My Suite of Test Devices

To ensure my work accommodates people using all of the three most common desktop platforms (Macintosh, Windows and Linux) I have them all at my disposal. I design/develop on my Mac (as I have for over a decade) and have the other two on standby. Because I use a Mac Pro I can run all three platforms on a single computer (I’m running Ubuntu—an amazing and free Linux platform—and Windows XP), thanks to the glorious Parallels application:

[screen shot: Ubuntu platform]

I also test on as many alternate devices as possible. This is most challenging because there are a plethora of mobile devices with an equally intimidating number of browsers and email clients. I do what I can with my Zaurus (Linux), my Treo (Palm OS) and my Blackjack (Windows). And I profusely apologize to my colleagues and friends as I occasionally beg them for test runs on their devices. Quite an annoyance, I’m sure.

My Suite of Test Clients

There is a lot of data to support a general consensus about the most widely used email clients and web browsers, but I also ask around to learn what people are using. This gives me a great foundation for where I should focus my efforts. However, with strict goals for accessibility I test for an extremely broad collection of clients/browsers. Some may call it extensive or even gratuitous, while I call it thorough and considerate. My suite of encompasses the following clients:

Mac OS X

Apple Mail 2.1
Entourage 10.1

Windows XP

Mozilla Thunderbird 1.5
Outlook 2002
Outlook Express 6
Eudora 7
Lotus Notes 6.5


Evolution Mail 2.8
Mozilla Thunderbird 1.5


Yahoo (original and new beta)
Windows Live Mail


Palm Versamail (Treo smartphone)
Linux EMail (Zaurus PDA)
Outlook (Windows mobile)

Deployment of Tests

For Campaign Monitor customers who are logged in to the admin system, sending test emails is effortless. Simply navigate to the “test campaign” utility under the “create/send campaign” tab, enter the basic information and you’re set:

Sending a test in Campaign Monitor - updated

I point all of the desktop/handheld clients in my suite to an IMAP account which I’ve created solely for testing. This enables me to send tests to a single address, then view the results across the board. Webmail accounts, however, are unique and consequently need to be tested individually. But the aforementioned test utility allows concurrent delivery to three addresses. So testing in six webmail clients is still simple and quick.

Through countless tests I have learned (as we all do) what general markup will succeed and fail in various clients/browsers. This knowledge enables me to send an initial test which most often works fairly well across the board, sans a handful of unanticipated hiccups. Then, as I work to resolve the complications, the testing suite dwindles until I am satisfied with the results in each client. Campaign Monitor’s test utility enables me to quickly resend tests, and the IMAP setup enables me to view the results only in clients needing attention.

My Approach to Presentation

There are two fundamental ways to markup the presentational layer of an HTML document, each having its own benefits/compromises: standards-based CSS for all presentation, or table-based layouts which envelope font/color tags for text formatting. From my perspective, there is no contest between the two approaches. However, for those less educated about the pros and cons I’ll outline the basic concepts.

Font Tags and Tables

While this approach offers a fairly consistent visual presentation across most email clients, it comes at a high price:

  • Embedded presentation layers weigh down an email, slowing down rendering times for mobile devices and people with dial-up connections and increasing fees for people using pay-per-kilobyte mobile plans.
  • Table-based layouts render horribly on small-screen devices and are nightmares for disabled readers who must navigate using key/verbal commands.
  • Table-based layouts are challenging to integrate into CMS solutions and to segment for templates.
  • Redundant, inline presentational-markup complicates maintenance.

Standards-Based CSS

While web professionals are increasingly adhering to web standards, the debate about using them for HTML emails is still quite fiery. And because of my articles on the topic, I’m typically a target for misinformed, plain-text-email evangelists. The benefits of web standards in the email environment is no less impactful than on websites. If anything, they’re more important because of the increasing number of people using mobile devices to access email.

The benefits of using web standards to mark up emails is obvious:

  • Reduced file sizes are considerate of mobile readers who pay for every kilobyte they download and for people using slower dial-up connections.
  • The content is accessible to everyone, is fluently read by aural devices and is easily navigated by those using assistive devices.
  • Clean segmentation enables easy integration with CMS solutions.
  • Presentation is maintained in a single location, ensuring global changes are quick and simple.

There are a couple of compromises one must accept when using CSS for presentation:

  • Visual design is reduced to something, not unlike a rich-text format in some clients.
  • Formatting is lost when forwarded from many clients.

A Word to the Wise

Irrespective of my stance on this debate, there will always be a client who believes design integrity across the board is significantly more important than accessibility or catering to a mobile device audience. Consequently, I have learned that it is vital to discuss these approaches with my clients before engaging in a project. Failing to have this conversation up front will inevitably result in hearing a client say “this doesn’t look good in Hotmail” or “when I forward this from Outlook, the formatting is lost.”

My Goals

There are many viewing scenarios to consider which vary more wildly in the email environment than within web browsers. This is primarily because security and spam are of great concern in our inboxes, but also because of the increased use of mobile devices. I believe my approach to preparing for each of these scenarios yields appropriate results across the spectrum of clients. I have specific goals for each scenario—all focused on accessibility—and test for these specific results accordingly. Following, are some of these specific scenarios.

Text-Only Clients

Many people use non-graphical email clients, especially in the mobile arena. These clients either display the plain-text segment of a multi-part email or extract text from the HTML. Take a look at how Lynx (popular non-graphical browser) renders HTML into a text-only presentation:

[screen shot: email in text-only format]

Note how there is some formatting which helps the reader distinguish headlines (flush left) from paragraphs (indented). This is possible because the headlines are marked up appropriately with H1, h3 and P tags. Font tags and tables would produce something much less readable. Also, note how I compose ALT text, using all-encompassing brackets. This is something I do by default to help readers distinguish ALT text from regular content when viewing HTML sans images. And I prefix ALT text with a description of the image (in this case “photo:”), which denotes what type of image has been omitted.

I test for text-only presentations using Lynx, Palm VersaMail and Linux EMail (default email application on my Zaurus handheld).

Disabled Images with CSS Support

Images can be manually disabled, and are disabled by default in a handful of clients. As David Greiner brings to our attention, Epsilon Interactive conducted a study which reports how 30% of our recipients may not even know images are disabled. My approach to image integration is pretty simple, I use CSS backgrounds for all images which are part of the core visual design and only use embedded images (<img>) for contextually relevant images.

The big challenge surfaces when images are disabled in a graphical client that supports CSS. In this scenario, CSS-background images would disappear leaving no ALT text. However, there is a solution to this problem which I outline in another article. I believe it yields acceptable results:

[screen shot: email with images disabled and CSS enabled]

The title of this email, “Digital Web Magazine,” is exhibited with an image of the publisher’s logo. With images disabled in a client that supports CSS we retain visibility of a title. Perfect.

I am able to easily test how my email will appear with disabled images using an amazing Firefox extension which is invaluable even beyond testing for disabled images. I highly recommend it for every web designer.

HTML Capable Clients with no CSS Support

Many HTML-capable clients do not support CSS. In this scenario, CSS shines bright. “Why?,” you say. “It’s gone.” I use CSS for my entire presentation and semantic markup for the content, so when the CSS is removed from an HTML document the result is a readable email, visually similar to that of a rich-text document:

[screen shot: email with HTML formatting and no CSS support]

This is where those seeking pixel-perfect designs across the board begin to recoil in horror. I feel this is an acceptable sacrifice to ensure accessibility for everyone, though many clients would disagree. And this is where the aforementioned pre-project discussion will come in handy. My clients are prepared for this scenario, safeguarding me from a mid-project debate and potential situation requiring me to recode an email using font tags and tables.

Testing for this scenario is simple using the aforementioned Web Developer Extension for Firefox, wherein CSS can be disabled with a single click. But it is advisable to set up Hotmail and Gmail accounts for real-world testing. Both of the said webmail clients support HTML and disable CSS by default.

Screen Readers

Aural devices obviously ignore all visual design. But that doesn’t mean all visual elements disappear completely. For example ALT text and link titles are read aloud and lists are denoted as such. Thus it becomes obvious just what kind of impact our markup can have on a visually-impaired reader.

Testing for aural devices is incredibly challenging because they simply aren’t widely available without paying significant license fees. The popular screen readers on the market are well worth their weight in gold to those who need them, but for developers the expense can be intimidating. However, there is an open source screen reader available for the Linux platform called Emacspeak. Thanks to the aforementioned Parallels application and respective Ubuntu Linux-platform on my Mac Pro, this is what I use to hear my websites and emails.

Spammers and Standards Compliance

I would like to conclude this article with a note about the deployment of mass emails, just so we’re all clear on my intentions.

I have written a handful of articles about techniques for successfully deploying standards-compliant emails. Consequently, I have been labeled a “spammer,” an “email marketer” and outright “evil” in blogs around the web. I have also received some emails exhibiting a level of anger I would expect if I were clubbing seals. And the debate about whether or not we should even have HTML emails fuels the fire for these evangelists.

My articles are intended to help legitimate companies send legitimate emails to an audience of subscribers. Permission-based email deployment is not evil and spammers do not take the time to ensure their emails are standards-compliant. I welcome a debate about use of HTML in the email environment, but I would like to ensure that my intentions are not misconstrued.

I have clearly outlined the importance of CAN-SPAM ACT compliance, do not work with clients who disregard the importance of a permission-based email-communication system and do not support the use of rented lists for mass marketing. The benefits of web standards are clear, and my hope is that this information will encourage people to accompany their standards-compliant websites with standards-compliant emails.

I’ve said it before and I’ll say it again: if we have to build HTML emails, we may as well do it right. I am willing to go the extra mile to ensure accessibility—how about you?

  • Damien Buckley

    As we’ve come to expect, a great article from Mark. Its always a useful exercise to gain some insight into the working methods of others’. I’ve always worked with pure CSS designs for email – more from the fact that I learned web design that way and didnt see the point in going backwards than anything else. Along the way I’ve adopted the image replacement techniques Mark outlines not only into my email designs but also into my websites too as IMO clearly they are the most technically sound and accessible. Some interesting points here, particularly with regards to how you’re formatting alt text etc and the diversity of platforms you’re testing on Mark. I notice you’re testing several clients across both Windows and Linux and I’m curious as to whether you see much difference between say thunderbird Windows and T’bird Linux for example?

  • Cheshire

    I would love to design my emails using CSS, but I feel like I have so many readers using Hotmail and Gmail that a majority of my readers would just end up with degraded, unpretty emails. So I suffer through the limitations of HTML because that seems to me to be the best way to reach most of my audience the way I’d like.

    The one thing I see that I lose in doing my emails the way I do is that I lose the graceful degradation of semantic markup. I am sorry to lose it, but I feel like the alternative is worse. I try to format my text-only versions to make up some of the difference. I really can’t wait until CSS in email is widely accepted, though.

    On another note: I’m confused by the mobile question. I have a Treo 600 and use SnapperMail to read my email. Since I send a text-only message along with my HTML emails, that’s what I get on my mobile mail-reader. I don’t recall ever choosing to view text-only emails — are there that many people who by default on their mobile devices have to suffer through poorly displayed HTML emails? That sounds odd to me.

  • Cheshire

    Sorry, forgot to also say that despite my resistance, I do appreciate all the information about techniques and strategies. It took me a couple of years to start coding all my websites in CSS/XHTML — I’m sure I’ll get to the same place with my emails eventually. ;)

  • justinas

    Usefull article. Thank you Mark!

  • Mark Brownlow

    Mark, just wanted to say what a pleasure it is to read your posts. With so many superficial articles floating around on aspects of email marketing, it’s great to see somebody take the trouble to go into the real practical detail of design. I’m in awe. Many thanks.

  • Phil McClure

    It seems like you’ve put a lot of effort into crafting these emails. Unfortunately, due to the abuse by spammers of html emails, I’ve automagically re-routed every html-laden email to /dev/null. Which is a shame since there are obviously a minority of people who do use html-email for legitimate purposes.

    You might want to point out to your readers that it would be wise to offer a “text-only” alternative to subscribers, as there are many people out there who feel the same way I do about html-enabled email.

  • John C.

    Are there techniques that help to prevent emails being marked as spam? I think this is the biggest problem with sending out legitimate mass emails.

  • Chris

    For text based browsers send two parts to the e-mail: one is text/html; one text/plain.

    Can you’re fancy website do that?

    Then when you create your text/html you use some old style font tags and table tags with all the attributes on the tags (I find it’s more effective if you set it up in CSS first, then use find and replace).

  • Sports Online

    Step 1: Just save it in to text file and save it as testemail.html,
    Step 2: Open the file in your local browser.
    Step 3: Send it by e-mail to yourself and see if it looks ok.
    Step 4: Send the e-mail out.

    Simple enough?

  • Scott Karlin

    I agree with Phil and Chris. I generally don’t read html-only e-mails that arrive in my inbox. If I do, I read them as text — that is, I read the html source. While not critical for html that will be interpreted by computer, it would be nice if the html source were formatted to be human-readable: no long lines, indented nicely. This will help with debugging as well.

  • Trevor

    Great article, Mark.

    I with Mark that CSS is definitely the way to go for fully-designed e-mails. The client I use lets me specify a text-only message for people whose clients won’t read HTML messages, so I get the best of both worlds.
    I think it’s crucial, as Mark notes, that you make sure your mailing list is composed of your opt-ins only, so that they’ll know to put in their trusted list of mailers and not have you automatically routed to the trash bin.

  • Denver Computer Consulting

    This was a great article, many people “try” and use HTML email and have no clue what they are doing. Keep up the good work.

  • Cory Duncan

    Mark, as usual you fail to disappoint. Great points all around, especially on the text-only browser formatting – I had no idea to what extent the text-only browsers used semantic markup for formating.

    Happy Holidays to you and yours!

  • Chris Butler

    There was an interesting article on O’Reilly Radar about a company that would appear to be addressing the mobile testing issue you bring up:


    For $199 a month that isn’t too bad for a site that needs to constantly validate their newest stuff on lots of phones and even between phones…

  • John

    Another very useful and well written article, thanks. For those affected, the plethora of mobile devices and non-desktop-like browsers is going to make life very difficult. Even if we opt for 80/20, can we even reach that, and will clients accept that many subscribers will get a poor experience? Perhaps list managers need to try to capture the likely reader. If you feel you can’t ask questions at subscribe time, maybe the welcome email should have a section allowing the new subscriber to indicate if they are using a handheld etc. Perhaps offer them something extra, and maybe repeat this in an annual mailing if the list has such a thing. At least then you would get some indication of device penetration.

  • Matt Williams

    I couldn’t be sure looking at your list of XP test clients whether you are on the Windows Live Mail Desktop Beta – if you want to join I can issue you an invitation – use my contact form.

  • Bill NZ

    I wish I had the flexibility to be able to design with pure CSS, but most of our clients are design agencies who believes that pixel-perfection is more important than anything else.

    My approach to make the design survive the majority of clients is to use tables for layout, and inline-css for formatting of text and padding/margins. I would also use float/clear on divs for images that I wanted text to flow around (usually because if I just use the “align” attribute, the client would ask for a caption on the image). But the new Outlook 2007 makes even this impossible. This means that I will have to put the caption as part of the image, and put the caption in the alt attribute for accessibility. And I thought Hotmail was a pain…

  • Jeremy

    Great article. Covers everything. I love everyone’s comments too!

    The issue for me is that the decision of using CSS or Tables is MINE, and I see benefits on both sides. The emails I send are for my own projects, and even when it is for clients, they really do not know what the right choice is.

    For CSS, the benefits are clear. If I had my way, I would stick to this so that finally I am creating websites and emails the same. But anyone I work with would freak to see that in Gmail, and few care about mobile web clients. Many would be upset at losing the formatting from forwarding the email.

    For inline CSS and tables, I see keeping formatting from a forwarded email as a good thing that business people expect, and Gmail seems important in all environments non-corporate, which is a lot of folks these days.

    I am also confused on one big point. I have always sent emails in both HTML and Text. I thought that would be how I cover my bases across the board when HTML did not function. Would anyone say this is bad thinking?

    I agree that it depends on the targets of the project. But for now, I vote Tables/inline CSS when the decision is mine.

  • Rachel

    These are some great tips, thanks! You have quite the elaborate test process, but it’s admirable.

    When it comes to the “formatting shock” that some clients go through when they see their emails on a different client, here’s how I see it.

    Although the formatted, graphical HTML email is nice and professional, the content of the message is more important than anything. If your recipients are seeing the content and it makes sense, the email has done most of its job. The content should certainly be able to stand on its own without the graphics.

    I believe a lot of the shock clients go through when they see their emails without formatting has more to do with expectations than anything.

    Say your client is using Outlook. They are accustomed to seeing HTML emails a certain way (and mostly intact). All they know is that if they received an email that looked like the unformatted version they saw in Gmail, they would think it’s poorly designed. What they may not realize is that people who use Gmail are very used to seeing the stripped down HTML result because they use it regularly. I use Gmail, none of the HTML emails I receive ever look that great but even as a designer, I’m ok with that because it’s the content I want to read.

    I also get ads from several large retailers, they are always composed almost entirely of images. Most of these I never read, unless the subject is compelling enough to make me turn on images.

    I guess my point is, all I want to do when I get an email newsletter is to read a clear message. While no client is perfect, I think in a lot of cases all they need is some education about the futility of trying to control every pixel (at least with the way things stand now), and to embrace the limitations of email. Otherwise, God help them when the new Outlook comes out…!

  • Mark

    I so wish I could desing like this. Unfortunately, for most email marketers the most important part of designing html email us getting as many click-throughs as possible. Perhaps there should be a test done comparing click throughs on Tables V Standards Based code. Of course this would vary greatly depending on the audience.

    My boss wouldn’t be too amused if he thought our users were reading ‘something not unlike a rich-text format’

  • Stephen Rider

    Just FYI —

    When you do your ALT attributes with brackets, e.g. “[photo: girl kissing library card]”, you should be aware that screen readers will read out the brackets, thus:

    “open bracket photo, girl kissing a library card close bracket”

    With one image this is not big deal, but… I was informed of this by a helpful person when I had a site with graphical buttons on a interface, thus about five such “open bracket/close bracket”s in a row!

    It was recommended to me that the brackets be left off. Personally, in the example you give I would just put in an empty alt attribute (alt=””), as that image lacks needed content.

  • Garrin


    You are a saint! I can’t understand for the life of me why it is so difficult to find information on designing HTML/CSS emails. Every HTML/CSS resource I’ve found, in the bookstore or otherwise, deals with the subject of designing for websites, and is limited to websites only. Websites don’t have to deal with DELIVERABILITY, a major concern for email marketers like myself. Not to mention the numerous other issues you address – CSS Support in Email, etc.

    Thank you for providing such a wealth of information. If you published a book on the subject I’d place a bet that it would do very well.

  • Tom

    Mark, as usual you fail to disappoint. Great points all around, especially on the text-only browser formatting – I had no idea to what extent the text-only browsers used semantic markup for formating.

  • Evelyn

    I couldn’t get the templates to work

  • Domki pod sosnami

    This figure was never set in stone and really depends on what email environment’s your recipient’s might be using.

  • Keri Russel

    Even if we opt for 80/20, can we even reach that, and will clients accept that many subscribers will get a poor experience? Perhaps list managers need to try to capture the likely reader. If you feel you can’t ask questions at subscribe time, maybe the welcome email should have a section allowing the new subscriber to indicate if they are using a handheld etc.

  • bet365

    All they know is that if they received an email that looked like the unformatted version they saw in Gmail, they would think it’s poorly designed. What they may not realize is that people who use Gmail are very used to seeing the stripped down HTML result because they use it regularly.

This blog provides general information and discussion about email marketing and related subjects. The content provided in this blog ("Content”), should not be construed as and is not intended to constitute financial, legal or tax advice. You should seek the advice of professionals prior to acting upon any information contained in the Content. All Content is provided strictly “as is” and we make no warranty or representation of any kind regarding the Content.
Straight to your inbox

Get the best email and digital marketing content delivered.

Join 250,000 in-the-know marketers and get the latest marketing tips, tactics, and news right in your inbox.


See why 200,000 companies worldwide love Campaign Monitor.

From Australia to Zimbabwe, and everywhere in between, companies count on Campaign Monitor for email campaigns that boost the bottom line.

Get started for free