While Microsoft has been making great improvements on the web standards front in IE, they’ve been seemingly rolling backwards with HTML support in Outlook. For the 2007 version they switched from the IE rendering engine to the Word engine (apparently for security reasons), which is completely crippled compared to IE. For anyone who does email marketing and designs and codes attractive HTML emails, this decision has no doubt had you shaking your fist and cursing Bill Gates’ mother.

We were all hoping that for the upcoming Outlook 2010 release Microsoft would go back to IE, but they have announced that they are sticking with Word. The pitchforks and torches are waving, but it looks like we’ll be dealing with the Word engine for emails for many years. Even if they switch to IE for 2012, we’ll have clients using 2007 and 2010 for years. So if you haven’t yet learned the ins and outs of designing emails for Outlook, now’s the time to learn!

Forget all your best practices for CSS – go back to 2001 coding practices for an idea of where your head should be.

Mural does a lot of HTML email work for some of our bread and butter clients, and we literally have thousands of campaigns in our archive dating back many years, so we have a lot of experience testing for lots of different clients and learning the various techniques needed for each. With Outlook 2007 we have our most challenging client, and in general if your email works well in Outlook it’s probably working well everywhere.

Limitations

The first thing you need to understand when designing and coding for Outlook is that the usual rules do not apply. Forget all your best practices for CSS – go back to 2001 coding practices for an idea of where your head should be. Note that some of these things might work in Outlook, but I advise against them because in my experience they do not work consistently, and it’s embarrassing to get an email back from your client asking why it broke when they sent it, so just trust me.

General “best practices” for Outlook 2007:

• Forget about separating content from design with CSS. Build your emails with tables and spacer gifs. No divs. See example below…
• No background images, only background colors. If you want to have HTML text over an image area, you’ll have to make the area behind it a solid color so you can slice it out of the layout.
• You can use basic styles, but use them inline attached to each tag, not in the header. Don’t get fancy – a lot of what works in a browser will not work in Outlook.
• Don’t use padding, only margins. Padding does not work properly.
• Keep your code as simple as possible.
• Optimize your email for ‘images off’ mode, which is likely to be default for your recipients. If you don’t define a height for images, they’ll collapse vertically, moving your text content up. Do specify width though.

Lets take a look at a sample email:

View the HTML version for code.

Lets take a look at the first paragraph of HTML text for an example of how the email should be coded for outlook.

<tr>
<td width=”20″>
<img src=”http://client.muralconsulting.com/neustar/7ways/spacer.gif” width=”20″ height=”1″ border=”0″ alt=”" />
</td>
<td bgcolor=”#ffffff” width=”530″>
<p style=”font: 14px/20px Arial, Helvetica, sans-serif; color: #002765; margin-bottom:10px;”>
<strong>Budgets are tight, yet your customers’ demands for high performance from your online service are growing.</strong> The good news is that you don’t need to spend a lot of money to make your web applications faster&hellip; if you know where to look!</p>
</td>
<td width=”20″>
<img src=”http://client.muralconsulting.com/neustar/7ways/spacer.gif” width=”20″ height=”1″ border=”0″ alt=”" />
</td>
</tr>

Note that we’re using tables to define the layout, not css, and we’re reinforcing cells with spacer gifs. All the styling is attached inline to the individual <p> tag itself, and not as a global p. Also note that we’re controlling vertical space with margins, not padding.

While many web designers and coders frown on tools like Dreamweaver for not providing accurate design modes for advanced CSS, Dreamweaver is actually a really good tool for emails, and can display them quite accurately. It was originally designed for building websites before the semantic web was popular, so it does old-school well. It definitely helps when building tables, so don’t be afraid to use it.

Testing your emails

There are three ways to test your emails: Sending it to yourself on a lot of different computers and clients, using a testing service like Litmus, and the ‘send page as email’ trick (Windows/IE only). While I don’t really recommend the former for practical reasons, the latter two are essential.

If you’re  using windows and have Outlook on your machine, the quick and dirty way to test is to open your email in IE, and then go to File > Send > Page by email. This will open a new Outlook email and insert the code faithfully into it. Don’t trust the compose view though, send it to yourself, and then you can see how it will appear when it arrives.

If you’re a Mac user, that will not work for you, and you’ll probably want to use a browser testing service that includes email testing. We use Litmus, which lets you test emails in a dozen web and desktop clients to ensure that it works properly. It also lets you test things like the fold, and turning images on and off. It’s expensive, but if you do this a lot it’s worthwhile. HTML clients can have even more compatibility issues than their browser counterparts, and can require just as much testing.

Certainly this is not an exhaustive article about all the ins and outs of Outlook emails, but it should give you a good working foundation. Like anything on the web, you’re bound to find more quirks, but following the guidelines here should get you 90% there.