For the latest results, visit the our page on “Web Fonts” in the “Will it work?” section of our site.

Typography is one of the foundational tools available to make your content unique and a pleasure to read. And while web typography is improving by leaps and bounds, email typography is less than ideal, constrained by the limits of current email clients.

We’ve previously discussed the merits of focusing on typography, as well of using @font-face or @import CSS rules for fonts in HTML emails before. But let’s give these a quick recap anyway.

Web font support in email clients

In our testing in late 2012, we found that support for the @font-face rule was still quite lacking – only Apple’s and iOS Mail support it. However, @import tends to fare slightly better – along with Apple’s Mail clients, Android Mail and Thunderbird can also make use of any fonts defined therein. As a result, both @font-face and @import does allow you to serve a portion of your readership with improved typography, while gracefully degrading for clients without web font support. Based on the numbers, the portion of people who will get the optimized version is growing all the time, especially if you consider the growth of email readership on mobile devices.

So, why wouldn’t a savvy designer take advantage of the tools available? Some of the best in the business do so.

How should you serve your fonts?

Once you’ve decided to make use of @font-face or @import, you have to decide where your fonts are going to be served from. Again, our testing in 2012 showed that Google Web Fonts are the best option available. Due to the lack of JavaScript support in email clients, services such as Typekit are sadly not an option.

But there’s a new kid on the web font services block: Cloud.typography from H&FJ. We were excited to see if the new service would work for both email and web sites. While we were at it, we decided to review a few other options – here’s what we found:

Now we’ve looked at a few options, let’s take a look at a sample campaign. Here’s The Weekly Review, a newsletter for design-minded folks. In this demo, @font-face is used to serve a couple of nice typographic options. The following image shows the three fonts that all of our iOS and Apple Mail readers can see, being Avenir, Brandon Grotesque and Facit:

Comparing fonts in iOS and Apple Mail

Readers using Android Mail or Thunderbird will also see Brandon Grotesque and Facit, as served via the @font-face declaration. However, as Avenir was not served via @font-face, it won’t be seen in these clients. Nonetheless, it was chosen as a good third font option for the article titles; being a system font for OS X and iOS, it’s also reliable font stack choice for Apple devices. All other readers will see Facit in its place.

Choosing good fallbacks

Once a service has been chosen and hours have been spent deliberating on just the right font, you can start putting your email design together. The key to providing a good experience for all readers is to ensure that good fallback font choices are made. Keep in mind that you are limited in your choices, as the fallback fonts have to be the safe options that will be available and supported by all email clients on all devices.

Despite the limited options, it’s important that you make choices that match your optimal font configuration as well as possible. For starters, vertical alignment is crucial to good design. Choosing a fallback font that has a similar x-height to your optimal font will ensure that the email you’ve designed doesn’t fall apart vertically when the second (or third) font choice is displayed.

In the earlier demo, Facit was chosen as the primary body font for two reasons. First, it’s lovely, plain and simple; it reads well at multiple sizes. But the second reason was that it has a similar x-height to some very safe fallbacks, Helvetica for the Apple crowd and Verdana for Windows users.

Comparing the x-heights of fonts

The animated GIF here shows the three choices and how well they fit together. Verdana in particular has an overall greater size and spacing, but the height is similar, meaning that the vertical spacing will be fine, no matter what font the email recipient sees.

Another item to keep in mind is choosing fonts that have a similar feel. This ‘feel’ can be dictated largely by the terminals, which provide an obvious distinction when comparing serif and sans-serif type. In our demo, the three primary fonts are distinct, but similar in their terminal types.

Comparing terminals between three fonts

As shown here, there are slight differences in the terminals and aperture of each letter, but they are each unmodulated, abrupt and the weight matches that of main stroke. As a result, the feel of your newsletter should not change greatly from client to client.

Will you use web fonts?

As we’ve postulated in the past, branding restrictions aside, there is nothing holding you back from taking advantage of better typography in 2013. Even in email!

With good fonts freely available and just as good fallbacks for less sophisticated email clients, using web fonts to better reflect your branding or to provide a more visually pleasing look and feel to your emails is a no-brainer. So, we’d love to hear from you – are you ready to put @font-face and/or @import to work in your campaigns? Chime in on the comments and let us know!

  • B. Moore

    Not yet…

    It is still not supported enough to make the time investment worthwhile.

    The only exception is if the email is specifically targeting apple devices.

    Thanks for all the tips!

  • Stephen Coles

    Thanks for the update on this! Missing from your list: the Webtype service professional self-hosted options (the best fonts aren’t free).

  • Chris Bowler

    Thanks for feedback Stephen — and for reading. Much respect to you and your work!

    And great point. I would love to have listed more than the usual offerings that a lot of designers turn to. Quality fonts are definitely worth the price! Thanks for adding to the list of options.

  • Todd

    Upvote for being ahead of the curve.

  • Mark

    Although not many clients support this, I’d say iOS, Android, Apple mail and Thunderbird make up close to 50% of our list.

    Well worth considering.

  • Antony

    Is there a maximum font size you can use in an email now. We used to be told that font size over 18px can be classed as spam?

  • Ros Hodgekiss

    Hi there Anthony, we’re on the fence about this one. There are both SpamAssassin filter rules covering both small and large font sizes, however the documentation on them isn’t specific about what the criteria are and overall, these rules aren’t weighted terribly heavily.

    That said, we’ve heard a few things on the grapevine:

    “I don’t believe SpamAssassin’s definition of large font sizes includes H1, H2, H3 heading tags. So use HTML heads and subheads rather than font tags to increase font size, since “large” font size costs 1.4 points and “huge” font size is 1.8 points. If copyright information in small type is hurting your point count, you might want to include it full size, since “tiny font size” costs 2.1 points. Using a font color similar to the background color to hide words can cost you 1.0 points.”

    Another report also suggested that font sizes in <font> were explicitly being targeted, not those defined using CSS styles. We’ll have to keep experimenting, but from personal experience, I haven’t come across any situations where a message has been junked on font size criteria alone.

  • Tommy Grimes

    I’m testing this out using @import to pull in the Oswald web font from Google. My font stack is: font-family: ‘Oswald’,arial,sans-serif;

    Everything looks good in all clients, except Outlook ’07 and ’10. They are not showing Oswald, but they are also not degrading down the specified stack. Instead, I’m seeing TNR or another serif font.

    Has anyone else experienced this?

  • Ros Hodgekiss

    Hi there Tommy, sorry for the late response on this one. We’ve seen font stacks fail pretty badly in Outlook and this Stack Overflow thread seems to be identical to what you’re reporting here. As per the answer, it may be worth trying conditional comments to define this web font for clients other than Outlook only. Best of luck!

  • Tommy Grimes

    Thanks, Ros! I ended up using a suggested conditional fix from Stack Overflow that says “IF not MSO, THEN import this web font.” Outlook ’07-’10 are now degrading correctly.

Want to improve your email marketing? Subscribe to get tips on improving your email marketing delivered to your inbox.

Join 150,000 companies around the world that use Campaign Monitor to run email marketing campaigns that deliver results for their business.

Get started for free