Email

Status: authoring pipeline locked. Full template catalog is deferred. Emails are authored in Markdown via emailmd.dev, which compiles to client-safe HTML with the table-based layouts, inline styles, and client-specific quirks handled at build time.

Authoring - Markdown via emailmd.dev

Email templates are not authored in raw HTML. The source format is Markdown, compiled to email-safe HTML by emailmd.dev. The compiler handles the defensive layer email clients demand - bulletproof buttons, inline-style hoisting, dark-mode inversion rules, Outlook-Word rendering - so the author never touches it.

Why this approach:

• Consistent with the rest of the design system - the brief itself is Markdown, product docs are Markdown, READMEs are Markdown. Email doesn’t get its own authoring register.
• Reviewable in PR diffs - unlike raw email HTML (where a one-word copy change produces a thousand lines of table re-layout noise), Markdown diffs show the content change.
• Forces restraint - Markdown doesn’t have decorative options. If a design requires something Markdown can’t express, the design is probably wrong for email.
• Content reuse - the same Markdown source can seed an email, a Slack digest, a blog post, and an in-product banner, with minimal transformation.

The FDT design system ships a set of emailmd.dev-compatible base templates (header with wordmark, footer with legal markings, CTA patterns, classification strips where required). Product teams extend these templates; they do not author from scratch.

Fonts - design for the fallback stack

Email clients handle custom-font loading inconsistently. Apple Mail (macOS, iOS) loads web fonts; Gmail web and Outlook 365 silently fall back to system fonts. The system’s stance: design assumes the fallback stack is what the recipient sees, not Inter.

• Body / UI: -apple-system, BlinkMacSystemFont, 'Segoe UI', system-ui, sans-serif
• Headings: same stack - Barlow Condensed is not loaded in email; if a condensed feel is needed, use 'Arial Narrow' in the stack as a best-effort fallback, and accept the result
• Data / mono: 'SF Mono', Menlo, Consolas, monospace

If Inter loads (Apple Mail), the result is marginally better. If not, the design still works at full readability on every client in the test matrix.

Dark-mode stance

Emails are designed dark-first (navy-900 background, fog-100 text) with the assumption that clients forcing light mode will invert. Production test matrix covers Apple Mail (macOS, iOS), Gmail (web, Android, iOS), Outlook 365 web, and Outlook desktop (Word-rendered). Inversion behavior is verified, not assumed.

Template scope

Three template categories ship as part of the design system’s email layer:

1. Transactional - system-sent messages to a specific user in response to an action. Auth codes, confirmations, access requests, operational alerts. Terse copy, high-priority delivery, no marketing content.
2. Program updates - briefings to a defined distribution list. Product updates, operational debriefs, milestone announcements. Longer form, structured sections, classification markings where required.
3. Marketing - newsletters, event invitations, external announcements. Lower priority, slightly more visual weight permitted within system constraints. External comms only - internal FDT audiences don’t get marketing-register emails.

Deferred to next pass

• ESP selection (Postmark, Resend, SendGrid) - each integrates with emailmd.dev output differently
• Classification markings on internal FDT emails - visual treatment, which emails carry them
• Signature block format for FDT employees
• Plain-text alternate rendering rules
• Unsubscribe / preference center treatment (marketing only)
• Per-product template inventory (what specific transactional emails GRIDWATCH vs QRF vs OVERWATCH send)