
How to choose fonts for email newsletters?
- Sajjad
- Typography
- 11 Oct, 2026
To choose fonts for email newsletters, start from fonts that are already installed on readers' devices, such as Arial, Helvetica, Georgia, Verdana, Tahoma, Trebuchet MS or the system UI font, because many email clients don't load web fonts. You can add a brand web font for headings or body text, but treat it as an enhancement: Apple Mail and some other clients will show it, while Gmail, Yahoo and Outlook on Windows will use your fallback instead. That means the fallback is what a large share of your readers actually see, so choose it as carefully as the web font. Keep body text at around 16px with a line height of about 1.5, use real text rather than images of text, and test in the clients your subscribers use.
Email is a much more restricted environment than the web. There is no single rendering engine, CSS support varies widely between clients, and some clients rewrite or strip styles. A font setup that works perfectly in a browser can fall back to Times New Roman in Outlook or be ignored entirely in Gmail. In this article you'll learn how email clients handle fonts, which fonts are safe, how to add a web font without breaking Outlook, how to size and space text for reading on phones, and how to test the result.
How Email Clients Handle Fonts
An email client displays the HTML you send using its own engine, and each has its own rules.
- Apple Mail on macOS and iOS: Uses WebKit and supports web fonts loaded with
@font-face,@importor alinkelement. It also understands the Apple system font through-apple-system. - Gmail: Doesn't load custom web fonts on its web or mobile apps. It renders your fallback stack, using fonts available on the device.
- Outlook on Windows (classic desktop): Renders HTML with Microsoft Word's engine. It doesn't load web fonts, and if the first font in your stack isn't installed it may ignore the rest and fall back to Times New Roman.
- Outlook.com, the new Outlook and Yahoo Mail: Web fonts generally aren't loaded, so expect the fallback.
- Other clients: Thunderbird and some versions of Samsung Email and other mobile apps support web fonts, but support changes between versions.
Because support shifts over time, check an up-to-date reference such as caniemail.com for the specific features you rely on.
Choosing Safe Fonts
"Email-safe" fonts are those installed by default on most operating systems, so they render without downloading anything. The most dependable are:
| Font | Type | Notes |
|---|---|---|
| Arial | Sans-serif | Installed on Windows and macOS; Android substitutes a similar sans |
| Helvetica | Sans-serif | macOS and iOS; usually listed alongside Arial |
| Verdana | Sans-serif | Wide, very legible at small sizes, takes up more space |
| Tahoma | Sans-serif | Narrower relative of Verdana, common on Windows |
| Trebuchet MS | Sans-serif | Humanist feel, a little more personality |
| Georgia | Serif | Designed for screens, a good choice for editorial newsletters |
| Times New Roman | Serif | Universal, but looks dated and small on screen |
| Courier New | Monospace | For code snippets or a typewriter effect |
You can also use the platform UI fonts through a system stack, which looks native in Apple Mail and on many phones:
font-family: -apple-system, BlinkMacSystemFont, "Segoe UI", Roboto, Helvetica, Arial, sans-serif;
Keep a classic font such as Arial near the end, so every client finds something it recognises.
Matching a Fallback to Your Brand Font
Pick the safe font closest in proportions to your brand font, so the email looks similar for everyone:
- A geometric or neo-grotesque sans such as Inter or Montserrat: fall back to Helvetica, Arial.
- A humanist sans such as Lato or Source Sans 3: try Trebuchet MS or Verdana, then Arial.
- A text serif such as Merriweather or Lora: fall back to Georgia.
Adding a Web Font Safely
If you want your brand font in clients that support it, load it in the head and list it first in the font stack, followed by your chosen fallbacks.
<!doctype html>
<html lang="en-GB" xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<meta name="x-apple-disable-message-reformatting">
<meta name="color-scheme" content="light dark">
<meta name="supported-color-schemes" content="light dark">
<title>Monthly update</title>
<!--[if !mso]><!-->
<link href="https://fonts.googleapis.com/css2?family=Lora:wght@400;700&display=swap" rel="stylesheet">
<!--<![endif]-->
<!--[if mso]>
<style>
body, table, td, h1, h2, p, a {
font-family: Georgia, "Times New Roman", serif !important;
}
</style>
<![endif]-->
<style>
body {
margin: 0;
padding: 0;
-webkit-text-size-adjust: 100%;
}
.body-text {
font-family: "Lora", Georgia, "Times New Roman", serif;
font-size: 17px;
line-height: 1.55;
color: #1f1f1f;
}
@media (prefers-color-scheme: dark) {
.body-text { color: #e8e8e8 !important; }
}
</style>
</head>
<body>
<table role="presentation" width="100%" cellpadding="0" cellspacing="0" border="0">
<tr>
<td align="center" style="padding: 24px 16px;">
<table role="presentation" width="100%" cellpadding="0" cellspacing="0" border="0" style="max-width: 600px;">
<tr>
<td>
<h1 style="margin: 0 0 16px; font-family: 'Lora', Georgia, 'Times New Roman', serif; font-size: 28px; line-height: 34px; font-weight: 700; color: #1f1f1f;">
What we shipped in October
</h1>
<p class="body-text" style="margin: 0 0 16px; font-family: 'Lora', Georgia, 'Times New Roman', serif; font-size: 17px; line-height: 26px; color: #1f1f1f; mso-line-height-rule: exactly;">
Three features, one fix you asked for, and a look at what's next.
</p>
</td>
</tr>
</table>
</td>
</tr>
</table>
</body>
</html>
The important details:
- The conditional comment around the font link hides it from Outlook on Windows, which can otherwise misbehave when it meets web font declarations.
- The MSO-only style block forces Outlook to use Georgia. Without it, Outlook may skip past "Lora" and land on Times New Roman.
- Inline font styles on each text element keep the stack in place even in clients that strip or limit
styleblocks. Many email build tools inline styles automatically. - Line heights in pixels with
mso-line-height-rule: exactlystop Outlook from adding unpredictable extra spacing.
Using @font-face Directly
If you self-host the font, declare it inside a media query, which Outlook on Windows ignores:
@media screen {
@font-face {
font-family: "Brand Sans";
src: url("https://cdn.example.com/fonts/brand-sans-regular.woff2") format("woff2"),
url("https://cdn.example.com/fonts/brand-sans-regular.woff") format("woff");
font-weight: 400;
font-style: normal;
}
}
Host the files on a fast HTTPS server, keep them small, and limit yourself to one or two weights. Some clients download fonts only when the email is opened, so heavy files delay rendering.
Check your licence too. Some commercial font licences cover websites but not email, which is usually licensed separately.
Size, Spacing and Layout for Reading
Most newsletters are read on phones, often quickly. Typography settings should favour comfortable reading at a glance.
- Body text: 16 to 18px. Below 14px, text becomes hard to read on phones, and iOS Mail may enlarge very small text on its own, which can break layouts.
- Headings: Around 22 to 32px for the main heading and 18 to 22px for section headings, in a bold weight.
- Line height: Roughly 1.4 to 1.6 times the font size for body text. In pixels, 16px text works well with 24px line height.
- Line length: A 600px content width with comfortable padding keeps lines to a readable length on desktop.
- Alignment: Left-align body text. Centred paragraphs are hard to read beyond a line or two.
- Links and buttons: Make links visibly different from body text, usually underlined, and set button text at 16px or larger in a bold weight.
Here is a button that keeps its font and sizing in every client, using a table cell and inline styles:
<table role="presentation" cellpadding="0" cellspacing="0" border="0">
<tr>
<td style="border-radius: 6px; background: #1a5fb4;">
<a href="https://example.com/october"
style="display: inline-block; padding: 12px 22px; font-family: Helvetica, Arial, sans-serif; font-size: 16px; line-height: 20px; font-weight: 700; color: #ffffff; text-decoration: none;">
Read the full update
</a>
</td>
</tr>
</table>
Using a safe font for buttons is deliberate: a button label is a call to action, and it should look the same everywhere.
Avoid Text in Images
It's tempting to put a brand-font headline into an image so it looks identical in every client. Doing so has serious downsides:
- Many clients block images until the reader allows them, so the headline disappears.
- Screen readers only get the alt text.
- Image text can't be resized, selected, searched or translated.
- Dark mode can make image backgrounds clash with the surrounding email.
If you must use an image for a logo or a special headline, always add meaningful alt text and keep the rest of the message in live text.
Dark Mode
Several clients apply dark mode to emails, and they handle it differently: some respect your prefers-color-scheme styles, some invert colours automatically and some leave the email alone.
- Avoid very thin font weights. Light text on dark backgrounds looks bolder, but thin strokes can break up when colours are inverted.
- Don't rely on pure black text on pure white; slightly softer colours survive automatic inversion better.
- Test transparent logos against dark backgrounds.
Testing Your Fonts
Before sending to your full list:
- Send test emails to accounts in the clients your audience uses most. Your email platform's reports usually show the client breakdown.
- Check the fallback deliberately: View the email in Gmail and Outlook on Windows, where the web font won't load, and make sure it still looks intentional.
- Use a preview service such as Litmus or Email on Acid if you need to cover many clients and versions.
- Read it on a phone in daylight. If you squint, increase the size.
Some email platforms also strip link elements or unusual CSS during sending, so test with the actual platform, not just a local HTML file.
FAQ: Fonts for Email Newsletters
Yes, by linking the font in the email's head. Clients such as Apple Mail will display it, while Gmail, Yahoo and Outlook on Windows will use your fallback fonts instead.
Classic Outlook on Windows may not move past a font it doesn't recognise. Add an Outlook-only style block that sets a safe font such as Arial or Georgia, and hide web font links from Outlook with conditional comments.
Use 16 to 18 pixels for body text, with a line height of about 1.5. Most newsletters are read on phones, where smaller text quickly becomes hard to read.
Gmail doesn't load custom web fonts in its web or mobile apps. It uses the fonts listed later in your font stack that are available on the device.
Both work. Sans-serifs such as Arial, Helvetica and Verdana are the most common, while Georgia is a strong serif option for editorial newsletters. Choose based on your brand and your fallback.
Only sparingly. Images are often blocked by default and can't be read by screen readers beyond their alt text. Keep important text live and use images for decoration or logos.
Conclusion
Fonts in email newsletters work best when you plan for the clients that ignore web fonts. Choose an installed, email-safe font that suits your brand, such as Arial, Helvetica, Verdana or Georgia, and if you add a web font, load it as an enhancement with conditional comments, an Outlook-specific fallback and inline font stacks on every text element.
Set body text at 16 to 18 pixels with comfortable line height, keep text live rather than baked into images, and test in Gmail, Outlook and Apple Mail with your real sending platform. The result is a newsletter that looks deliberate in every inbox, whether or not the brand font appears.


