Building transactional email templates with React Email

React Email lets you write email templates as React components, using a constrained set of layout primitives (Body, Container, Heading, Text, and similar) that render down to email-client-safe HTML, rather than hand-writing table-based HTML yourself. The integration point with Envello is simple: render() the component to a string, send that string as the html field.

Structuring templates for real transactional use, not just the demo

The quickstart examples usually show one component per email. For a real product with several transactional email types (welcome, password reset, receipt, shipping notification), it's worth extracting shared pieces, a header/logo component, a footer with your address and support link, a base layout wrapping all of them, so each individual email template only contains what's actually unique to it.

Passing dynamic content in

Since these are just React components, dynamic content is plain props: render(<ReceiptEmail orderNumber={order.id} amount={order.total} items={order.lineItems} />). This is one real advantage over a string-templating approach, you get type checking on what a given template actually needs, and a missing required prop is a build-time error instead of a blank spot in a production email.

Generating a plain-text fallback

@react-email/render also exports a plainText option that strips your component down to a readable text version automatically, rather than requiring a hand-maintained duplicate template. Pass both the html and text fields to the API; some mail clients and accessibility tools still prefer the plain-text part, and a missing one is a minor but avoidable deliverability signal.

Previewing before you send

React Email's own dev server (npx react-email dev) renders your templates in a local preview with live reload, so you can check layout and content across different sample props without actually sending a test email for every iteration. Save the real send-and-check-the-inbox step for final verification of client rendering quirks, not for routine content and layout changes during development.

Testing across real email clients

React Email's primitives handle most of the table-layout and inline-CSS quirks that plague hand-written HTML email, but Outlook's rendering engine (Word-based, notoriously inconsistent) still deserves a real check before shipping a new template, not just Gmail and Apple Mail. A tool like Litmus or Email on Acid renders your output across real clients; for a small team, sending a test to a personal account on each major client you care about (Gmail, Outlook desktop, Apple Mail, a common webmail client) covers most of what actually matters.

Attachments and inline images

React Email components render to HTML only; images referenced in a template need to be hosted at a public URL (your CDN, your app's asset host) rather than embedded as base64 data URIs, which many mail clients strip or refuse to render inline. For attachments (a PDF invoice, for example), those are a separate field in the API request, not something you compose inside the React component itself.

Versioning templates alongside application code

Because templates are just components in your codebase, they're versioned, reviewed, and tested the same way as the rest of your application, no separate template-management system to keep in sync. A template change ships in the same pull request as the feature that needed it, and a rollback reverts both together, which isn't true of provider-hosted drag-and-drop template editors that live outside your normal deploy pipeline.