Web fonts in email – working with web fonts vs fallbacks

Quick answer: Web fonts in HTML email load only in clients that fetch external fonts – mainly Apple Mail, iOS Mail, and Outlook for Mac, with Gmail limited to its own Roboto and a couple of others. Classic Outlook for Windows (the Word engine) ignores web fonts entirely and needs a carefully built fallback stack, or it defaults to Times New Roman. Roughly half your audience sees the fallback, so the fallback is the real design job.

You pick a web font for a campaign – something clean and geometric that makes a launch look like it cost real money – build the email, run it through your previews, and it looks flawless everywhere you check. So it ships. Then, buried in a reply or a forwarded screenshot, you find out that a solid chunk of the list opened the thing in Times New Roman. Not the fallback you chose on purpose. Times New Roman, specifically, which manages to make any email read like a parking fine. And the reason nobody flagged it before send is almost always the same dull one: everyone who reviewed it was on a Mac, or Gmail in a browser, or a phone – all the places where the web font loads without a fight. The version that actually broke never made it into the approval chain, because the clients that wreck web fonts in email aren’t the clients most teams bother to QA on.

Here’s the thesis, plainly, so you don’t have to go digging for it. The font you design in is not the font a big chunk of your list sees. The real skill with web fonts in email isn’t picking a pretty typeface – it’s engineering the fallback so carefully that nobody can tell which version they got. Everything else here hangs off that one idea.

I’ve been coding HTML email for years, and web fonts in email are one of the two or three things that catch people out the most. Partly because half the rules that work on the web are actively wrong in an inbox. So this is the long version – what “web font” even means here, the honest support picture, why Outlook reaches for Times New Roman like it’s 2004, how to build a fallback stack nobody notices, the ESP landmines, testing, and an honest read on the next five years. Code where it helps. War stories where they’re relevant. FAQ at the bottom for the skimmers, and I see you, that’s fine.

What “web fonts” and “fallback fonts” actually mean

Quick definitional bit, because the producers and shop owners reading this don’t always need it spelled out, and the developers can skim.

There’s a three-way distinction that trips people up in briefs constantly. A typeface is the design – Helvetica, Georgia, the artistic thing. A font family is a grouping of related styles. A font is one specific weight and size of that. People say “font” when they mean “typeface,” including me, including probably three times in this article. Not a hill I’ll die on.

The distinction that matters for email is different:

• A web-safe font is pre-installed on basically every device. Arial, Georgia, Verdana, Times New Roman, Tahoma. No loading, no server, it just renders. These are your font-family email workhorses.
• A web font (also called a custom font) gets fetched from somewhere – Google Fonts, Adobe Fonts, or your own server via @font-face. It only shows up in clients that bother to load external fonts.

Why email breaks the normal rules

Quick reminder, because you’ve heard it before and I won’t lecture. Email renders in something like 40 different clients. Classic Outlook runs on Microsoft Word’s rendering engine – the document program – and a 2007-era build of it. Gmail rewrites your CSS on a whim. Apple Mail is the well-behaved kid nobody’s whole audience actually lives in.

Here’s the reframe that changes everything. On the web, the fallback font is a 200-millisecond flash before the real font arrives. Nobody notices. In email, for a huge share of your opens, the fallback is the final render. It’s not a placeholder. It’s what the person reads. That single difference is the whole reason web fonts in email are a genuinely different problem from web fonts on a web page.

The honest support matrix – which clients render web fonts in email in 2026

Most guides open with “web fonts are widely supported now!” and then spend eight paragraphs explaining the ways they aren’t. Let me just hand you the real map first. Here’s where web fonts in email actually load in 2026.

The number that sounds worse than it is

Caniemail – the reference source, maintained by Rémi Parmentier’s crew – currently puts @font-face support at roughly 22% full plus about 2.4% partial across all the clients it tracks. That’s around a quarter. Sounds bleak.

But that number is weighted by client, not by your audience. And that distinction flips the whole thing.

Apple Mail alone accounts for somewhere in the range of 52 to 58 percent of email opens market-wide, depending on whose data you trust. So even though only a handful of clients support custom fonts, your web font might reach more than half your recipients.

Which is the nuance the raw percentage completely hides. Twenty-four percent of clients, more than fifty percent of humans. Both true. Your actual reach depends entirely on your list, which is why “is it worth it” has no blanket answer – it’s an analytics question, not a philosophy question.

A conflict I’m not going to paper over

Here’s a credibility thing. Sources genuinely disagree on the new WebKit-based Outlook for Mac. Some client-support references now list its web-font support as effectively full. At least one still lists it as limited-to-none. I’ve seen it render both ways in the wild depending on the build.

So I’m not going to hand you a confident single answer, because I don’t have one. Test your own send. Don’t trust a matrix as gospel – including the one I just gave you. That’s the honest position and I’d rather look slightly less authoritative than lie to you.

Gmail’s dirty little detail

“Gmail supports web fonts in email” is technically-true marketing-speak. What Gmail actually does is load fonts it already ships – Roboto, Google Sans – and fall back on everything else. Gmail mobile overrides to Roboto almost across the board. So if your brand font isn’t one Google already bundles, Gmail shows your fallback. Which brings us back to: the fallback is the job.

Why Outlook shows Times New Roman – and how to stop it

This is the meatiest technical section, and it’s your best defense against looking like an amateur. It’s also where web fonts in email do their most spectacular breaking, so we go deep.

State the bug plainly first. Classic Outlook doesn’t merely ignore your web font. When you import the font a certain way, it also ignores your entire fallback stack and jumps straight to Times New Roman. People write font-family: 'Brand', Arial, sans-serif and watch Outlook render TNR anyway, and they lose their minds, because Arial is right there in the stack.

The actual mechanism (nobody explains this properly)

Credit where it’s due – Rémi Parmentier (HTeuMeuLeu) is the one who actually cracked this. Here’s what happens under the hood.

Outlook parses your @font-face rule. It can’t load the remote font file. So it falls back to whatever mso-generic-font-family value applies – and when that value is undefined, it resolves to auto, which Outlook interprets as the roman family, which is a serif, which is Times New Roman. It’s not random. It’s a defined resolution path that happens to be idiotic. Understanding why it happens is what separates you from someone who just knows “Outlook does a weird thing.”

And critically: this stack-nuking behavior mostly triggers when you import the font via <link> or @import. The @font-face method on its own is better behaved. Which points straight at the fixes.

The fixes, as a decision – not a dump

1. Prefer @font-face over <link> / @import. The @font-face method doesn’t trigger the stack-nuking bug the way <link> does. Import that way and half your problem evaporates before you write another line.

2. Add mso-font-alt inside the @font-face block. This hands Outlook a sane alternative instead of letting it default to roman. It’s the single most underused property in email typography.

@font-face {
  font-family: 'Manrope';
  src: url('https://yourcdn.com/manrope.woff2') format('woff2');
  font-weight: 400;
  mso-font-alt: 'Arial';       /* Outlook tries this first instead of Times New Roman */
  mso-generic-font-family: swiss;   /* swiss = sans-serif in MSO-speak; use roman for a serif */
}

A quick note on that last line, because it trips people up: mso-generic-font-family doesn’t take the CSS keywords you’d expect. It takes Microsoft’s own font classifications – roman, swiss, modern, script, decorative, auto. swiss means sans-serif, roman means serif. When the value is left undefined it resolves to auto, which maps to roman, which is how you end up back at Times New Roman. So writing sans-serif there does nothing – you want swiss.

3. The MSO-conditional override. Wrap your <link> or @import so Outlook never sees it, using <!--[if !mso]><!-- --> … <!--<![endif]-->. Or drop an <!--[if mso]> style block that force-sets a safe stack with !important. Both work. The trade-off is the classic conditional-comment horror story – some ESPs mangle conditionals, so you test after the platform touches it, not before.

4. The @media screen trick. Declare your safe stack in embedded styles, then put the web-font font-family inside an @media screen block that Outlook can’t read. It’s more code and slightly more fragile, but it’s a real option when conditionals get stripped.

The belt-and-suspenders version

One compact block. This is the version I actually paste into templates.

<style>
  /* Web font, guarded so Outlook doesn't choke on it */
  @font-face {
    font-family: 'Manrope';
    src: url('https://yourcdn.com/manrope.woff2') format('woff2');
    font-weight: 400;
    mso-font-alt: 'Arial';
    mso-generic-font-family: swiss;   /* swiss = sans-serif */
  }

  /* Modern clients get the web font; everyone else the safe stack */
  .body-text {
    font-family: 'Manrope', Arial, Helvetica, sans-serif;
    line-height: 24px;
  }
</style>

<!--[if mso]>
<style>
  .body-text { font-family: Arial, sans-serif !important; }
</style>
<![endif]-->

One honest aside so you don’t over-engineer. The bug was partly patched in Outlook 2019 and up. But you still code for it, because 2016 and older are not going anywhere in corporate land, and I’ll come back to why in the forecast section. For now, assume the Word engine is opening your emails and build accordingly.

Building a fallback stack that nobody notices

This section carries the whole angle, so give it a minute. Everything worth knowing about web fonts in email eventually collapses down to this one skill. The goal isn’t a fallback that’s “readable.” A readable-but-visibly-worse fallback still means half your list gets a downgraded brand. The goal is indistinguishable. The Outlook half should get an email that looks like you meant it, not like the good version broke.

The three matching rules

Match the style class. Sans primary gets sans fallbacks. Serif gets serif. Obvious, and still botched constantly – I’ve reviewed stacks that put Georgia behind a geometric sans “just in case,” which is like patching drywall with a brick.

Match the x-height. This is the single biggest tell, and the one people skip. Fonts with different x-heights reflow your lines differently. A fallback that’s taller or shorter in the lowercase pushes copy below the fold, changes how cramped body text feels, and generally makes the layout drift. Proxima Nova, Arial, and Verdana all have noticeably different x-heights – swap one for another blind and the composition shifts. Pick a fallback whose x-height sits close to your web font.

Set line-height explicitly on every text block. Never inherit. Different fonts carry different default leading, so if you don’t lock line-height, spacing drifts between the web-font view and the fallback view. This is precisely where “it looked fine in Apple Mail” emails fall apart in Outlook. One property. Set it everywhere.

Know what each client picks when you leave the stack empty

If you don’t fill the stack, the client picks for you, and it picks badly:

• Gmail defaults to Arial
• Apple Mail defaults to Helvetica
• Outlook defaults to Times New Roman
• macOS system defaults to SF Pro

So an incomplete stack means four different clients render four different fonts. Fill it.

Starter stacks you can steal

Sans, ending in the generic keyword every time:

font-family: 'YourBrandSans', 'Helvetica Neue', Helvetica, Arial, sans-serif;

Serif, same principle:

font-family: 'YourBrandSerif', Georgia, 'Times New Roman', serif;

Always end in sans-serif or serif. That generic keyword is the floor under everything – it’s the difference between “the client picks a reasonable default” and “the client picks Times New Roman out of spite.”

The system font stack option

Worth its own moment. Instead of loading anything, you can lean on whatever font the operating system already uses for its own interface:

font-family: -apple-system, BlinkMacSystemFont, "Segoe UI", Roboto,
             Helvetica, Arial, sans-serif;

Each client renders its own native UI font – SF Pro on Apple, Segoe on Windows, Roboto on Android. It always looks intentional and native, there’s zero loading, and it sidesteps the entire Outlook drama because you never asked for a web font in the first place.

The trade-off is real, though: zero brand distinctiveness. You get “clean and native,” not “unmistakably us.” My honest take – the system stack is great for transactional and text-heavy sends where legibility beats personality, and weaker when your brand typeface genuinely carries the identity. Horses for courses.

How to actually add web fonts in email – the three import methods, ranked

Practical and opinionated. There are three ways in, and they are not equal.

1. @font-face (preferred). Fewest Outlook side effects, most control, and it’s the only method that lets you add mso-font-alt. Start here.
2. <link> (the Google Fonts embed). Easy, copy-paste, and it triggers the Outlook stack bug. Must be MSO-guarded. Fine if you guard it.
3. @import. Same problems as <link>, plus some clients strip it outright. My least favorite. I reach for it roughly never.

Formats

Use WOFF and WOFF2. Skip the legacy .eot / .ttf / .svg soup you’ll see in old web tutorials – email doesn’t need it, and WOFF2 is the smallest, best-supported option among the clients that load fonts at all. One line, moving on.

Self-hosting vs Google / Adobe

Two landmines here worth knowing about.

• CORS. Self-hosted font files need access-control-allow-origin set, or they silently fail to load cross-origin. No error, no warning, just fallback everywhere. And plenty of ESPs won’t host font files for licensing reasons, so “self-host it” isn’t always available to you anyway.
• Adobe Fonts licensing. Adobe Fonts needs the Typekit embed plus a license that actually permits email use – and a lot of them don’t. Check the license before you build. Nothing quite like finding out at legal review that your hero font was never cleared for email.

Keep this section tight in your head – it’s table-stakes. The value is in the ranking, not in exhaustive tutorials you can find anywhere.

The traps the generic guides skip

Short, punchy, and this is where you out-depth the ESP listicles. These are the failure modes with web fonts in email that never make it into the “top 10 fonts” posts.

The multilingual glyph trap

Leading with this one because it’s the real pain for anyone sending course content across languages. Here’s the failure. Your web font’s character set is missing the glyphs for a language you send in – Cyrillic, Greek, or the diacritics in Romanian, Polish, Turkish. The client renders those characters only in the fallback and keeps everything else in the web font. So you get a single line where half the letters are your beautiful custom font and the accented ones are Arial, mismatched, right there in the subject line’s neighbor.

Almost nobody writes about this, and it silently wrecks multilingual sends. If you’re running the same campaign across languages, check the font’s language coverage before you commit to it. Not after.

Faux-bold from weight inheritance

If you load only the 400 weight and then bold something, some clients synthesize a fake bold by algorithmically fattening the strokes. It looks cheap and slightly smeared. Load the weights you actually use – 400 and 700, usually – or accept that the fallback often handles bold more gracefully than your half-loaded web font does.

The image-as-text escape hatch

For a hero headline where the exact brand typeface genuinely matters, some big brands (Samsung and Nike get cited a lot) render that one line as an image with real alt text. Fair enough. It’s bulletproof for the typeface. But it costs you live text, accessibility needs the alt done properly, and it vanishes when images are off. Verdict: fine for one hero line, never for body copy. If someone’s shipping paragraphs as images, that’s a different conversation and a worse one.

Buttons

Some ESP editors won’t let you put web fonts on buttons because it breaks the Outlook VML button. If you’ve built bulletproof buttons before, this is the same corner of the map – the VML fallback wants a safe font, so plan your button type around the safe stack, not the web font.

Fonts in the ESPs that mangle them

Whatever you code, the ESP is a second rendering pass, and it will have opinions about your web fonts in email. Test after the platform has had its way with your HTML, not just in your local file. Some specific notes from actual projects.

GetCourse

Relevant to the course-creator crowd, and I flagged this in my fluid-hybrid piece too, so I’ll stay consistent. GetCourse has a history of stripping <link>-loaded fonts inconsistently. Don’t trust <link> imports there. Inline your fallback stack and assume the web font is a bonus that may or may not survive. On GetCourse specifically, I build like the fallback is the design, every time.

Mailchimp

The newer drag-and-drop builder re-inlines CSS aggressively, which can drop or duplicate font declarations in ways that break your careful stack. Hand-code in the “code your own” template type. The visual editor and hand-built font logic don’t get along.

Klaviyo, Braze, Salesforce, HubSpot

Quick hits:

• Klaviyo – mostly cooperative, but its native blocks inject their own font styling that can override yours. Go fully custom or fully native, don’t marble the two.
• Braze – leaves your HTML fairly alone; the Liquid layer just makes the source ugly to debug.
• Salesforce Marketing Cloud – respects custom fonts well, but Content Builder can wrap your blocks; use the HTML paste content type.
• HubSpot – this one matters here. HubSpot strips MSO conditional comments in certain older drag-and-drop template types. If it strips your conditional, your entire Outlook fallback fix dies with it. Use the coded email tool.

Testing web fonts in email across clients – and what the tools cost now

You cannot eyeball web fonts in email by looking at them in Chrome. Your browser loads every font perfectly and lies to you about Outlook. I’ll keep repeating it because people keep trying. The thing you specifically need to see is the fallback rendering in real Outlook, side by side with the web-font version – and no local preview shows you that.

Litmus, with the asterisk taped on

Litmus is still the most thorough for font QA across roughly 100 client and device combinations. For seeing your fallback render in actual Outlook, next to the Apple Mail version, it’s the best there is. That’s the genuine value.

Now the asterisk, and it’s a big one. Litmus was acquired by Validity in April 2025. In August 2025 they retired the old entry-level Basic plan with basically no notice and moved everyone onto the Core plan at $500 a month – that’s 2,000 previews, five seats, plus a pile of analytics and personalization features whether you asked for them or not. Annual lands north of $5,000. The old small-team tier that ran around $79 to $99 a month is just gone, with no monthly replacement.

Heads up if you’ve relied on Putsmail: Litmus’s free send-yourself-a-test tool has been retired. It was a handy way to fire a quick test to your own inboxes for years, and it’s gone. Don’t build a workflow around it.

For an in-house team running dozens of campaigns a month, the Core plan’s math still works. For a freelancer testing two emails a week, $500 a month to look at screenshots is a hard sell. I still pay for it because my client mix earns it back – but I’ve stopped recommending it as the automatic default, and I’d feel dishonest not saying so.

Mailgun Inspect (formerly Email on Acid)

This is where I point most people now. Email on Acid has been folding into Mailgun Inspect, the rendering coverage is comparable, and it has historically sat around half the Litmus price. If you don’t need Litmus’s analytics suite and you just want to see your email across clients, start here.

caniemail.com

Free, and the actual reference for @font-face support data. Learn to read the support table yourself rather than trusting some blog’s summary of it (this one included). It’s maintained properly and updated often.

A font-stack previewer, and the real-hardware test

Grab a free font-stack previewer that renders a stack across clients side by side, so you can eyeball the fallback before you send. And – my recurring drum – keep one real machine around. Mine’s a 2019 ThinkPad running actual Outlook 2019. It catches the x-height and line-height drift that virtual machines quietly smooth over. Pair it with a real phone. VMs are close, not identical.

My actual QA loop, two lines: build, preview in Litmus or Mailgun Inspect, then send-to-self across Gmail / Outlook / Apple Mail / Yahoo with one specific instruction to myself – check the fallback, not the web font – then look at it on the real ThinkPad and real phone, then send. The web font looking great is not the test. The fallback looking deliberate is the test.

Does any of this survive the new Outlook? A 2026 – 2030 read

Mandatory forward-look, because if you don’t think about this your templates age badly and you’re re-coding everything in two years. I’ll hedge where I’m guessing, and say so, because anyone claiming to know exactly how a Microsoft transition plays out is bluffing.

The facts as of mid-2026

• The new Outlook for Windows is Chromium-based – Microsoft Edge WebView2 under the hood – and crucially, it loads web fonts like a browser. So as classic Outlook’s share shrinks, the whole Outlook font problem slowly dissolves on its own.
• But the transition keeps slipping. The opt-out phase – where the new Outlook becomes the default but users can still revert – was originally slated for April 2026. In late February 2026 Microsoft pushed it to March 2027 for enterprise environments, giving organizations 12 months of lead time.
• The cutover phase, where you can no longer switch back to classic, has no firm public date and won’t begin before roughly March 2028, after that 12-month notice.
• Microsoft supports classic Outlook through at least 2029 for Microsoft 365 subscribers and perpetual-license holders (Office 2021, Office 2024, Office LTSC).
• Outlook 2016 and 2019 hit end of support entirely on October 14, 2025 – that’s the end of the line, no more security patches. (Mainstream support for those two ended years earlier, 2020 and 2023 respectively; October 2025 was the final extended-support cutoff.) Corporate IT keeps running them anyway, because corporate IT does not move because Microsoft published a blog post.

One caveat so you don’t over-trust the new client. It isn’t a clean browser. It runs a post-processing layer that rewrites some styles after load – the famous one being border-radius, where it flattens different corner values to a single radius on all four corners. There are also scattered reports of installed-font pickup quirks. “Chromium” does not mean “identical to Chrome.” Test it specifically.

The five-year read (this is guesswork, and I’m telling you it’s guesswork)

• 2026 – 2027: Full fallback discipline is mandatory for any B2B or mixed list. Nothing forces users off classic during the opt-out window.
• 2027 – 2028: Audience analysis starts beating the calendar. A 90%-mobile, Apple-and-Gmail consumer list? You can lean harder on the web font. Enterprise B2B? Not yet, not close.
• 2028 – 2030: The Outlook fallback shifts from “must have” to “legacy layer you maintain.” Web fonts in email become the safe default, with the stack demoted to backup.
• Beyond 2030: Assuming Microsoft doesn’t pivot again – they might – email typography starts to resemble web typography, with the fallback as the legacy layer.

The part that outlives Outlook

Here’s what the “is this dying” takes miss. Building web fonts in email around a deliberate fallback stack is correct engineering even after classic Outlook is finally in the ground. Gmail still overrides fonts to Roboto. ESPs still rewrite your <head>. Fonts still fail to load on bad connections. Forwards still land in clients you can’t predict. Designing for “the font didn’t load” doesn’t expire just because one Microsoft product got better.

Pragmatic recommendation:

• Keep a matched fallback as the base layer, always.
• Ship the web font as an enhancement on top.
• Audit your client mix quarterly.
• Once classic Outlook drops below about 5% of your opens, you can stop guarding for it in new templates.
• Don’t rip working font code out of templates that already work just because it feels old.

Frequently asked questions

Which email clients support web fonts?

Apple Mail, iOS Mail, Outlook for Mac, Outlook.com / OWA, and the new Chromium-based Outlook for Windows all load web fonts. Gmail only reliably loads its own fonts. Classic Outlook for Windows and most legacy clients ignore web fonts and render your fallback stack instead.

Why does Outlook change my font to Times New Roman?

Classic Outlook can’t load web fonts, and when you import via <link> or @import, it also drops your fallback stack and resolves to its default roman family – which is Times New Roman. Fix it with @font-face plus mso-font-alt, or an MSO conditional that force-sets a safe stack.

Does Gmail support web fonts?

Barely. Gmail webmail only reliably renders fonts it already ships, like Roboto and Google Sans. Gmail mobile overrides almost everything to Roboto. For any other custom typeface, Gmail shows your fallback – so a matched fallback matters as much for Gmail as it does for Outlook.

What’s the difference between a web-safe font and a web font?

A web-safe font (Arial, Georgia, Verdana) is pre-installed on virtually every device, so it always renders with no loading. A web font is fetched from a server – Google, Adobe, or self-hosted – and only appears in clients that support @font-face. Everything else falls back.

How do I set a fallback font in email?

List fonts in the font-family stack in priority order, ending in a generic keyword (sans-serif or serif). Match the fallback’s style class and x-height to your web font, and set line-height explicitly on every text block so spacing holds when the fallback kicks in.

Should I use a system font stack instead of a web font?

Often yes, for newsletters and transactional email. The system stack renders each client’s native font, always looks intentional, needs no loading, and dodges Outlook’s font drama entirely. Choose a web font only when the brand typeface genuinely carries identity and the extra fragility is worth it.

Do web fonts work in the new Outlook?

Yes. The new Chromium-based Outlook for Windows loads web fonts in email like a browser. But classic Word-engine Outlook is supported through at least 2029 for subscription and perpetual-license users, so you still need a fallback for the corporate audience for years yet.

Can a non-developer add a web font to an email?

Swapping a font inside a well-built template – yes, a careful marketer can manage that. Setting up the @font-face import, the Outlook fallback control, and a matched stack from scratch really needs someone comfortable with HTML and the Outlook quirks. It’s a good task to hand to a specialist.

What font format should email web fonts use?

WOFF and WOFF2. Skip the legacy .eot, .ttf, and .svg formats you’ll see in old web tutorials. WOFF2 is the best-supported and smallest option across the clients that load web fonts at all, and it’s all you need for email.

The short version

Pick a web font if you want one. But build the fallback like it’s the real design – matched x-height, matched weight, explicit line-height – because for half your list, it is. That’s the entire craft of web fonts in email compressed into one sentence, and everything above is just the working-out.

The two things that separate someone who read three blog posts from someone who’s shipped this: understanding why Outlook reaches for Times New Roman (the mso-generic-font-family resolution path, not magic), and actually checking the fallback in real Outlook instead of admiring the web font in Apple Mail. Get those right and your email looks deliberate in Apple Mail, in Gmail, in the new Outlook, and in the Word-engine relic somebody’s still running in a basement office in 2029.

If you want a quick read on whether the developer building your emails knows their stuff, ask them two things. What does mso-font-alt do? And do they test the fallback in real Outlook, or just admire the web font on their Mac? The answers tell you most of what you need to know.

I’ve got follow-ups coming – one specifically on dark mode and fonts, and the container-queries piece I’ve now promised twice and really will write. They’ll be on the blog when they’re done. Send me a brief if you need emails that hold up where it counts. I’ll show you the test results before you send, and I won’t disappear mid-project.