Typography in email: what renders, what doesn't, and what your ESP won't tell you
Typography is one of the first places where designers realize that email is its own world. The rules you learned for web or app design don't fully apply here. And the gap between what your email looks like in Figma and what it looks like in an inbox can be... humbling.
Let's clear that gap up. Here's what actually happens to your fonts when an email hits an inbox, what your ESP is and isn't doing about it, and how to make design decisions that hold up in the real world.
Why email typography is different
On the web, you load a font from Google Fonts or a CDN, it renders in the browser, done. In email, it's more complicated because email clients don't all support external font loading, and the ones that don't will silently swap your carefully chosen typeface for a system fallback without asking.
That silent swap is the core problem. You design something that looks great in Figma, it renders fine in Apple Mail, and then you check it in Outlook and the entire typographic personality of the email has been replaced by Arial.
Which clients support custom fonts?
Here's the current landscape as of 2026:
Apple Mail (macOS + iOS): Supports web fonts via @font-face. Reliable.
Gmail (web): Strips @font-face. Fallback always.
Gmail (iOS + Android app): Partially supports @font-face. Inconsistent.
Outlook (Windows desktop): Does not support web fonts. Renders Word-style.
Outlook (web / OWA): Supports @font-face more reliably.
Samsung Email: Supports @font-face.
Thunderbird: Limited support.
Gmail, the most-used email client in the world, doesn't support custom fonts in its web interface! That means for a huge portion of your list, your font will always be a fallback, unless the subscriber is using an Apple device. For an always-updated reference on what each client supports, caniemail.com is the go-to resource.
What Klaviyo, Customer.io, and other ESPs actually support
Klaviyo
If you still want to use custom fonts to render essentially on Apple devices-only, Klaviyo supports custom fonts via @font-face in its HTML editor. You can link to a Google Font or host your own font files and reference them in the email's <head>. The implementation works and the font will load in clients that support it.
The catch: Klaviyo's drag-and-drop editor doesn't expose this. You're working in the HTML editor or via their template API to get it done. For teams using the visual builder exclusively, custom fonts aren't accessible without custom code blocks.
Klaviyo's recommended stack for fallback fonts is safe but generic: Arial, Helvetica, sans-serif or Georgia, Times New Roman, serif. Make sure your fallback doesn't create a jarring size or weight shift, more on this below.
Customer.io
Customer.io is similar. Their Visual Editor doesn't natively surface font-family controls beyond a limited set of web-safe options. In their code editor or via API-managed templates, you can inject @font-face declarations in the <head> and reference custom fonts throughout.
One thing to watch with Customer.io: when you switch between their editors (visual to code), you can lose the custom CSS you've added. Always keep a backup of your font declarations and check them after any template edits.
Iterable, Braze, SFMC
Similar story across the board. HTML-level font support is usually possible through code access. Visual editors either don't expose it or limit options to safe fonts. SFMC in particular has notoriously complex template management font declarations in content blocks vs. layouts that can conflict if you're not careful. For teams coding emails with MJML, the Scalero MJML resources are a solid reference for handling custom fonts cleanly.
How to write a bulletproof font stack
Whether or not your custom font loads, you need a fallback stack that doesn't embarrass you. Here's the principle: your fallback should be close enough in weight, x-height, and proportions that the layout doesn't break when it kicks in.
Bad fallback: font-family: 'Canela', serif; - jumps from a light editorial serif to Times New Roman, blows up the line lengths and visual rhythm.
Good fallback: font-family: 'Inter', -apple-system, BlinkMacSystemFont, 'Segoe UI', Arial, sans-serif; - degrades gracefully through system UI fonts before landing on Arial.
The system font stack (-apple-system, BlinkMacSystemFont, Segoe UI) is underused in email. It gives you the clean, native-feeling typeface of the user's OS which is often more appropriate than Arial anyway, and almost always better than Times New Roman.
Size, line-height, and mobile
Typography in email needs to work at mobile scale first. The minimum recommended body copy size is 14px; 16px is safer for readability on small screens. And line-height should be at least 1.4 to 1.6 for body text. These aren't optional nice-to-haves. They're table stakes for scannability. We wrote about designing for skimmability in our post on making emails easy to read, which covers the broader layout side of this.
Designing for fallback in Figma
Here's a workflow tip that saves headaches: design your email twice in Figma. Once with your brand font, once with your fallback font. Check how the layout holds up when Inter or Georgia replaces your custom typeface.
If a subhead that works at 32px in your brand font suddenly breaks layout at the same size in Arial, that's a problem you want to find in Figma, not in a QA email. Building this into your design process is a small step toward a much more consistent email design system.
Custom fonts in email are worth pursuing; they contribute to brand recognition and make your emails feel distinctive. But they require a realistic understanding of where they'll render and a fallback strategy that's actually been designed, not just declared.
Know your audience's primary email clients. Build your fallback stack thoughtfully. And always check how your typography behaves in the clients that matter most to your list.
