Email is a magical thing as you click Send in Bangor and it’s received in Bangkok. However, it isn’t email fairies or electronic hamsters delivering your mail, it’s an extremely complex system where the data is bounced around the internet running a gauntlet along the way that determines what bytes get through and which ones don’t. When you’re devising your email layout you have to take into consideration what valuable code will be stripped out and where otherwise your email will display like a dog’s breakfast. The primary three trouble spots are:

1. Pre-Processors

Unless you’re a total technophile you might have been sending out emails for years without even realizing that every single missive goes through something known as a pre-processor. This is a pre-sift of your HTML which occurs before the code is handed over to the rendering engine. Pre-processors are designed to remove any content that might be malicious or dangerous, avoid violations of privacy standards (by disabling external URLs which could load content without your knowledge), or cause the client itself to malfunction. There are two different types of pre-processors:

  • Local. These are the ones that are present in the email client itself and they basically concentrate on the removal of javascript or any other form of client-side scripting, the elimination of object, embed, and related tags which prevent any Flash or ActiveX content from being embedded right in the email, and the deletion of unrecognized tags which is especially important when using older email clients.
  • Web Based. The pre-processors of the big guns of the email industry such as Gmail and Outlook.com will perform the same tasks as the local counterparts but go well beyond that. It is their responsibility to make sure that incoming emails don’t end up blowing up the rendering of their web based interfaces so they tend to be far more restrictive in shutting out any code that they don’t recognize or even don’t agree with.

2. Rendering Engines

Once the pre-processors have done their jobs the email is now handed over to the rendering engine whose job it is to display the content in the best possible way. The biggest problem that faces email designers is the fact that there are various types of rendering engines and each has its own unique quirks. WebKit is going to render a bit differently than Gecko or Trident, or any of the others. Should you be unlucky enough to have your email land in a client which utilizes some of the older rendering engines such as Tasman or NotesRichText you might as well just send out text-only because these are almost guaranteed to break your code. Even some of the most modern and updated rendering engines will have the tendency to break something in your email especially if you are unwise enough to start piling your messages full of CSS. Entire volumes can be written about how best to navigate the Internet Explorer (Trident), Firefox (Gecko), and Chrome or Safari (WebKit) waters so you’re well advised to look into each of these in order to determine what the quirks of each major rendering engine are.

3. Mail Servers

The mail server is the way that mail gets from point A to point B and it’s a really great thing that the primary server protocols such as POP, IMAP, WebDav/DeltaSync, and Exchange are able to deliver email without as much as touching the code. The problem occurs when you’re going through Domino which is IBM’s email server process as it modifies the code in the way that it best sees fit in order to render it in Lotus Notes. This software works along the lines of a pre-processor as it will strip out any HTML elements that it doesn’t support, including object and script which can act like a stick of dynamite underneath your email layout. Domino also especially despises iframe and frame(set) but if you’re using frames in your email layouts you’re hopeless anyway and you deserve to have your layouts exploded.

Preventing layout problems in-transit is best achieved through a comprehensive preview suite such as Benchmark’s new Inbox Checker.