5 Challenges to Expect When Doing HTML Email and How an Agency Can Help

Mike Maier
Mike Maier VP of Solutions & User Experience

If you ever want to mess with the developers at your digital agency, mention that you’ve got plans for some new HTML email marketing initiatives. Then, sit back and listen for them to let out a sigh, watch their shoulders slump as they look to the floor, and notice how you can see a little part of their soul disappear through their eyes.

You’re probably thinking: What’s the big deal — I send and receive tons of email daily, surely this shouldn’t be cause for distress? But, here’s the truth: Doing HTML email marketing the correct way is a painstaking process filled with challenges you may not be aware of. Let’s look at five such challenges.

5 Challenges: HTML Email

Building a Good List

A good list is the foundation of every successful email campaign. But more often than not, lists are gathered incorrectly, setting up the entire campaign for failure. Believe it or not, you can’t just add any email address you want to your list and send it your emails. You by law (and by heavily enforced rules of nearly all if not all email send programs) need permission to send to an address, and the way we do that is via opt-ins. This means that the person consents to receiving your emails. There are 2 basic ways to opt-in to an email list:

  1. Single Opt-in: Many times this is done by adding a checkbox to another form on your site with messaging that the person will be added to your list. Checking that box and submitting the form gives you permission to send.
  2. Double Opt-in: This method takes it a step further. After an address is given, an email is sent to that address requiring the user to click a link to confirm they want to be added to your list. This method goes much further to validate the person actually wants to be added to your list.

This is important, because if your list is filled with bad email addresses or addresses from those who did not want to be added, you’ve got a bad list. A bad list will lead to high bounce rates and increased spam complaints, and will hurt the sender reputation (more on that next). In the end, the size of the list is not nearly as important as its quality. A good list will lead to better engagement and higher success. A huge bad list just means you’re sending to more people who don’t want your email or who don’t ever actually check that email address (if it even exists).


2. Sending Score and Reputation

In an attempt to limit spam, ISPs will look at the domain that the email is sent from and evaluate its legitimacy. Sending Score and Reputation are how it will decide if your message gets delivered or not.

A couple of factors you should be aware of are:

  1. Domain Signature: This is where the IT department comes in and can be a hurdle to sending success. In order to verify that the sending domain is in fact what it claims to be, the domain need to be verified through some extra DNS records. Those records are typically an SPF record, DKIM record, and occasionally a txt record and or CNAME record. That’s a lot of acronyms and if you don’t know what that stuff is, it’s okay. The important thing is that, when you are asked to have these things set up, you pass them along to the appropriate people and make sure it gets done.
  2. Bounces and Complaints: These are logged against your domain and contribute to Sender Score. Too many spam complaints and/or too high a total bounce rate and you are likely to get blocked even with the appropriate Domain Signature. This is why a good list was number 1. The best way to sabotage your email campaign is by starting with a bad list.


3. Email Client Render Engines

Once you have a solid foundation to send, you need to consider who and what you are sending to. There are many different types of devices out there all running different email programs. And of these different email clients, there are different rendering engines. Rendering agents control how the email is displayed and they are not all created equal, which causes problems when trying to get your message to display consistently. What this means is that your email could look perfect to one recipient and appear entirely broken to another.

Common email clients and their rendering agents

  • Outlook 2007, 2010, and 2013 use Microsoft Word (really, not kidding).
  • Outlook 2000, 2002, and 2003 use Internet Explorer.
  • Apple Mail, Outlook for Mac, Android Mail, and iOS Mail use WebKit.
  • Webmail uses the browser’s respective engine, which are also all different per browser.


4. Coding Hurdles

This is a big one, and the reason the developer may be curled up in the corner. On top of the various render engines comes their lack of modern advancements. This means the state of email development is stuck somewhere in the mid-90s. Many of the techniques we rely on to build today’s web are not available to us as we build HTML emails. The problem can be compounded by the speed in which browser-based design advances. Depending on the age of the developer, they may not have ever lived through a time where TABLES were used for layout purposes. This is sort of like handing a rotary phone to a teenager and telling them to make a phone call. While technology is starting to catch up, here are some common constraints to be aware of as your developer is pushing for a more simple approach to email.

  • Table-based layouts: As previously mentioned, in order to get any kind of structure that will work across all the various email clients, we must rely on tables, a technique that has long been extinct in modern web development.
  • Inline CSS: The CSS controls the look of your structed email — sizing, spacing, colors, etc. In modern times these rules are compiled in a separate file and added once to the HTML document. Again, because of archaic email clients, we must instead use inline CSS. This means there is no reusability. The rules must be applied to each specific HTML element each and every time they are needed. This creates a much longer development window. Luckily, there are ways to automate this process, but even then there can be problems.
  • Limited font choices: Because of the poor CSS support, we must rely on device fonts, and because we have so many different devices, we are even further limited in the amount of fonts available to us that will likely work on everyone’s device.
  • Conditional Coding: This means writing different blocks of code specifically for each email client (such as Outlook 2012). When doing many conditions for many clients, this can become very time consuming.

Code Example

To illustrate the difference in building for the modern web vs. HTML email, let’s look at something as simple as a button, one of the most commonly used elements in HTML emails. First we’ll look at how it would be done for a regular webpage and then how it would be done in order to have the best chance of looking similar in all email clients.

Modern Web

[html]<a href="#" class="button">Click Here</a>[/html]

HTML Email

[html]<table border="0" cellpadding="0" cellspacing="0" class="button" style="border-collapse: separate; mso-table-lspace: 0pt; mso-table-rspace: 0pt; width: 100%; box-sizing: border-box; min-width: 100% !important;" width="100%">
<td align="center" style="font-family: sans-serif; font-size: 14px; vertical-align: top; padding-bottom: 15px;" valign="top">
<table border="0" cellpadding="0" cellspacing="0" style="border-collapse: separate; mso-table-lspace: 0pt; mso-table-rspace: 0pt; width: auto;">
<td style="font-family: sans-serif; font-size: 14px; vertical-align: top; background-color: #cccccc; border-radius: 5px; text-align: center;" valign="top" bgcolor="#cccccc" align="center"><a href="" target="_blank" style="display: inline-block; color: #ffffff; background-color: #cccccc; border: solid 1px #999999; border-radius: 5px; box-sizing: border-box; cursor: pointer; text-decoration: none; font-size: 14px; font-weight: bold; margin: 0; padding: 12px 25px; text-border-color: #99999;">Click Here</a></td>

Layout and inline CSS include special rules for Outlook’s quirks vs. a simple line including one tag. And now you know why the developer is curled up in the corner.


5. Mobile

Once we’ve worked through all that, let’s throw in the fact that more and more email is being read on mobile devices, giving us a new set of email clients and devices to worry about. In modern web design we use responsive techniques to build websites that can display on any device and with some extra work we can do the same with emails. But there are some restraints. Different email clients, again, support different coding techniques. Testing increases as the amount of target devices increases. And new layout constraints are introduced as mobile emails generally work best in a single column format.

Because of this, the general recommendation has become to keep emails simple and one column in nature whenever possible, as these types of emails generally transition from desktop down to mobile with the fewest issues, target the message, and reduce some amount of coding and testing.


As you can see, there is a lot that goes into a successful email campaign, and while the thought of sending and receiving emails seems pretty simple, there is a lot of planning and work that goes into doing it right. Because of this, it’s important you rely on your vendor for guidance to ensure your email’s success. Email marketing is a powerful tactic and we highly recommend it, just give your developer a comforting cup of tea and some time to work through his ro her email demons.