Fonts in email: what works, what breaks, and how to fix it

Pick a font for your website and it works everywhere. Pick a font for your email and you're immediately dealing with a different reality. Fonts in email have never followed the same rules as fonts on the web. Gmail ignores your @font-face declaration. Outlook might swap in Times New Roman. Apple Mail renders your custom typeface perfectly. Your users see three different versions of the same email.

This isn't a new problem, but it's one that trips up even experienced teams because the rules aren't obvious. Email clients don't follow browser standards. They each have their own rendering engine, their own CSS support, and their own opinions about what fonts to show.

This guide covers the practical standard for handling fonts in email: how to build fallback stacks that hold up, where custom fonts actually work, what to do about the clients where they don't, and how to QA all of it before you hit send.

Why fonts in email don't work like fonts on the web

On the web, you declare a font with CSS, point to a hosted file, and browsers load it. It's been reliable for over a decade. Email doesn't work that way.

Every email client is its own rendering environment. The same HTML might pass through Gmail's web interface (which strips <style> blocks and ignores @font-face), Outlook for Windows (which uses Microsoft Word's rendering engine), Apple Mail (which supports most modern CSS), and dozens of others. Each one makes its own decisions about what CSS to keep, what to strip, and what to override.

That fragmentation means your font choice isn't really a design decision. It's a compatibility decision. Three things make it tricky:

• Inconsistent @font-face support. Some clients load custom fonts. Others strip the declaration entirely and fall back to their own default.
• Different default fonts per client. Gmail defaults to Roboto on Android and Arial on desktop. Apple Mail uses Helvetica. Outlook uses Calibri. If your fallback stack doesn't account for this, the client picks for you.
• Layout shifts from fallback fonts. A fallback with a different x-height or character width than your primary font can change line wraps, push content below the fold, or compress spacing in ways you didn't design for.

The takeaway: if you want your emails to look intentional across clients, you need to design for what happens when your preferred font doesn't load. Because in many inboxes, it won't.

The industry standard: fallback-first, enhance where you can

Look at the guidance from Litmus, Campaign Monitor, Email on Acid, and the support data on Can I Email. The pattern across all of them is the same.

Teams that ship reliable email at scale don't pick one perfect font and hope for the best. They build a fallback-first strategy: start with fonts you know will render everywhere, then layer in custom fonts as a bonus for clients that support them.

Here's what that looks like in practice:

1. Start with email-safe system fonts as your baseline. These are fonts pre-installed on virtually every operating system: Arial, Helvetica, Georgia, Verdana, Times New Roman, Courier New. They're not exciting, but they're universal.
2. Add a custom web font at the front of the stack for clients that support it. Apple Mail, iOS Mail, and a handful of others will load it. Everyone else gets the fallback.
3. End every stack with a generic family. Always close with sans-serif, serif, or monospace so you're never leaving the final choice to the client.
4. Test in the clients your audience actually uses. Your open data tells you where to focus.

You'll sometimes hear this called a "web-safe font" strategy. That term comes from old web standards and refers to fonts commonly installed across operating systems. In the email world, the better mental model is email-safe fonts: the subset that reliably renders across major email clients, not browsers.

Which email clients support custom fonts (and which don't)

Support changes over time, so always check a current source like Can I Email before making decisions. That said, the high-level patterns have been stable for years:

Where this nets out depends on where your audience reads. Apple Mail (across iPhone, iPad, and Mac) accounts for roughly half of all email opens, about 51% in Litmus's February 2026 data, and it renders custom fonts well. So for a consumer or Apple-heavy audience, a custom font can genuinely reach most of your readers.

But the next-largest client, Gmail, strips custom fonts entirely, and so do Outlook for Windows, Outlook.com, and Yahoo Mail. B2B audiences in particular skew toward those clients. Apple's share is also inflated by Mail Privacy Protection, which pre-fetches content and can log opens no human ever saw. The net: a large share of real readers will see your fallback, not your custom font.

That's not a reason to skip custom fonts. It's the reason your fallback has to look just as intentional as your first choice.

How to implement fonts in email HTML

There are three methods for loading custom fonts in email. Each has different levels of client support.

@font-face (recommended for email)

This gives you the most control. You declare the font family, weight, style, and source directly, and you can specify the woff2 format, which has the widest support among clients that accept custom fonts.

@font-face {
  font-family: 'Inter';
  font-style: normal;
  font-weight: 400;
  src: url('https://your-cdn.com/fonts/inter-regular.woff2') format('woff2');
}

Then reference it in a fallback stack on every text element:

<td style="font-family: 'Inter', Helvetica, Arial, sans-serif; font-size: 16px; line-height: 1.5;">
  Your order has shipped.
</td>

One caveat: link to a hosted woff2 file rather than base64-embedding the font in your HTML. Embedding inflates the message size quickly, and Gmail clips any message larger than roughly 102KB, which can hide content or the unsubscribe link and break your layout.

<link> and @import

Both of these pull from an external stylesheet, most commonly Google Fonts. Google Fonts are free to use in email, and their licenses explicitly cover it. They're simpler to set up, but have slightly narrower email client support and can introduce loading delays.

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

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

If you use either of these, watch out for an Outlook quirk: some versions will fall back to Times New Roman instead of your declared fallbacks. The @font-face method avoids this, which is one reason it's preferred.

Build your fallback stack with intention

A font stack isn't a list of random alternatives. Each entry should be chosen deliberately:

• Match the style class. Sans-serif primary gets sans-serif fallbacks. Serif primary gets serif fallbacks.
• Match the x-height. Fonts with similar x-heights produce fewer layout shifts when the fallback kicks in.
• Keep line-height explicit. Don't rely on inherited or default values. Set line-height on every text block so spacing stays consistent regardless of which font loads.

Here are example stacks for common styles:

Handle Outlook explicitly

Outlook for Windows deserves special attention. It uses Microsoft Word's rendering engine, which means it ignores most CSS you'd expect to work. For fonts specifically, Outlook can default to Times New Roman when it encounters font declarations it doesn't understand.

The standard fix is an MSO conditional comment that forces a safe font stack for Outlook:

<!--[if mso]>
<style type="text/css">
  body, table, td, p, a, span {
    font-family: Calibri, Arial, sans-serif !important;
  }
</style>
<![endif]-->

Not glamorous. Very effective.

Readability and accessibility standards

Email typography has one job before all others: be readable. If your subscribers can't comfortably read your content, nothing else about your font strategy matters.

These are the practical defaults that align with WCAG guidance and industry best practices:

• Body font size: 14px minimum, 16px recommended. Some teams go to 18px for mobile.
• Line height: 1.4 to 1.5 times the font size for body copy. Tighter spacing feels cramped on screens.
• Heading scale: 28 to 32px on desktop, 24 to 26px on mobile. Always set line-height explicitly on headings.
• Color contrast: meet WCAG AA minimums (4.5:1 for body text, 3:1 for large text). Strong contrast isn't optional.
• Visual hierarchy: use size, weight, and color differences to create clear distinction between headings, body, and secondary text.

A few things to avoid:

• Decorative fonts for body copy. They're hard to read at small sizes and harder to read on mobile.
• Image-only emails as a font workaround. Locking text in images breaks screen readers, fails when images are blocked, and kills accessibility.
• Relying on font-weight alone for hierarchy. Not all clients render weights consistently. Combine weight with size and color.

Use media queries to refine sizing on mobile:

@media only screen and (max-width: 480px) {
  .heading { font-size: 26px !important; line-height: 34px !important; }
  .body-text { font-size: 15px !important; line-height: 22px !important; }
}

Dark mode and font rendering

Dark mode is where a lot of careful font work quietly falls apart. Email clients don't handle it the same way, and some rewrite your colors whether you want them to or not.

Three behaviors to know:

• Apple Mail applies a mostly faithful dark treatment and generally respects your CSS, including @media (prefers-color-scheme: dark) overrides.
• Gmail partially adjusts colors, and its behavior differs between the mobile apps and the web client. You get limited control.
• Outlook.com and Windows Outlook can force-invert your palette aggressively, turning dark text on a light background into light text on a dark one, sometimes with poor contrast in the result.

What this means for fonts:

• Never rely on color alone for legibility. A forced inversion can flip a carefully chosen text color into something with barely-there contrast against its new background.
• Set explicit text and background colors on your containers so clients have less room to guess.
• Test both modes. A stack that reads perfectly in light mode can lose contrast or hierarchy once a client inverts it.
• Use prefers-color-scheme where it's supported (mainly Apple Mail) to ship a hand-tuned dark palette instead of an auto-inverted one.

Dark mode won't change which font loads, but it can wreck how readable that font is. Treat it as part of your font QA, not a separate afterthought.

A pre-send QA checklist for fonts

You don't need a 30-minute QA process for every email. But you do need a repeatable check that catches font issues before they reach inboxes. You can eyeball this in your own inbox, but the reliable way to see every client at once is a preview-testing tool like Litmus or Email on Acid, which render your email across dozens of clients and devices from a single test.

Before every send:

1. Every text block has an explicit font-family with a fallback stack.
2. Body text meets your size and line-height targets.
3. The email previews correctly in Gmail, Outlook, and Apple Mail (at minimum).
4. Mobile rendering looks right at 375px width.
5. Dark mode doesn't break text contrast or hide content.
6. Headings still create clear hierarchy when the primary font doesn't load.

Common failures this catches:

• A CTA button drops below the fold because the fallback font is slightly wider.
• Body copy looks cramped because the fallback has a larger x-height than expected.
• Outlook renders everything in Times New Roman because the font declaration method doesn't play well with MSO.
• Thin font weights become nearly invisible on certain screens.

Catching these in QA takes minutes. Fixing them after a send takes an apology email.

How Courier handles this for you

Everything in this guide boils down to one workflow: pick a font, build a fallback stack, and test it. Courier's notification designer, part of Design Studio, now handles that workflow automatically.

When you design an email in Courier, you choose from a catalog of fonts vetted to render reliably across major clients: 10 web-safe families plus 60 Google Fonts, 70 in total. The designer auto-selects a compatible fallback stack for you, so every email template ships with a proper stack out of the box. No hand-coding font-family declarations, no guessing which fallbacks match your primary font's x-height.

Pick a Google Font and Courier loads it automatically on its own servers, so you don't need any <link> tags, then generates the matching fallback the same way. Clients that support web fonts get your custom typeface. Everyone else gets a matched fallback. Progressive enhancement, handled for you.

And if you have opinions about which fallbacks to use (you probably do), you can override the auto-selection and pick your own from the catalog. You get full control without having to write the CSS yourself. For a look at how this fits into a full send workflow, see our Design Studio and Journeys integration guide.

Frequently asked questions

Do custom fonts work in email?

Sometimes. Apple Mail and iOS Mail render custom fonts well, and they account for around half of all email opens. But Gmail, Outlook for Windows, Outlook.com, and Yahoo Mail strip custom font declarations and fall back to their own defaults. Design for the fallback first, then treat the custom font as an enhancement for clients that support it.

Which email clients support custom fonts?

Apple Mail (macOS), iOS Mail, Outlook for Mac, and Thunderbird support @font-face. Gmail, Outlook for Windows, Outlook.com, and Yahoo Mail do not, and Samsung Mail offers only partial support. Always confirm against a current source like Can I Email before you rely on it.

What are the safest fonts for email?

System fonts installed on nearly every operating system: Arial, Helvetica, Georgia, Verdana, Times New Roman, and Courier New. These "email-safe" fonts render consistently across clients. Always end your stack with a generic family (sans-serif, serif, or monospace) so the client never picks the final font for you.

Why does my email show up in Times New Roman in Outlook?

Outlook for Windows uses Microsoft Word's rendering engine, which falls back to Times New Roman when it can't parse a font declaration, especially with <link> or @import. The fix is an MSO conditional comment that forces a safe font stack (for example Calibri or Arial) just for Outlook.

What font size should I use in email?

Use 14px as a minimum and 16px as the recommended default for body copy, with a line-height of 1.4 to 1.5. Headings usually land around 28 to 32px on desktop and 24 to 26px on mobile. Set line-height explicitly on every text block so spacing holds up regardless of which font loads.

Are Google Fonts allowed in email?

Yes. Google Fonts are free to use in email and their licenses cover it. Client support is narrower than a self-hosted @font-face file, and some Outlook versions may fall back to Times New Roman, so always pair a Google Font with a solid email-safe fallback stack.

Wrapping up

The industry standard for fonts in email comes down to one principle: design for the fallback first, then enhance where you can.

Custom fonts can absolutely strengthen your brand in the inbox. Apple Mail and iOS Mail render them beautifully, and those clients lead email opens. But a large share of your audience still reads in Gmail, Outlook, or Yahoo, where the custom font never loads, and your emails need to look intentional there, too.

Build a solid fallback stack. Set readable defaults for size, line-height, and contrast. Handle Outlook explicitly. Test before you send. That's the standard, and it's the standard because it works. And once your typography holds up, make sure the emails actually land: our guide to email sender requirements covers the authentication rules Gmail, Yahoo, and Outlook now enforce.