Just a short entry this time, pointing at an article I recently wrote on Location Aware Applications printed in CXO magazine and also available online.
Hope you enjoy it, 64 Diggs so far!
Just a short entry this time, pointing at an article I recently wrote on Location Aware Applications printed in CXO magazine and also available online.
Hope you enjoy it, 64 Diggs so far!
If you’re sending marketing emails then you’ll naturally want to do everything you can to get those emails into people’s inboxes.
Sending emails used to be simple however then came the fraudsters and so in the interests of security, email verification and authentication technologies were introduced. These are Domain Keys, DKIM, SPF and SenderID.
Enabling these authentication methods is a significant and important step in helping our marketing emails hit peoples inboxes. See MailChimp’s page for a demonstration of how many significant domains rely on these different authentication schemes to verify email senders. It’s a great article.
So, lets start with SPF and SenderID…
Firstly, skipping the long explanation, they’re 99% the same. Very basically, when a recipient reads an email from yourdomain.com it cross references the originating IP with yourdomain.com’s DNS server to verify that the email server’s IP is allowed to send emails. Simple.
To get this working go to http://www.openspf.org and complete their SPF record creation wizard. You’ll end up with something looking like…
"v=spf1 ~all"
Email this to the company that looks after your domain and ask them to add it to your DNS server as a text record. SPF – done.
Moving on to Domain Keys and DKIM…
These are again very similar but differ from SPF/SenderID in that rather than simply verify sending rights, they dig a little deeper.
When sending the email, the email server attaches an encrypted digital signature to its header. The recipient then processes this signature by cross referencing it to a text record held on yourdomain.com’s DNS server. Hence the recipient can again verify that the server sending the emails is genuine and legitimate, a little more securely.
So, getting it to work in Exchange…
Exchange doesn’t actually support DKIM or Domain Keys so you need to buy an after market software package. AdminSystem sell it, and it’s a not-so-cheap $799 for the Enterprise version (allows a number of servers to use it for the same domain). It supports not only Exchange but also IIS SMTP server so you can use it in several environments. The product is here and called (aptly) “EA DomainKeys/DKIM for IIS SMTP Service and Exchange Server”. It may look like an amateur website selling a fake product but it really works!
Installation is simple: download the MSI, install it, restart and voila…almost. Mid way through you need to create the DNS record and luckily for all of us there’s a video on youtube explaining exactly how you do this. It’s here, try to ignore the terrible music in the background. There’s also almost a minute of pointless pause at the end so be prepared to ignore it.
Once you have the text record you’ll again need to send this on to your DNS host for them to add to youdomain.com.
Lastly we need to test!
For Domain Keys/DKIM, send go to Mail Radar and send an email to the randomly generated address at the bottom. After a few seconds click view results for verification.
For SPF/SenderID we don’t even need to bother sending an email, just go to PoliteMail and type in your email address. PoliteMail will then verify the SPF record.
Bingo! DKIM, Domain Keys, SPF and SenderID all on an Exchange Server!
FYI, before you read this post, you’ll need to know some HTML!…
Designing and coding an HTML email is not like designing a simple web page.
Ok so they’re both coded in HTML but the approach is entirely different. HTML emails could potentially be viewed in many different email clients – Outlook, Outlook Express, Windows Mail, Mac Mail, Eudora…the list goes on not forgetting the hundreds of online services like Hotmail, Yahoo Mail and Google Mail. All these clients and webmail services have their own little quirks which when compiled and compared means coding with any kind of modern techniques is near impossible…
Outlook 2007 is what many cite as being a frustrating turning point in email client HTML rendering when Microsoft chose to switch the rendering engine from Internet Explorer (as it was in Outlook 2003) to Word 2007. Thus HTML rendering was crippled. Microsoft can’t take all the blame though, Google Mail refuses to interpret externally linked stylesheets and ignores numerous seemingly random inline CSS properties.
For a depressing comparison of Outlook 2010′s attempt to render to the same level as Outlook 2000 see below…

Outlook 2000 vs Outlook 2010
…this was, according to Microsoft, due to security concerns.
So, the question is…
How can we design marketing emails that look great in all email clients, webmail and offline?
Surprisingly, you’ve gotta code like it’s the year 2000, back when flashing text looked great and play.com was called play247.com (and looked like this). This means <table> elements with all their dated and inflexible <tbody>, <tr> and <td> delights. Those dark times when web designers would need to use <rowspan> and <colspan> to create a grid of elements that couldn’t overlap.
My best practise tip is to physically draw a rough content grid for the email by pencil. As an example, below is an M&S email from January 2009.

M&S Marketing Email Jan 2009
The images are likely designed and sliced in Photoshop for convenience. Here’s an approximate HTML table grid…

HTML Layout Grid of M&S Email
Different tables are shown as different colours, with the white background representing a parent table. Each row is a separate <tr> and each cell is a table element <td>. COLSPAN is used to force a table cell to bridge two or more columns and ROWSPAN to force a table cell to bridge two or more rows. I’ve labelled the colspan attribute as ‘cols‘ due to shortage of space.
This email can basically be pseudo-html-coded as…
<table> <table>...table-elements...</table> <table>...table-elements...</table> <table>...table-elements...</table> </table>
For a full tutorial carrying all details of how to build HTML tables as seen in this email I’d recommend this about.com tutorial. I would demo-code it myself, but it’s not even necessary as the full M&S email and source code is available here.
Once you create an HTML file with tables, table rows and table cells ensure you declare each table’s width and height where possible. It’s best to fill each cell with an <img /> and then link that image, otherwise it’s a potential wasted click i.e…
<td><a href="<link>"><img src="<img-link>" height="100" width="100" border="0" /></a></td>
Note: Always declare the image’s height and width in an <img /> tag. That way when the email lands in someones inbox the email actually looks readable/presentable before they click to ‘Allow Image Downloads’.
Generally, try to use solid background colours where possible as simple colours are better supported amongst email clients than background images. For cells where you want a background image and text content then use the background attribute. For example…
<td height="100" width="100" background="<url>">
This will enable the background to be viewable in all most webmail providers. Using an inline style may not (Google Mail). In fact because support is so patchy avoid using inline styles as much as possible.
When formatting text don’t use inline CSS styles, instead use the ancient <font> tag e.g.
<font face="verdana" size="1">Here is some Text</font>
If you use Google Analytics then you’ll have a good idea which font your customers have from their declared operating systems. As with all web design it doesn’t make sense to put your entire email in ‘Arial’ if 90% of browsers use Mac OSX. It’s best to use a decent amount of body text to give spam filter’s the best chance of judging your marketing email as not being spam.
Generally, once you create a table/row/cell/sub-table/sub-table row/sub-table cell structure and fill it with linked/unlinked images and text then really there’s nothing else to it. Active content like videos are very poorly supported indeed and like I mentioned before JavaScript is a complete no-go.
For detailed and accessible documentation of which email clients/webmail providers support certain HTML/CSS properties then take a look at the Email Standards Project. It clearly demonstrates that whilst many web designers are thoroughly fed up with having to code for IE6, many email clients are just as patchy and awkward.
Once happy with your layout, design, and text then before you send anything it’s important to TEST, TEST, TEST and see how it looks in as many email clients as possible. You could try Litmus, an absolutely fantastic service that lets you see how your email will render in a majority of the major clients/webmail services. It costs $50 a month but it’s worth it.
For those of you that don’t want to pay for seeing how your emails will look in different clients then take a look at Email on Acid. It doesn’t have as many options or clients as Litmus and may be a little patchy on result consistency but it’s still great for a free service.
So to summarise here are the important things to do when when creating an HTML marketing email…
Email on Acid is nolonger free
However, it’s only $13 a month and so far better value for money than Litmus (who have been having some issues recently with webmail rendering). As such I’ve cancelled my subscription with Litmus. Sorry but EON is way faster and cheaper.