The Right Font-Family Stack for HTML Email (and Why the Order Matters)

Most email templates start with font-family: Arial, Helvetica, sans-serif, and nobody on the team could tell you why those three names, in that order, over any other combination. The order isn't decoration. It's a fallback sequence, and getting it wrong is exactly why some emails render in Times New Roman for no reason anyone can immediately explain.

How a font stack actually resolves

A font-family declaration is a priority list, not a single choice. Whichever rendering engine a given client happens to use reads the first name, checks whether a font by that exact name is installed or already loaded, and if not, moves to the next name, and the next, until it either finds a match or reaches the final generic keyword (sans-serif, serif, or monospace), which every client maps to some default installed font of that general shape. Leave off the generic keyword at the end and you're gambling on the recipient's device having at least one of your named fonts installed, which for an older Android phone or a Linux desktop running a non-Google mail app is a real risk, not a theoretical one.

Ready-to-use stacks

If you want a real custom font in that first slot

Nothing stops you from putting a web font first in any of these stacks, for example 'Poppins', Arial, Helvetica, sans-serif. Just treat everything after the first name as what most of your list will actually see. Roughly a third to over half of email opens, depending on whose methodology you trust, will render a correctly embedded web font; the rest render whichever fallback comes next. Which clients actually render a custom font and which silently substitute is its own mechanism, different enough from plain font-family stacking that it's worth understanding on its own before you commit a brand headline to a font a large part of your list will never see.

The naming detail that breaks stacks silently

Multi-word font names need quotes: 'Times New Roman', not Times New Roman unquoted. Without quotes, some rendering engines read Times, New, and Roman as three separate, mostly nonexistent font names, and quietly skip straight to the next entry in the stack. It's a one-character fix that's easy to miss, because the email still renders, it just renders one step further down the fallback list than intended, which is the kind of bug that never throws an error and just makes an email look slightly off in a way nobody can immediately name.

One more thing worth checking before a send goes out: the stack should be identical across every element that shares a visual style, headers, body text, buttons. A stack that's quoted correctly in one place and unquoted in another will render consistently in some clients and inconsistently in others, and the inconsistency is the kind of thing a recipient notices without being able to say exactly why.