Transactional email: what it is, the types, and how it's sent

A transactional emailis automatically triggered by an individual user’s action or an account event, and it carries information that user is expecting. Because the recipient asked for it (implicitly or explicitly), it doesn’t need marketing consent and is held to a higher delivery standard — a receipt that lands in spam is a support ticket.

The difference isn’t the content, it’s the trigger and the audience:

• Transactional— triggered by one user’s action, sent to one person, expected, account-specific. Examples: password reset, order receipt.
• Marketing — sent on your schedule to a list, promotional, requires consent and an easy unsubscribe. Examples: a newsletter, a sale announcement.

They typically run on separate infrastructure: you want transactional mail to be fast and reliable, and you never want a marketing problem to delay a password reset.

• Authentication — email verification, OTP codes, magic-link sign-in.
• Account — password resets, security and new-device alerts, profile changes.
• Commerce — order confirmations, payment receipts, invoices, shipping and delivery updates.
• Lifecycle — welcome emails, trial and usage notifications, and other event-driven messages.

You can send over SMTP — the classic mail protocol — or through an HTTP API, which is how most modern apps do it. An API send is a single authenticated request naming the template and variables, which is simpler to integrate, easier to get delivery and bounce feedback from, and doesn’t tie up a connection:

import { SenderKit } from "@senderkit/sdk";

const senderkit = new SenderKit({ apiKey: process.env.SENDERKIT_API_KEY! });

await senderkit.send({
  template: "password_reset",
  to: user.email,
  vars: { first_name: user.firstName, reset_url: resetUrl },
});

See the email API for the full sending model, or the language-agnostic walkthrough on the transactional email use case.

Sending is easy; landing in the inbox is the work. At minimum, authenticate your domain with SPF, DKIM, and DMARC, send from a domain you control, and keep bounces and complaints low. If transactional mail is going to spam, the why-emails-go-to-spam checklist walks through every common cause.

• Keep templates out of your codebaseso copy changes don’t need a deploy.
• Send fast. A verification code that arrives in 30 seconds is a failed signup.
• Make it plain and scannable — the action or information should be obvious in one glance.
• Monitor delivery with webhooks for bounces and failures, and have a fallback channel (SMS, push) for critical messages.

Look for fast, reliable delivery, real template management, clear webhooks, and no lock-in so you can switch providers without rewriting code. If you also send SMS or push, one API across channels saves stitching products together. Compare the common options — SendGrid, Mailgun, Twilio — or see how SenderKit approaches it on the email API page.