How to Add Custom Fonts to Your Email Template
Add a custom font to your email template with @font-face and always a web-safe fallback, because Gmail and Outlook strip custom fonts.

Md. Yaikub Hossain Razon
Add a custom font to your email template by declaring it with @font-face or @import for clients that support web fonts, then pairing it with a web-safe fallback stack for the many that do not. Apple Mail renders custom fonts; Gmail and Outlook for Windows strip them and show your fallback instead.
The custom font is a preference, not a guarantee. Because major clients ignore it, the fallback you choose is what a large share of readers actually see - so it has to look just as intentional as your brand font.
Follow these steps to add a custom font:
- Choose the font and get its @font-face or @import code (for example, from Google Fonts).
- Place the font CSS in a <style> block near the top of the template.
- Write a font stack: your custom font first, then web-safe fallbacks.
- Apply the font-family inline on your text elements, not only in the head.
- Hide the web-font CSS from Outlook so it uses the fallback cleanly.
- Test in Apple Mail, Gmail, and Outlook before sending.
Do custom fonts work in email, and which clients support them?
Custom fonts work in some email clients and are stripped by others, so support is partial. Apple Mail on iOS and macOS renders custom web fonts well, and because Apple Mail accounts for roughly half of all email opens (about 51 percent in Litmus's early-2026 data), a custom font can reach a large share of a consumer audience. Gmail, Outlook for Windows, Outlook.com, and Yahoo Mail strip custom fonts and substitute a default.
|
Email client |
Custom font support |
Falls back to |
|---|---|---|
|
Apple Mail (iOS/macOS) |
Supported |
- |
|
Android default mail |
Supported |
- |
|
Gmail (web and app) |
Not supported |
Arial / Roboto |
|
Outlook for Windows |
Not supported |
Calibri (or Times New Roman) |
|
Outlook.com |
Not supported |
Default |
|
Yahoo Mail |
Not supported |
Default |
The practical takeaway: never rely on a custom font for readability. Each client has its own default - Gmail uses Arial, Apple Mail uses Helvetica, Outlook uses Calibri - so the design must hold together whether the custom font loads or not.
How do you add a custom font to your email template?
Add the font by embedding its CSS in the template head and referencing it in a font stack. There are three loading methods, and the reliable approach combines the first two.
- Get the font's @import and @font-face code - Google Fonts provides both for its free library at fonts.google.com.
- Place @font-face (and, for broader coverage, @import) inside a <style> block near the top of the email.
- Reference the font in a stack, custom font first: font-family: 'Poppins', Arial, Helvetica, sans-serif;.
- Apply that font-family inline on your headings, paragraphs, and buttons, because clients often strip <head> styles and inline declarations survive.
- Test the result in a client that supports web fonts (Apple Mail) and one that does not (Gmail or Outlook).
For the deeper technical detail on the loading methods, read how to add web fonts to HTML email safely. You can also skip the code entirely: set your brand font and fallback once in MailEditor's email editor, and it writes the font stack and inline styles into the template for you.
How do you set a web-safe fallback font stack?
Set a fallback stack by listing your custom font first, then one or more web-safe fonts, ending with a generic family. The client uses the first font it can render, so the order decides what non-supporting clients display.
A safe stack looks like this:
font-family: 'Poppins', Arial, Helvetica, sans-serif;
Here Poppins is the brand font, Arial and Helvetica are the web-safe fallbacks that ship on Windows and Apple devices respectively, and sans-serif is the final catch-all. Choose fallbacks that share the shape and weight of your custom font so the design stays consistent - a geometric sans-serif brand font pairs better with Arial than with a serif. Web-safe fonts such as Arial, Helvetica, Georgia, Verdana, and Tahoma are installed almost everywhere, which is why they anchor every reliable stack.
How do you stop Outlook from breaking your custom font?
Stop Outlook from breaking your font by hiding the web-font CSS from it, so it never registers the custom font name. Outlook for Windows uses the Microsoft Word rendering engine, and when it encounters a web-font declaration it cannot load, it can fall back to Times New Roman instead of your intended fallback.
The fix is an MSO conditional comment that keeps your @font-face and @import rules away from Outlook. With the web-font CSS hidden, Outlook skips straight to the next font in your stack - Arial or Helvetica - which is the fallback you designed. Always define the fallback inline on the element as well, so a stripped head style never leaves Outlook guessing. This one step is the difference between a clean Arial fallback and a broken Times New Roman signature across every Outlook inbox.
Custom fonts vs web-safe fonts: which should you use?
Use a custom font only when your audience skews toward clients that support it; otherwise, a web-safe font is the safer default. The choice depends on where your readers open email.
|
Use a custom font when |
Use a web-safe font when |
|---|---|
|
Your audience is Apple Mail / mobile heavy |
Your audience is Gmail or Outlook heavy (often B2B) |
|
Brand typography is a design priority |
Consistency across every client matters most |
|
You have a strong, matched fallback ready |
You want zero rendering surprises |
Many teams land on a hybrid: a custom brand font for headings, where the visual impact matters and Apple readers see it, and a web-safe font for body text, where readability everywhere matters more. For how typography choices affect the whole design, see our guide to email typography best practices.
What are the best practices for custom fonts in email?
These rules keep a custom font on-brand where it loads and clean where it does not:
- Always include a web-safe fallback stack. Never declare a custom font without fallbacks behind it.
- Apply font-family inline, not only in the head, so stripped <head> CSS does not remove your typography.
- Match the fallback to the custom font in shape and weight so both versions look intentional.
- Hide web-font CSS from Outlook with MSO conditional comments to avoid the Times New Roman fallback.
- Keep it to one or two fonts. More fonts add weight and inconsistency.
- Test in Apple Mail, Gmail, and Outlook for Windows at minimum, on desktop and mobile.
FAQ
Question:Do custom fonts work in email?
Answer: Partly. Apple Mail on iOS and macOS renders custom web fonts, but Gmail, Outlook for Windows, Outlook.com, and Yahoo Mail strip them and show a default. Because a large share of readers see the fallback, always pair a custom font with a web-safe fallback stack rather than relying on the custom font alone.
Question:How do I add a custom font to my email template?
Answer: Embed the font's @font-face or @import CSS in a style block near the top of the template, then reference it in a font-family stack with your custom font first and web-safe fallbacks after. Apply the font-family inline on your text elements, hide the web-font CSS from Outlook, and test across clients.
Question:What is a web-safe fallback font stack?
Answer: A fallback stack lists your custom font first, then fonts installed on most devices, ending with a generic family, for example: 'Poppins', Arial, Helvetica, sans-serif. Clients that cannot load the custom font use the next available one, so a well-chosen stack keeps the design consistent everywhere.
Question:Why does my email font change in Outlook?
Answer: Outlook for Windows uses the Word engine and does not load web fonts, and it can default to Times New Roman when it sees a web-font declaration. Hide the web-font CSS from Outlook with an MSO conditional comment and set the fallback inline so Outlook uses Arial or Helvetica instead.
Question:Should I use a custom font or a web-safe font in email?
Answer: Use a custom font if your audience is Apple Mail or mobile heavy and you have a strong matched fallback. Use a web-safe font if your audience skews Gmail or Outlook, common in B2B, where consistency matters most. A common hybrid uses a custom font for headings and a web-safe font for body text.
Popular Blogs

Email Design2 mins to read
Top Email Template Builders & HTML Email Editors for 2026
Compare the best email template builders and HTML editors to design professional, responsive campaigns without coding.

Email Tips7 mins to read
Best Drag and Drop Email Editors in 2026
Discover the best drag and drop email editors in 2026. Compare top tools, features, templates, pricing, and automation to build stunning emails fast.

Marketing7 mins to read
4 Best Unlayer Alternatives to Design Emails
Looking for Unlayer alternatives? Explore the 4 best email design tools to create beautiful, responsive emails faster and easier.

Marketing6 mins to read
5 Beefree Alternatives to Upgrade Email Design Workflows
Looking for a better email design tool? Explore 5 Beefree alternatives that streamline workflows, improve collaboration, and elevate email campaigns.

Email Design1 min to read
How to Create an HTML Email Template in Mailtrap
Follow this step‑by‑step guide to creating a responsive HTML email template in Mailtrap. Design, code, and customize your template with confidence.