Design, 12 min read
The Ultimate Guide to Email Fonts
Everything you need to know about choosing, embedding, and fallback-stacking fonts in HTML email — from web-safe classics to Google Fonts, with a full client support matrix.
Typography is one of the most powerful tools in an email designer's kit. The right font makes copy feel trustworthy, premium, or playful — and the wrong font choice, or a missing fallback, can turn a polished campaign into a wall of Times New Roman.
The challenge? Email clients are not browsers. The same CSS rules that work perfectly on your website may be stripped, ignored, or overridden the moment your email hits a Gmail inbox. Understanding how fonts work in email is one of the most important — and most frequently misunderstood — skills in email development.
This guide covers everything: web-safe fonts, custom font embedding via @font-face, Google Fonts, the full client support matrix, recommended stacks, sizing guidelines, and the eight most common mistakes that silently break your typography.
Why fonts matter (differently) in email
On the web, if a custom font fails to load, the browser shows a flash of invisible or unstyled text, then settles on the fallback. Users barely notice. In email, the story is different:
- No live reload. Once delivered, an email is static. If your font stack has no usable fallback, the recipient sees whatever the email client decides — often Times New Roman.
- Client rendering diversity. Gmail strips most <style> blocks. Outlook for Windows uses Microsoft Word's layout engine, which ignores @font-face entirely. Apple Mail renders web fonts beautifully. These clients share the same inbox.
- Deliverability side-effects. Bloated font imports or inline styles add to message weight, which can tip you over limits on some ESPs or cause clipping in Gmail (which clips emails over ~102 KB).
- Brand perception. Typography is a brand signal. A brand that uses Inter or DM Sans on its website but delivers Times New Roman emails signals inconsistency — even if subscribers can't articulate why.
The good news: with the right font stack strategy, your email looks great on every client — custom font where supported, a well-chosen fallback everywhere else.
Web-safe fonts: the reliable foundation
Web-safe fonts are typefaces that ship pre-installed on virtually every operating system — Windows, macOS, Linux, iOS, and Android. Because they live on the device, no downloading is needed and they render identically across every email client.
You should always end your font stack with a web-safe font. No exceptions.
Sans-serif
| Font | Best for | Notes |
|---|---|---|
| Arial | Body text, UI-style emails | The de-facto standard. Neutral, legible at any size. |
| Helvetica | Brand-forward, neutral layouts | macOS/iOS default; Arial renders on Windows where Helvetica is absent. |
| Verdana | Small body text, accessibility | Wider letter-spacing aids legibility at small sizes. |
| Trebuchet MS | Friendly, slightly quirky tone | More personality than Arial without being unusual. |
| Tahoma | Compact UIs, smaller text | Slightly narrower than Verdana; good for dense layouts. |
| Geneva | macOS/iOS only fallback | Only include after Verdana in stacks — rare on Windows. |
Serif
| Font | Best for | Notes |
|---|---|---|
| Georgia | Editorial, premium, storytelling | High readability on screens. The best web-safe serif by far. |
| Times New Roman | Avoid as a choice; accept as fallback | Email-client default if nothing else matches. Design for its appearance. |
| Palatino Linotype | Publishing, long-form newsletters | Elegant but rarer — use with Georgia as a prior fallback. |
Monospace
| Font | Best for | Notes |
|---|---|---|
| Courier New | Code snippets, dev-focused emails, retro aesthetic | Safe everywhere; the standard monospace fallback. |
| Courier | macOS/iOS variation | Virtually identical to Courier New; add it before for macOS users. |
Custom & Google Fonts via @font-face
Custom web fonts bring your brand typography into the inbox — but only where the email client allows it. The two common methods are:
Method 1: Google Fonts via <link> (recommended)
Place a <link> tag inside the <head> of your email HTML. This is the most reliable method for clients that support remote stylesheets.
<head>
<link
rel="stylesheet"
href="https://fonts.googleapis.com/css2?family=Inter:wght@400;600;700&display=swap"
/>
</head>
<body>
<p style="font-family: 'Inter', Arial, sans-serif; font-size: 16px;">
Your email body text here.
</p>
</body>Method 2: @import inside <style>
Some email clients support @import inside a <style> block. It is slightly less reliable than <link> but useful as a fallback when you cannot control the <head> tag.
<style>
@import url('https://fonts.googleapis.com/css2?family=Inter:wght@400;600;700&display=swap');
body {
font-family: 'Inter', Arial, sans-serif;
}
</style>Method 3: Self-hosted @font-face
For brand fonts not on Google Fonts, or when you need offline reliability, host the font files yourself and declare them via @font-face.
<style>
@font-face {
font-family: 'BrandFont';
src: url('https://yourdomain.com/fonts/brandfont-regular.woff2') format('woff2'),
url('https://yourdomain.com/fonts/brandfont-regular.woff') format('woff');
font-weight: 400;
font-style: normal;
font-display: swap;
}
@font-face {
font-family: 'BrandFont';
src: url('https://yourdomain.com/fonts/brandfont-bold.woff2') format('woff2'),
url('https://yourdomain.com/fonts/brandfont-bold.woff') format('woff');
font-weight: 700;
font-style: normal;
font-display: swap;
}
</style>@font-face block, adding unnecessary overhead and increasing the chance your email gets clipped by Gmail's 102 KB limit..woff2 with a range axis) are not broadly supported in email clients. Stick to individual weight files for maximum compatibility.Client-by-client support matrix
This is the data that saves campaigns. Knowing which clients render custom fonts — and which silently fall back — determines how much you invest in custom font polish.
| Email client | Market share* | @font-face | Google Fonts <link> | Notes |
|---|---|---|---|---|
| Apple Mail (macOS) | ~11 % | ✓ Full | ✓ Full | Best custom-font support of any desktop client. |
| Apple Mail (iOS) | ~28 % | ✓ Full | ✓ Full | Full support. The largest single client — worth investing in custom fonts. |
| Gmail (browser) | ~26 % | ✗ None | ✗ None | Strips all <style> and external link tags. Fallback font always renders. |
| Gmail (Android) | ~9 % | ✗ None | ✗ None | Same as Gmail web — no custom font support. |
| Outlook 2016–2021 (Windows) | ~9 % | ✗ None | ✗ None | Uses Word rendering engine. Respects inline font-family only for installed system fonts. |
| Outlook for Mac | ~4 % | ~ Partial | ~ Partial | Outlook 2019+ for Mac is WebKit-based — respects web fonts. 2011 does not. |
| Outlook.com (new) | ~3 % | ✓ Full | ✓ Full | The new Outlook.com web client (2023+) has solid web font support. |
| Samsung Mail | ~3 % | ✓ Full | ✓ Full | Good support. Renders web fonts reliably. |
| Yahoo Mail | ~3 % | ✗ None | ✗ None | Strips most <style> tags. Fallback renders. |
| Thunderbird | < 1 % | ✓ Full | ✓ Full | Full support — Gecko-based renderer. |
* Approximate global market share, 2025–2026. Figures vary significantly by industry and audience.
Recommended font stacks
A font stack is the ordered list you pass to font-family. The email client tries each font in order, using the first one it can find. The last entry should always be a generic family (serif, sans-serif, or monospace) so the OS picks a reasonable default if nothing else matches.
Modern sans-serif (custom + safe fallback)
font-family: 'Inter', -apple-system, BlinkMacSystemFont, 'Helvetica Neue', Arial, sans-serif;
This stack shows Inter on Apple Mail, iOS, and Outlook.com (all load the Google Font). On Gmail it falls back to Helvetica Neue (macOS/iOS) or Arial (Windows/Android) — both clean, neutral sans-serifs that barely break the design.
Elegant serif (editorial, storytelling, newsletters)
font-family: 'Playfair Display', 'Palatino Linotype', Palatino, Georgia, 'Times New Roman', serif;
Playfair Display on supporting clients. Georgia on Gmail and Windows Outlook — a graceful serif that still looks intentional. Never falls back to bare Times New Roman without a fight.
Friendly rounded (consumer / lifestyle brands)
font-family: 'Nunito', 'Trebuchet MS', Verdana, Geneva, Arial, sans-serif;
Technical / developer (SaaS, development tools)
font-family: 'DM Mono', 'Courier New', Courier, monospace;
System UI (no external font dependency)
font-family: -apple-system, BlinkMacSystemFont, 'Segoe UI', Roboto, Oxygen,
Ubuntu, Cantarell, 'Helvetica Neue', Arial, sans-serif;The system UI stack means subscribers always see the native default sans-serif for their OS — SF Pro on Apple, Segoe UI on Windows, Roboto on Android. Loads instantly, zero external dependency, always looks clean. A strong default choice when custom fonts are not a priority.
Font sizing & line-height guidelines
Sizing rules for email are stricter than for the web. Email is read on everything from a 5-inch phone screen to a 32-inch monitor, often at arm's length — and you cannot rely on the reader zooming in.
Recommended sizes
| Element | Minimum | Recommended | Notes |
|---|---|---|---|
| Body / paragraph | 14 px | 15–16 px | Use 16 px to prevent iOS auto-zoom on form inputs. |
| Caption / legal text | 12 px | 13 px | Never go below 11 px — many clients will ignore smaller text. |
| CTA button | 15 px | 16–18 px | Larger text improves tap target legibility on mobile. |
| H3 / sub-heading | 16 px | 18–20 px | Just enough to differentiate from body without dominating. |
| H2 / section heading | 20 px | 22–28 px | Should read clearly at a glance when scanning. |
| H1 / hero headline | 28 px | 32–48 px | Scale down on mobile (use max-width + fluid sizing). |
| Preheader text | — | 0 px (hidden) | Hidden with font-size:0; line-height:0; max-height:0; overflow:hidden. |
<a> styled as a button) when the page font size is below 16 px. Set the minimum body font-size to 16px in mobile-targeted styles, or set -webkit-text-size-adjust: 100% on the <body>.Line height
Line height is the single most impactful readability setting and is routinely under-used in email. Tight line height feels dense and exhausting; too loose feels disconnected.
| Element | Value | Reasoning |
|---|---|---|
| Body text | 1.5–1.6 | The sweet spot for comfortable reading across all screen sizes. |
| Headings (H1/H2) | 1.1–1.25 | Tight but not cramped — keeps multi-line headlines visually tied. |
| Sub-headings (H3) | 1.3–1.4 | Slightly more breathing room than H1/H2. |
| CTA buttons | 1.2–1.4 | Consistent with tap target height; don't let text wrap inside a button. |
| Legal / caption | 1.4–1.5 | Small text needs generous spacing to stay readable. |
line-height values (like 1.5). Always add a pixel value fallback: line-height: 1.5; mso-line-height-rule: exactly; — the mso-line-height-rule property prevents Outlook from adding extra spacing between lines.Weight, style & letter-spacing
Font weight
Not all font weights render consistently across email clients, even when the font is loaded.
400 (regular)— Safe. Universal. Use for body copy.700 (bold)— Safe. Renders as bold in virtually every client.500 / 600 (medium / semi-bold)— Supported in modern clients but Outlook for Windows may round to 400 or 700. If visual accuracy matters, test in Outlook and consider using only 400/700.100–300 (thin / light)— Often too faint on low-contrast screens. Not recommended for body text.800–900 (extra-bold / black)— Useful for impactful hero headlines, but verify the custom font supports this weight before loading it.
Italic
Italic works reliably in most clients when using web-safe fonts. For custom fonts, load the italic variant explicitly via a separate @font-face rule with font-style: italic. If you don't, the browser will synthesise an italic by slanting the regular variant — which often looks poor.
Letter-spacing
letter-spacing is widely supported across modern email clients. Use it sparingly:
- Headings: 0.5–1 px (or -0.5 px to tighten large display text)
- Small caps / labels: 1–2 px — greatly improves legibility of all-caps text
- Body text: 0 px — extra tracking on small text reduces readability
- Never use letter-spacing on preheader / hidden text (breaks reading order in some accessibility tools)
Readability & accessibility
Email accessibility is often the first thing cut for speed, and the first thing that costs you subscribers. The good news: accessible typography is also just better typography.
Colour contrast
The WCAG AA standard requires a contrast ratio of at least 4.5:1 for normal text and 3:1 for large text (18 px+ or 14 px bold). In practice:
- Dark text on white: #222 or #333 is safer than #999, which fails AA at any size.
- Light text on dark: White (#fff) on a mid-dark background (#444 or below) typically passes. Off-white (e.g. #e5e5e5) on pure black can feel harsh — try #d0d0d0 for a softer pairing.
- Coloured text: Brand colours often fail contrast checks when used for body text. Use them for headings or on appropriately dark/light backgrounds.
Don't rely on font style alone to convey meaning
Screen readers do not announce bold or italic by default. If content is critical — an expiry date, a warning — supplement font styling with explicit text (e.g. "Expires: March 31" rather than just bolding "March 31").
Minimum touch target size
Apple and Google recommend a minimum tap target of 44 × 44 px. For text links inline in a paragraph, this cannot always be achieved — but CTA buttons should always meet this threshold, both in height (via padding) and in the font size used.
8 common font mistakes to avoid
No fallback font
Setting font-family to only a custom web font means Gmail users see Times New Roman. Always end every stack with a web-safe font and the generic family.
Fallback looks nothing like the custom font
Using a decorative display font as primary with Arial as the fallback creates a jarring visual switch for the 40 % who don't get the web font. Pick a fallback that has similar proportions: Inter → Helvetica Neue / Arial; Playfair Display → Georgia.
Loading too many font weights
Google Fonts URLs grow with each weight. &family=Inter:wght@100;200;300;400;500;600;700;800;900 loads nine weights and can add 150–200 KB to the email before the message even begins — triggering Gmail's clipping threshold.
Font size below 14 px for body
Sub-14 px text fails legibility checks on mobile, fails accessibility contrast checks at lower weights, and triggers auto-zoom in iOS Safari. Set a 15–16 px minimum and use font-size-adjust or mso-line-height-rule for Outlook.
Tight line-height on long copy
A line-height of 1.0–1.2 on body text (not headlines) is tiring to read, especially on mobile. The minimum for comfortable reading is 1.4; 1.5–1.6 is the standard for prose.
Omitting mso-line-height-rule for Outlook
Outlook for Windows adds extra space between lines by default. Without mso-line-height-rule: exactly, a line-height of 1.5 may render as 2.2 in Outlook, disrupting spacing-dependent layouts.
Using more than two typefaces
Two fonts maximum: one for headings, one for body (or a single font family with weight variation). More than two creates visual noise and slows load time. The exception: monospace code snippets in dev-focused emails.
Never testing in Gmail
Because Gmail strips all web fonts and all <style> blocks, it is the most important test environment. If your email looks polished in Gmail with the fallback font, it will look great everywhere. Test in Gmail — both browser and mobile app.
Quick-reference cheat sheet
Email Font Cheat Sheet
Put it into practice
Ship better-looking emails — starting now.
Emlet applies all of these font-stack best practices automatically. Every email it generates uses proper fallback stacks, correct sizing, and tested line-heights — across Gmail, Outlook, and Apple Mail.