October 30, 2017

What to Look For When Your Emails Aren’t Rendering Correctly

Trevor on October 30, 2017 in Inside Tips

We’d all love to pretend that our emails are stunning right out of the gate, that we don’t make trivial mistakes in coding the emails that leave us scratching our heads, and that the first version of every email we create has a click-through rate of 75%. But, unfortunately, we all know that that’s not the case.

What is the case is that our emails are often riddled with mistakes and that it can take us hours to unravel the underlying causes of our emails’ problems. That’s without the difficulty that comes along with automated and personalized emails, which introduce a raft of problems all their own.

So, to help you streamline the process of identifying, debugging, and rectifying the issues you run into, we’ve put together a guide on email rendering and how to use knowledge of the rendering process to your advantage.

What Is Email Rendering?

First, let’s start with the basics: what is email rendering? Well, as you may know, every email client has different standards for how they display emails. This is because each email client uses a different rendering engine, which is the name for the software that turns your code — ie. renders it — into something visual and human-readable.

These rendering engines take the CSS and HTML you’ve written for your emails and decide how they’re going to display it. Will they accept every CSS attribute you’ve written? Will the layout you’ve created in HTML be acceptable to their engine? What about the images: are they in the right format? Each of these questions, along with hundreds of others, is answered in milliseconds by the email client’s rendering engine. Along the way, the engine strips out parts of the code that are unacceptable, such as embeds, <iframe>’s, and any Javascript code. These interfere with the operations of email clients, so they’re just a no-go from the start.

What to Look For When Debugging Email Rendering Issues

This then leads us to the big issue: due to the fact that no two email clients have the same rendering engines, leading to an endless list of rendering problems.

Are the Issues Only Appearing on One Email Client?

When you’re debugging your emails, start by first looking to see if your emails are rendering the same (or similarly) on your target email clients. If you’re sending an email to Gmail and you see a bug, you may begin to wonder if the bug is the result of an idiosyncratic issue that exists only in that email client, leading you to further worry that you’ll need to identify a rare issue and spend hours coming up with a one-off custom fix.

However, what you may be missing is that the bug may exist in multiple email clients. Not only does this help you identify the bug — it’s likely a syntax error at this point — but it also helps remove the anxiety around discovering a bug in the first place. That’s why we always recommend checking your test emails in multiple clients before writing down the actual bugs to be fixed.

Did You Inline All of Your CSS From Your Latest Version?

One of the most common mistakes we make when creating new CSS-heavy emails is to not properly inline the styling. This is the result of a common process in email creation. First, we create the structure of the email using nested tables, then we add the high-level styling, and finally, we add the specific styling needed for every element. Typically, we write the CSS in one place and then use a tool like Mailchimp’s CSS Inliner to combine the CSS and HTML together in a format email clients will read correctly.

However, what’s often missed is that when you go back in and make edits to your CSS code, you may be doing it on the individual element level (such as changing the font-size on a specific line of text). What you may not realize is that by doing this and then not propagating those changes throughout your email’s code using your original process, you can introduce unexpected bugs and rendering issues.

Is Your Email Service Provider Changing Your Code?

An issue that can occasionally come up without you noticing is that your Email Service Provider (or ESP) can be changing the code of your email without you realizing it. Some of the largest ESPs include Marketo, SendGrid, Mandrill, and similar industrial level email senders. These are massive providers that all have very specific restrictions and features in their platforms.

Without noticing it, you may accidentally put text into your email that causes it to render incorrectly. For example, a common feature in ESPs is the ability to add personalized tokens using stand-ins such as {{First Name}}. These are very useful, but the special characters “{{“ mean that if you were to accidentally put those symbols in your email without intending to activate a token, you may end up causing serious rendering issues. This can be a particular problem in programmatically generated emails.

Are Links Being Formatted Correctly?

Like with personalized tokens, links can cause big issues if entered incorrectly. This can be as simple as a typo, but a more common issue is that you’ve been developing an email on your desktop and have all the images referenced locally, in file paths like, “…/img/img_0048.jpg”.

This can be a big issue when you try to port your locally developed email over to a production server, not just because you need to bring the image with you, but also because all images need to be universally and publically accessible to be seen by the vast majority of email clients. While you can attach images to emails, this is a great way to get your emails sent to a spam folder, meaning that your images need to be referenced using a simple public URL.

Common Ways to Avoid Rendering Issues

There are a few reliable methods you can use to avoid some of the most common rendering issues, assuming you aren’t trying to reinvent the wheel of HTML emails.

Start With Templates

First and foremost, start with a template. There are untold thousands of email templates available to the public that you can begin to use for free, all created with the major email platforms in mind. In fact, many of these templates come with the email providers you plan on using, meaning that you can sign up for an ESP and begin using their templates right from the get-go. This will help you avoid many, many bugs, while also helping you to start sending emails sooner.

Don’t Be Unique Just for the Sake of Being Unique

Second and more controversially, don’t try to be unique just because you want to try something new. There are tried-and-true tactics that work in email, whether they’re marketing, operational, newsletter, or sales emails. While you may be able to hack together an amazing motion picture email using transitions and gifs in creative ways, the hard truth is that at the end of the day using experimental and unsupported CSS features is just going to introduce unwanted bugs, all while demanding massive amounts of time to get it to work correctly.