The first consideration to take into account when working with custom fonts is that email client support is patchy. The following email clients support custom fonts:
Apple Mail
iOS Mail
Samsung Mail
It's important to define a font stack when using custom fonts. This should include some standard system fonts to make sure that your email renders for clients that don't support custom fonts.
Example: 'OpenSansBold', Helvetica, Arial, sans-serif
To host your custom fonts, you can either use a service such as Google Fonts or host them yourself. You can add your Google Font directly. Refer to the following image.
For situations where your custom fonts aren't supported, you should select fallbacks that are included on the majority of computers. These fallbacks define what fonts will be displayed if the email client doesn't support custom fonts. Here is a website for fallback fonts:
Please Note: You may need to reach out to a developer for assistance if you don’t have the expertise.
The most reliable way to include a specific font in your email is to use @font-face. Below is an example of this in action:
<style> @font-face { font-family: 'Festive', cursive; src: url('https://fonts.googleapis.com/c...') }
* { font-family: 'Festive', cursive; }
</style>
When you are within the email builder you would add custom CSS on the Appearance tab
When you are using the email builder in a workflow you can add custom code as well. See the screenshot below:
Please Note: When working with Outlook, you need to wrap this @font-face in a @media tag. This is because Outlook 2007, 2010, and 2017 don't support them.
Please Note: If you want to use the custom font in the builder you can copy the custom font code and make a custom value for it and use the custom value.
Always Define a Font Stack: Ensure you include fallback fonts in your font stack, such as 'OpenSansBold', Helvetica, Arial, sans-serif, to maintain consistency across email clients that do not support custom fonts.
Use Web-Safe Fonts as Fallbacks: Select fallback fonts that are universally available, like those listed on websites like CSS Font Stack.
Test Emails Across Clients: Before sending your email campaign, test how the custom font renders across different email clients to avoid unexpected visual issues.
Optimize for Outlook: Wrap the @font-face rule in a @media tag when targeting email clients like Outlook 2007, 2010, and 2017 to prevent rendering issues.
Host Fonts Securely: Use a reliable service like Google Fonts or a secure self-hosted server to ensure fonts are accessible during email rendering.
1. Which email clients support custom fonts?
Apple Mail, iOS Mail, Samsung Mail, and Outlook.com support custom fonts. However, many other email clients rely on fallback fonts.
2. How do I add a custom font to an email template?
You can include custom fonts using the @font-face rule in the <style> section of your email. Make sure to add the code in the Appearance tab or through custom CSS in the email builder.
3. What happens if a custom font isn’t supported by the recipient’s email client?
If the client doesn't support custom fonts, the email will default to the fallback fonts defined in your font stack.
4. Can I use Google Fonts in my email templates?
Yes, you can include Google Fonts by linking directly to their hosted font files using @font-face. Ensure you have proper fallbacks for unsupported clients.
5. Why is custom font rendering inconsistent in Outlook?
Outlook versions 2007, 2010, and 2017 don't support custom fonts unless wrapped in a @media tag. Without this, the custom font may not render properly.
