The HTML vs. text e-mail dilemma

Published on .

Reprints Reprints

Most Popular
So, you've purchased an expensive e-marketing software package. As you design your first program, a system administrator brings up an interesting question: Is the message going to be in HTML or text format?

At a glance, the decision looks easy. You have seen both, and HTML is far more appealing. The problem is, not everyone can read HTML messages.

But you've thought of that. You purchased software that could support both versions, via multipart MIME (multipurpose Internet mail extensions). You're all set, right?

Wrong. Multipart MIME works in unpredictable ways. When you use the multipart MIME protocol, both text and HTML versions of the message are sent out. It is up to the recipient's e-mail system to determine which version of the message will be received. Some systems can only receive one version or the other. Others let the administrator choose what type of messages to allow so that companies can limit the disk space their e-mail systems use.

One of the leading e-mail systems does not choose the text version of the message when HTML has been turned off, as you would expect. Instead, it strips all of the tags out of the HTML version, creating very unpredictable results. To confuse things more, there are not just two types of messages, HTML and text; there are actually many more. For example, older versions of America Online support a proprietary "rich-text" messaging format that is quite different from regular HTML.

So, what should you do? These guidelines should help minimize unexpected results:

• Determine which type of message recipients prefer, and store that information on their profile. Give your audience a way to update their profile via personal portals.

• Send text only to people who have requested text and HTML only to people who have requested HTML. Use multipart MIME when you don't know. Don't worry, you didn't waste your money on this software feature; it is still the best way to send messages if you don't know the preferred format.

• When using multipart MIME, use different links in your text and HTML versions. Hopefully, you are already tracking click-through rates by recipient. If you use different links, you can tell which version recipients have received even if they don't know themselves.

• In the HTML version of the message, precede the message with comments in the code. You may have received a message in the past that says something like: "If you can read this, you have received the incorrect version of this message. Click here to update your profile." What you are reading is a comment in the HTML code.

Another approach is to put the full plain text version of the message in the beginning of the HTML version, as a comment. This way, at least your message is readable. In either case, make sure to include your "unsubscribe" text in the comment. If the message recipient cannot read the unsubscribe directions, you have not provided them with an opt-out option and you may be guilty of spamming. This practice will protect you against those numerous e-mail systems that strip out HTML tags instead of using the text version of the message.

Remember, building a dialogue with your customers and prospects should be your goal. If you don't know what your message looks like, it may be difficult to tell how it is perceived. Eventually, standardization across e-mail systems will make the process simpler. Until then, these steps should help.

Kirk Hanson is director-technology solutions at BeNow in Wakefield, Mass., a provider of b-to-b e-marketing solutions. You can reach him at

In this article: