The dangers of HTML email

Recently, HTML-based email has enjoyed somewhat of a renaissance with some of our clients. In principle, these seem like a nice idea – cheap, branded, marketing directly in to an inbox. In reality, it’s not quite that simple.

The purpose of this post is to outline some of the issues that we believe are worth flagging up to clients before they go down this route. This isn’t a definitive list but should be useful to anyone wrangling over this issue:

Multipart emails [1] (the preferred file format for HTML emails) are often rejected by mail servers as spam or potential virus threats.

A lack of proper CSS support often results in Multipart emails having a rather large filesize. This is certainly something you may want to consider if any of your target audience are going to be using dial-up connections. There’s also a potential accessibility issue here as developers are forced to use outdated techniques that may cause problems with screen readers.

Microsoft Outlook – the world’s most widely used mail client – will not display images in HTML emails by default as it recognises these as potential security risks. This results in a rather ugly message:

Right-click here to download pictures. To help protect your privacy, Outlook prevented automatic download of this picture from the Internet.

…and an empty space where the image should be.

Webmail clients such as GMail, Hotmail and Yahoo! Mail rarely display the mail as intended. This is because they are forced to remove or reinterpret bespoke CSS styling in case this supersedes the styling within the client itself.

9 times out of 10 forwarded HTML emails will lose all their styling and become an unintelligible combination of code and content. This is because the mail client itself encodes the mail and not the mail server itself. This isn’t always an issue, but is certainly worth highlighting to any clients considering HTML mail as a viral marketing tool.

Mailing lists

More often than not, HTML emails are the intended format for mailing list subscribers. If this is the case, clients should be made aware that they will then need a range of supplementary services to support this that go someway beyond ‘a simple HTML page’ [2].

Firstly, the ability to unsubscribe is a legal requirement. To support this service, your site will need an unsubscribe and confirmation page(s), but more importantly this will more-often-than-not need to be managed via a database or some kind of administration tool. Obviously at this point development costs are likely to rise significantly.

OK, HTML emails suck. Is there an alternative?

It’s not that bad. The purpose of this article is not to dissuade people from using HTML formatted mail but instead raise some of the factors that are worth considering before doing so. One thing is for sure, it’s not a simple exercise and certainly not something that can be knocked up in an hour’s work.

If you decide to go down the route, following a few simple rules will help:

Assess whether HTML is actually necessary. As long as the content is good enough, a plain text email can be just as effective and you won’t have any problems with consistency. Alternatively, If the appearance of your message is important why not put the page on your website and send the link instead?

Keep the page simple. Heavy, image based-layouts or multiple columns are often a cause for concern. A far better option is to go with a simple header, followed by body, followed by footer.

Summing up

Consider your target audience and if this includes any of the problem areas outlined above weigh up the possible alternatives and real costs before proceeding.

Multipart mails allow documents to be divided in to more than one content type. Typically emails are divided in to an HTML and a plain text version. The advantage of multipart is that users of mail applications that do not support HTML are shown a plain text version and therefore are not not disadvantaged. Wikipedia has more on Multipart.
This needn’t be a bespoke application . There are plenty of off the shelf list management tools out there.

So far one person has argued with us about ‘The dangers of HTML email’. Read what they've said and then add to our woes using the form below.

Michael Barrish · Wednesday 24th May at 18:57

I’ve been diving into the muck of HTML emails and have learned quite a bit from the folks at Campaign Monitor, particularly this article.

Now, though Campaign Monitor has a vested interest in people buying the idea of HTML emails, they go out of their way to point out some of the pitfalls (though they wisely skip the screenshots from Gmail, etc.). I’ve used their articles as a basis for some HTML emails do’s and don’ts.

In sum, HTML emails can be done, although one must be very careful and test extensively. Personally, though, I agree with your point about keeping it simple. If I wanted to send emails like this for my own company, I wouldn’t go the HTML route.

Thanks for the helpful article.

Love what we’ve said? Think we’re talking nonsense? Don’t worry about being polite, just let us have it. We’re not afraid of telling you that you’re talking crap, so don’t be afraid of telling us the same.