Email Font Stacks: Web Fonts and Fallbacks | EmailGuide.dev

The State of Web Fonts in Email

On the modern web, custom fonts are taken for granted. In email, they're a minefield. The fundamental problem is that email clients have wildly inconsistent support for loading external font files, and the biggest clients — Gmail and Outlook — flat-out refuse to do it.

Here's the current state of web font support across major email clients:

Email Client	Web Font Support	Method
Apple Mail (macOS)	Yes	@import, <link>, @font-face
iOS Mail	Yes	@import, <link>, @font-face
Thunderbird	Yes	@import, <link>, @font-face
Outlook (macOS)	Yes	@import, <link>
Gmail (web & mobile)	No	Strips <link> and @import
Outlook (Windows)	No	Word engine, no web font support
Yahoo Mail	No	Strips external font references
Outlook.com	No	Strips <link> tags
Samsung Mail	Partial	@import only in some versions

The clients that support web fonts (Apple Mail, iOS Mail, Thunderbird) account for a significant share of opens, especially in B2C markets where Apple devices are common. But Gmail and Outlook together cover a massive chunk of the remaining audience. You cannot ignore them.

Loading Web Fonts: @import vs <link>

When using web fonts in email, you have two primary methods for loading them. Both go inside the <head> of your email.

The @import Method

Place an @import rule inside a <style> block in the <head>:

<head>
  <style>
    @import url('https://fonts.googleapis.com/css2?family=Inter:wght@400;600;700&display=swap');
  </style>
</head>

This is the more widely supported method across the clients that accept web fonts. Apple Mail, iOS Mail, Thunderbird, and Outlook for Mac all handle @import well.

The <link> Method

Alternatively, use a standard <link> tag in the <head>:

<head>
  <link href="https://fonts.googleapis.com/css2?family=Inter:wght@400;600;700&display=swap" rel="stylesheet">
</head>

The <link> method works in the same clients as @import. Some email developers prefer it because it's more familiar from web development and can load slightly faster since it doesn't block the CSS parser. In practice, both methods produce nearly identical results in email clients that support them.

The @font-face Method

You can also declare fonts directly with @font-face if you host the font files yourself:

<style>
  @font-face {
    font-family: 'CustomFont';
    font-style: normal;
    font-weight: 400;
    src: url('https://yourdomain.com/fonts/customfont-regular.woff2') format('woff2');
  }
</style>

This gives you the most control but requires hosting the font files and managing CORS headers. For most use cases, Google Fonts via @import is simpler and sufficient.

Recommended System Font Stacks

Because web fonts fail in Gmail, Outlook, and Yahoo, your fallback font stack is what most subscribers will actually see. Choosing good fallbacks is not an afterthought — it's the primary design decision.

Sans-Serif Stack

This stack targets the best-looking system sans-serif on each platform:

font-family: -apple-system, BlinkMacSystemFont, 'Segoe UI', Roboto, Oxygen-Sans, Ubuntu, Cantarell, 'Helvetica Neue', Arial, sans-serif;

-apple-system / BlinkMacSystemFont: San Francisco on macOS and iOS.
Segoe UI: The default UI font on Windows.
Roboto: The default font on Android and Chrome OS.
Oxygen-Sans / Ubuntu / Cantarell: Common Linux system fonts.
Helvetica Neue / Arial: Universal fallbacks.
sans-serif: Final generic fallback.

Serif Stack

For editorial or formal content, a reliable serif stack:

font-family: Georgia, 'Times New Roman', Times, serif;

Georgia is the workhorse here. It was designed specifically for screen readability, renders well at small sizes, and is available on virtually every platform. It's a significantly better choice than Times New Roman for body text in email because of its larger x-height and wider letterforms.

Monospace Stack

For code snippets, confirmation numbers, or tracking codes:

font-family: Menlo, Consolas, 'Liberation Mono', 'Courier New', monospace;

Menlo: Default monospace on macOS.
Consolas: Default monospace on Windows.
Liberation Mono: Common on Linux distributions.
Courier New: Universal fallback monospace.

Design Considerations: Metric Differences

One of the biggest pitfalls when using web fonts with system fallbacks is the metric difference between fonts. Two fonts set at the same pixel size can render at noticeably different widths and heights. This causes layout shifts when a subscriber sees the fallback instead of the web font.

For example, Inter (a popular web font) has wider letterforms than Arial. A heading that fits on one line in Inter might wrap to two lines in Arial. A button sized for the web font's metrics might have text overflowing in the fallback.

Here are practical strategies to handle this:

Design with the fallback first. Build and test your email using only the system font stack. Once it looks good with system fonts, layer on the web font as a progressive enhancement.
Avoid tight containers. Give text elements enough breathing room that a slightly wider or taller fallback font won't break the layout.
Choose metrically similar fonts. If you're using Inter as your web font, Arial is a reasonable fallback because their metrics are close (though not identical). If you're using a condensed web font, don't fall back to a wide system font.
Test with images off. If your headings are critical to the design, consider rendering them as images (with proper alt text) rather than relying on a specific font rendering.

Applying Fonts Inline

Because Gmail strips <style> blocks in many contexts, you should always apply your font stack as an inline style, not just in a class definition:

<td style="font-family: -apple-system, BlinkMacSystemFont, 'Segoe UI', Roboto, 'Helvetica Neue', Arial, sans-serif; font-size: 16px; line-height: 1.5; color: #333333;">
  Your content here.
</td>

Yes, this means repeating the font stack on many elements. It's verbose but necessary. Email CSS inlining tools (like the ones built into most ESPs, or standalone tools like Juice or the premailer npm package) can automate this from a <style> block, but you should verify the output.

Summary

Web fonts are a nice-to-have in email, not a given. About half your audience will see your web font; the other half will see the system fallback. Design for the fallback first, treat the web font as progressive enhancement, and always inline your font stacks. The goal is an email that looks intentionally designed in every client — whether or not the custom font loads.

Email Font Stacks: A Practical Guide