Email templates for HTML email testing and transactional workflows

Email templates are the fastest way to ship consistent transactional email, but they are also one of the easiest places to ship regressions. A small HTML change can break a password reset button, leak the wrong environment link, or fail in dark mode.

This guide focuses on the practical side: how to design templates your team can reuse, and how to test them like code before they reach customers.

Quick answer

Use an email template when the same message shape needs to be sent repeatedly with different values. Before release, test the generated message, not only the source template.

That means checking:

variables and fallback values
reset links, OTP codes, billing links, and account URLs
HTML and plain-text bodies
images, buttons, and unsubscribe controls
Gmail, Outlook, mobile, desktop, dark mode, and light mode rendering

If you came here from an html email template, html email builder, or html email generator search, the safest workflow is to build the template in your editor, send the final version into MailSlurp, then run device previews or Free email render before customers see it.

What counts as an "email template"?

An email template is a repeatable email body plus a set of variables you fill at send time. In a typical product, templates cover:

OTP or verification codes
Password resets and magic links
Receipts, invoices, and alerts
Team notifications and workflow status updates

If your template has any user-impacting link or code, treat it as part of your release surface.

Common failure modes (and how to prevent them)

Before you write more templates, decide how you will prevent these common issues:

Broken links: wrong hostname, missing UTM params, or a stale route after refactors
Missing variables: {firstName} shows up literally in production
Unsafe HTML: unescaped content breaks the layout or introduces injection risk
Rendering drift: looks fine in Gmail, breaks in Outlook, fails in dark mode
Spam signals: too many tracking domains, heavy images, or missing authentication

You can catch most of these with a lightweight template test workflow.

Template variables and substitution

MailSlurp templates support variable replacement so one template can serve many user events.

If you're building "merge variables" or handlebars-style placeholders, use the dedicated guide:

Template variables and replacement

Testing templates with MailSlurp (recommended workflow)

The goal is to make template validation deterministic:

Generate an inbox for a test run.
Send the template using a known set of variables.
Assert the HTML contains the right link targets and copy.
Extract codes or links and verify they behave.
Gate the release if the checks fail.

Send a templated email

Create a template once:

await mailslurp.templateController.createTemplate({
  createTemplateOptions: {
    name: "Welcome",
    content: "Welcome to our app",
  },
});

Send with runtime variables:

const templateObject = await mailslurp.templateController.getTemplate({
  templateId,
});
expect(templateObject.content).toContain("Hello {{firstName}}. Welcome to {{brandName}}.");
const sent = await mailslurp.sendEmail(inboxId, {
  to: [emailAddress],
  subject: "Welcome {{firstName}}",
  template: templateId,
  templateVariables: {
    firstName: "Sally",
    brandName: "My Company",
  } as any,
});

Assert the right link or OTP shows up

For example, validate that the template produced a working reset URL (and not a staging link).

const [welcomeEmail] = await mailslurp.waitForMatchingEmails(
  {
    conditions: [
      {
        condition: ConditionOptionConditionEnum.HAS_ATTACHMENTS,
        value: ConditionOptionValueEnum.FALSE,
      },
    ],
    matches: [
      {
        field: MatchOptionFieldEnum.SUBJECT,
        should: MatchOptionShouldEnum.CONTAIN,
        value: "Welcome!",
      },
    ],
  },
  expectedCount,
  inboxId,
);

If your template carries OTP codes, see:

HTML email checklist for release readiness

Use this as a pre-merge checklist for template changes:

Subject is descriptive and testable (not "Hello")
Text alternative exists or the copy is readable without images
Links use the correct environment base URL
Buttons are accessible and work without images
Variable placeholders have defaults or validation
Branding assets are on stable URLs (no expiring signed URLs)
Tracking pixels are intentional (and don't break deliverability)

For client-specific template work, use Outlook email templates when humans reuse templates from Outlook, and HTML email spacing when layout drift is the main risk.

For visual approval, use HTML email preview to check the template output across real clients and devices. For Gmail-specific sends, use Send HTML email in Gmail so the template is tested after Gmail has handled the final message.

Email templates for testing and transactional workflows