Creating and coding an email for email marketing is easy and it’s not worth the trouble to run any tests to make sure it validates and renders properly, correct? WRONG!

An HTML validator is a program that is used to check Hypertext Markup Language (HTML) elements for syntax errors. While doing some research about this topic on the web I got a lot of mixed results. Most of the recent posts (and also a few older posts) about the subject indicate that it is a waste of time to validate your code because these validators check your code against a set of rules referred to as ‘web standards’ and the problem is that most email clients don’t support these web standards.

Call me old school but I still prefer to validate all my emails that I build to make sure the minimum errors are found by the validator.

An example of an email validator is https://validator.w3.org/

Although the most popular doctype to use these days is the HTML5 doctype I still use the old doctype XHTML 1.0 Transitional as it is the one trusted by most email developers in the bygone years and allows the use of deprecated elements which in some instances is vital for email marketing. My 2nd reason for using the old doctype is that HTML5 hasn’t become standard for email and the best CSS (Cascading Style Sheets which is the code that enables you to style your email beautifully) support is still in my opinion the XHTML 1.0 Transitional doctype.

Sticking to best practice is an important step to ensure the following:

Reaching the inbox
Rendering correctly across all email clients and mobile devices
Clean code can also decrease the file size of your email. Try to keep your email file size less than 102kb in size because anything above that will be clipped by Gmail giving a bad user experience. Large emails also tend to take longer to send due to the processing required from the email sending platform and can also have an impact on the loading time in your inbox.

If your email code is poorly written, then spam filters might interpret your email as something different than intended and your email could end up in the spam folder or even worse, get blocked by ISP’s and ultimately blacklisted.

Here are a few tips to make sure your code stays clean to decrease the chance of landing in the spam folder:

• Check that there aren’t duplicate opening/closing tags or incorrectly nested tags – Badly written code may result in your email landing in the spam folder.
• Check that the font colour isn’t too similar to the background colour – This is one of the most common tricks used by spammers to hide text in an email – especially when it comes to the unsubscribe.
• Don’t use Embedded Javascript – Due to security concerns most email clients do not support any Javascript as it is potentially very dangerous to support script execution in a desktop application which potentially contains a lot of personal information and some email clients will just strip these from your email resulting in a bad user experience.
• Do manual spell checking – Make sure to check the spelling and grammar of your email text and double check your content to avoid common spam topics that reference financing, genitalia and medication. From experience, installing programs that help with spell checking can be disastrous as these apps can add their own code to your HTML file.
• Do manual link checking even if your email platform has a link checking function – Always do a manual check as the link might be ‘correct’ according the link check functionality, but it can navigate to the wrong landing page by accident! Always use an absolute path for links that include the “http://” prefix as some older email clients will treat links without this prefix as unclickable. Without the prefix, email sending platforms won’t register a click and your reporting stats won’t be correct because the prefix is the part that identifies it is linked to a web page.

Validating your HTML code is essential! One coding error can have a cascading effect on the rest of your code which could result in the code being misinterpreted by the render engine of the email client. This could be devastating in that images and text could be displayed totally different than intended.

Render testing is the term used to describe the way your email will render (display) in the various email clients and mobile devices. Most email sending platforms have this functionality so you can easily run a test to see how your email displays in various email clients and devices. Email on Acid and Litmus are the biggest names. Sometimes these are charged for.

Email clients and mobile devices use different rendering engines which is the software they use to draw text and images on the screen. The rendering engines get the text from your HTML document and format it according to the styles which you declared either in the CSS in the email header or inline as is required by some email clients.

It has happened that email clients drop support for HTML and CSS attributes without any notice so an email that displayed perfectly the previous week can now be broken.

I would also suggest creating test accounts in as many email clients as possible to send yourself test emails as the result of some invalid code can also be spotted in the way your email displays.

The bottom line in creating fabulous emails is to test, test and test again to ensure everything is correct and that your message will get maximum traction by sitting pretty in the inbox.

With this in mind, start creating your design in a platform like Photoshop.  Whilst designing, keep in mind:

• “How will this section I am doing now render on mobile” – don’t make it impossible or difficult to code.
• Fonts – stick to system fonts for copy and headlines. Set the correct sizes, colours, line spacing etc in Photoshop
• Make sure your canvas size is the right size to export your slices later

Read more about newsletter design here.