How to use email-safe, web, and custom fonts in email campaigns?

Typography is one of the easiest ways to express your brand in email. It is also one of the most fragile. The same font that looks crisp on your website can render as Times New Roman in Outlook or silently fall back to Arial in Gmail without any error or warning. Your subscriber just sees a slightly different email than the one you designed.

This article explains the three font categories Stripo gives you, where each one actually works, and what to check on your font's source URL before you start using it across campaigns.

If you're looking for steps on how to add a custom font to your account, see Managing custom fonts.

Web and custom fonts use the same loading mechanism. They are fetched from an external URL when the email is opened. The difference is how they are added in Stripo.

The email safe fonts in Stripo (Arial, Helvetica, Georgia, Times New Roman, Verdana, Trebuchet MS, Courier New, Tahoma, and similar) are widely available across operating systems and supported by all major email clients. They render as standard text without any additional setup.

Email safe fonts ensure consistent rendering across:

They are recommended for transactional emails and any campaigns where consistent appearance is critical.

Web fonts allow you to use custom typography in email instead of only system fonts. They are loaded from an external source when the email is opened.

Web fonts can be connected using <link>, @import, or @font-face. These are different methods of adding the font, and they are explained in How to choose between link, import, and font-face.

Support for web fonts in email is limited. According to caniemail.com, only about a quarter of email clients fully support the @font-face rule.

Here is the breakdown for the most commonly used email clients:

In practice, this means that in a significant part of email environments, web fonts will not be displayed.

Instead, the email client will automatically switch to your fallback font or its default typeface.

Web fonts are still useful in two cases:

The key point is that web fonts should not be treated like web fonts on websites. They are not universally supported in email, so the fallback font is what actually defines how your email will look in many cases.

When you add a custom font, Stripo doesn't host the font file. You point us at a URL where the font lives — yours, a CDN, Google Fonts, Adobe Fonts. For that font to load successfully in subscribers' email clients, three things have to be true on the server side.

The URL must start with https:// and the SSL certificate must be valid, not expired, not self-signed, and issued for the correct domain. Email clients block mixed content, HTTP resources requested from an HTTPS rendered email, so a font served over plain HTTP will silently fail to load even in clients that otherwise support web fonts.

Fonts are subject to Cross-Origin Resource Sharing (CORS) rules. If a font is hosted on a different domain, the server must allow it to be used in email.

If CORS is not configured correctly, the font may be blocked even if the URL is accessible.

This issue often occurs with self-hosted fonts. Services like Google Fonts and Adobe Fonts already include the correct configuration by default.

If you host fonts on your own server, make sure CORS is enabled for font files.

For more information, see How to set up CORS policy for fonts.

A single font URL should resolve to one font family. If you point Stripo at a Google Fonts URL that bundles three different families, for example, family=Roboto|Open+Sans|Lato, the connection will fail with a validation error in the add font pop-up.

The issue should be fixed at the source. Generate a separate URL for each font family you need and add them one at a time. You can still include multiple weights of the same family in a single URL, for example, Roboto:wght@400;700, which is one family with two weights and fully supported.

Email clients do not show error messages when a web font fails to load. They quietly fall back. The fallback they use depends on what you specified and what they default to if you did not.

If you set a font stack like 'YourBrandFont', Arial, sans-serif, an email client that does not support web fonts will skip YourBrandFont and render with Arial. If Arial is not available (rare), it falls through to the generic sans-serif.

If you set only the brand font with no fallback, each email client picks its own default.

This is why you should always specify a font family fallback with at least one email-safe font. The fallback ensures your email remains readable when a custom font cannot be loaded.

When you add or edit a custom font in Stripo, use the Font family fallback field to build this stack. Pick a fallback that is visually close to your brand font in width, x-height, and weight so the difference between "rendered" and "fallen back" is as small as possible.

For step-by-step instructions, see Managing custom fonts.

Before using a web or custom font in production:

Your fallback font should remain readable and visually consistent in unsupported email clients.

Thank you for taking the time to read our articles. We hope you will find this information helpful.

​If you have any additional questions, please email us at support@stripo.email.

We would be glad to talk with you.