*Last updated: June 2026*

Before you send a single message, it helps to know exactly what category of email you're dealing with. Transactional email has its own rules, its own infrastructure expectations, and its own failure modes. This chapter defines it, separates it from marketing email, and explains why something that looks simple on the surface gets complicated fast.

## What is transactional email?

A transactional email is a message sent to one person in response to an action they took or an event tied to their account. It carries information the recipient is expecting and usually needs: a password reset link, a receipt, a shipping update, a login code.

The defining trait is the trigger. A transactional email is triggered by a specific event for a specific user, not sent on a schedule to a list. When someone resets their password, they get exactly one email, right away, addressed to them. That one-to-one, event-driven nature is what separates transactional email from every other kind.

Because recipients expect these messages and often need them to keep using your product, transactional email carries different legal and deliverability treatment than promotional mail. It's tied to a service the user signed up for, so it generally doesn't require the same consent and unsubscribe handling that marketing email does. That distinction matters, and it's the subject of the next section.

One reason to get transactional email right: people actually read it. Because these messages are expected and personal, they consistently outperform marketing email on engagement, with open rates commonly several times higher than bulk campaigns. That attention runs both ways. The same users who reliably open a receipt or a reset email are the first to notice, and the first to file a support ticket, when one fails to arrive.

## Transactional vs. marketing email: what's the difference?

Transactional email is triggered by an individual user's action and delivers information they're expecting. Marketing email is sent to a list of recipients to promote something, on your schedule rather than theirs.

The difference is more than intent. It changes how you send, what consent you need, and how the message is regulated.

| Dimension | Transactional email | Marketing email |
|---|---|---|
| Trigger | A user action or account event | A campaign you schedule |
| Audience | One recipient at a time | A list or segment |
| Consent | Implied by the user relationship | Explicit opt-in required |
| Unsubscribe | Not typically required | Required by law (CAN-SPAM, GDPR) |
| Timing expectation | Immediate (seconds) | Whenever the campaign runs |
| Examples | Password reset, receipt, alert | Newsletter, product promo, sale |

Two practical consequences follow from this. First, you'll usually want to send the two types through separate infrastructure or separate sending domains, because mixing promotional content into your transactional stream can drag down the deliverability of email people actually need. Second, the line can blur: a receipt with a "you might also like" block starts to look promotional, and some jurisdictions will treat it that way. When a message mixes both, the safe move is to treat it as marketing for consent and unsubscribe purposes.

**How the law draws the line: the "primary purpose" test.** In the US, the [CAN-SPAM Act](https://www.ftc.gov/business-guidance/resources/can-spam-act-compliance-guide-business) classifies a message by its *primary purpose*. It recognizes three kinds of content: commercial (advertises or promotes a product or service), transactional or relationship (facilitates or updates an already agreed-upon transaction), and other. If the primary purpose is transactional, the message is largely exempt from the consent and unsubscribe rules that govern commercial email. The moment promotional content becomes the primary purpose, the message is treated as commercial, no matter which pipeline or template sent it. So classify by primary purpose, not by the system you happened to use.

## The most common types of transactional email

Most transactional email falls into a handful of recognizable categories. Knowing them helps you plan templates, prioritize reliability, and decide which messages are time-critical.

- **Account lifecycle**: email verification, welcome messages, password resets, and email-change confirmations. These gate access, so latency and deliverability are critical.
- **Security**: login codes, two-factor authentication codes, new-device alerts, and suspicious-activity notices. Often the most time-sensitive email you send.
- **Commerce**: order confirmations, payment receipts, invoices, refund notices, and shipping updates. Users save and reference these, so accuracy matters.
- **Activity and collaboration**: comment notifications, mentions, assignment alerts, and share invitations. High volume, and a common source of notification fatigue.
- **Operational**: usage alerts, quota warnings, failed-payment notices, and scheduled-maintenance messages. These protect the user's account and your relationship with them.

You see these every day without thinking about them: a Vercel sign-in alert, a Stripe receipt, a DoorDash order confirmation, a GitHub security notice, an Asana mention digest. A password reset that arrives two minutes late is a support ticket. A receipt with the wrong total is a trust problem. Sorting your email into these buckets early tells you where to invest in speed and where to invest in correctness.

## Why transactional email is harder than it looks

"It's only email" is the assumption that gets teams into trouble. Sending one email from your laptop is easy. Sending millions that arrive in seconds, land in the inbox, and never go out twice is a real engineering problem.

A few things make it hard. Deliverability is not under your full control: mailbox providers like Gmail and Outlook decide whether your message reaches the inbox based on your domain reputation, authentication, and recipient engagement. Timing expectations are tight, because a login code that takes 90 seconds is useless. Reliability is unforgiving, since a dropped password reset locks someone out and a duplicated charge receipt erodes trust. And the rules keep moving: authentication requirements and bulk-sender policies tightened across the industry in recent years, and they'll keep changing.

None of this is insurmountable. But it's why transactional email has grown into its own discipline, with dedicated providers, authentication standards, and operational practices. The rest of this guide walks through each piece.

## Frequently asked questions

### Is transactional email regulated like marketing email?

Mostly no. Under the US CAN-SPAM Act, a message whose primary purpose is transactional or relationship content is exempt from the consent and unsubscribe requirements that apply to commercial email. If the primary purpose becomes promotional, the message is treated as marketing no matter how it's sent.

### Do users have to opt in to transactional email?

No. Because transactional email is triggered by the user's own action and delivers something they need, like a receipt or a password reset, it generally doesn't require the explicit opt-in that marketing email does. Keep promotional content out of it to preserve that status.

### Is transactional email the same as SMTP?

No. SMTP is the protocol that moves email between servers. Transactional email is a category defined by how a message is triggered and who receives it. You can send transactional email over SMTP or through an HTTP API that handles the SMTP layer for you.

Transactional email is automated, one-to-one mail triggered by user actions. Learn how it differs from marketing email, common types, and why it's hard.

What Is Transactional Email?

Transactional email has its own rules, infrastructure expectations, and failure modes. Learn what it is, how it differs from marketing email, the common types you'll send, and why something that looks simple gets complicated fast.

What Transactional Email Is

*Last updated: June 2026*

This chapter is the practical core: how a message actually travels from your application to someone's inbox, how to pick the service that carries it, and how to send your first one. By the end you'll have working code, a framework for choosing a provider, and a plan for templates, personalization, and localization.

## How transactional email gets delivered: SMTP, APIs, and providers

When your app sends a transactional email, it hands the message to a mail server, which relays it across the internet to the recipient's mailbox provider, which decides whether to place it in the inbox. You can talk to that mail server in one of two ways: the SMTP protocol or an HTTP API.

**SMTP** (Simple Mail Transfer Protocol) is the standard language of email. Your code opens a connection to a mail server, authenticates, and streams the message. SMTP works everywhere and is well understood, but it's chatty, slower to send at volume, and gives you limited feedback beyond "accepted" or "rejected."

**HTTP APIs** are what most modern providers offer on top of SMTP. You make a single HTTPS request with a JSON body, and the provider handles the SMTP relay for you. APIs are faster, easier to debug, and return rich responses (message IDs, validation errors, structured status), which is why most new integrations use them.

Behind either interface sits the hard part: actually getting delivered. The recipient's mailbox provider evaluates your domain's reputation, your authentication records, and how recipients have engaged with your past email, then routes the message to the inbox, the spam folder, or nowhere at all. This is why a dedicated email service provider matters. Running the mail server is the easy part. Maintaining the sending reputation and relationships with mailbox providers that get you to the inbox is the work.

## How transactional email gets triggered

Every transactional email starts with an event: a password reset, a cleared payment, a shipped order. The path that event takes to your email system decides two things that matter, how fast the message goes out and how reliably it arrives. Pick the path based on how much each one matters for that message.

- **Direct send.** Your app calls the email API in the same request that handled the action. Fewest moving parts, lowest latency, and the right default for anything a user is actively waiting on: reset links, login codes, receipts.
- **Queued send.** Your app drops the send onto a queue and a worker picks it up. You trade a little latency for resilience, since spikes get absorbed and failed sends get retried (chapter 4). A good fit once volume grows or a send can wait a beat.
- **Event-driven send.** A CDP or event stream like Segment, RudderStack, or Kafka routes product events to your email layer along with everything else. This is how behavior- and lifecycle-based messaging usually gets built, where the trigger is "did X three times this week," not a single request.

The thing to get right is what sits on the critical path. CDPs and event streams are usually quick, but their latency isn't guaranteed and they add a hop between the user and their message, so they're a poor place for something like a login code, where an unpredictable tail and an extra dependency are exactly what you don't want. Keep the messages a user is waiting on close to your app, and let lifecycle messaging flow through the event pipeline where a little variability is fine.

## How to choose an email service provider

An email service provider (ESP) is a service that sends your email for you and works to keep it landing in the inbox. The right one depends on five things that actually move the needle, not on feature-list length.

- **Deliverability and reputation management**: the core job. Look for established sending infrastructure, dedicated IP options, and a track record with major mailbox providers. This is the single most important criterion.
- **API quality and SDKs**: a clean REST API, official SDKs for your language, sandbox or test modes, and clear errors. You'll live in this API, so its ergonomics matter daily.
- **Analytics and visibility**: delivery, bounce, and engagement data, plus webhooks for delivery events. You can't fix what you can't see.
- **Pricing model**: per-email, monthly volume tiers, or pay-as-you-go. Match it to your actual sending pattern, and check how overages and add-ons (dedicated IPs, validation) are priced.
- **Support and reliability**: published uptime, status history, and support that responds when your password resets stop sending.

A few rules of thumb by volume. Under roughly 50K emails a month, most providers' free tiers are plenty and the decision comes down to developer experience. Between 100K and 1M a month, unit economics start to matter, so compare per-message cost carefully. Above that, dedicated IPs and direct deliverability support become worth paying for. And if you have EU data-residency requirements, confirm the provider offers EU infrastructure specifically, because not all of them do.

A useful mental filter: deliverability and visibility are the things you can't easily build yourself, so weight them heavily. Templating and nice dashboards are conveniences you can work around.

## Transactional email providers compared

There's no single best provider, only the best fit for your volume, stack, and budget. Here's how the most common transactional email services compare on the criteria that matter.

| Provider | Interface | Templating | Entry pricing (approx.) | Best for |
|---|---|---|---|---|
| Resend | API and SMTP | React Email components | Free 3K/mo; ~$20/mo for 50K | Modern stacks and developer experience |
| SendGrid | API and SMTP | Dynamic templates | Free trial; from ~$20/mo for 50K | Full-featured general-purpose sending |
| Amazon SES | API and SMTP | Minimal (bring your own) | ~$0.10 per 1,000 emails | High volume, AWS-native teams |
| Postmark | API and SMTP | Template editor | Free 100/mo; from ~$15/mo for 10K | Speed-critical transactional email |
| Mailgun | API and SMTP | Handlebars templates | Free trial; ~$35/mo for 10K | Technical teams wanting granular control |
| Mailjet | API and SMTP | Visual builder | Free 200/day; from ~$17/mo for 15K | Mixed technical and non-technical teams |
| MailerSend | API and SMTP | Visual builder | Free 3K/mo; from ~$25/mo for 50K | Modern SaaS wanting approachable tooling |
| Mailchimp Transactional | API and SMTP | Templates | Block pricing; ~$80 for 100K | Existing Mailchimp customers |

Pricing and tiers change constantly, so treat these figures as rough orientation and confirm current rates with each provider before you commit.

A few patterns stand out. Amazon SES is the cheapest at volume but the most barebones: you bring your own templating, suppression handling, and analytics tooling. Postmark optimizes hard for transactional speed and keeps marketing email on a separate stream by design. Resend is the newest and leans into developer experience and React-based templates. SendGrid is the full-featured general-purpose default, and Mailgun gives technical teams granular control with both US and EU regions. For EU data residency specifically, Mailgun and Mailjet offer dedicated EU infrastructure. If cost at scale dominates, SES wins; if developer experience and time-to-first-send dominate, Resend or Postmark tend to win; if you want one well-trodden option, SendGrid is the safe default.

## How to send your first transactional email

The fastest path to a sent email is a provider's HTTP API and an SDK. Here's a complete, runnable example using Node.js and SendGrid to send an order confirmation.

First, install the SDK and set your API key as an environment variable:

```bash
npm install @sendgrid/mail
export SENDGRID_API_KEY="your_api_key_here"
```

Then send the email:

```javascript
const sgMail = require("@sendgrid/mail");

sgMail.setApiKey(process.env.SENDGRID_API_KEY);

async function sendOrderConfirmation(order) {
 const message = {
 to: order.customerEmail,
 from: "orders@yourstore.com", // must be a verified sender
 subject: `Order ${order.id} confirmed`,
 text: `Thanks for your order. We're preparing it now. Total: $${order.total}.`,
 html: `Thanks for your order. We're preparing it now.
 Order ${order.id} &middot; Total: $${order.total}`,
 };

 try {
 await sgMail.send(message);
 console.log(`Confirmation sent for order ${order.id}`);
 } catch (error) {
 console.error("Send failed:", error.response?.body || error.message);
 throw error;
 }
}
```

Three details make this production-shaped rather than a toy. The `from` address has to be a verified sender on a domain you control, or mailbox providers will reject it. You always send both a `text` and an `html` version, because some clients and filters prefer plain text. And you handle the error path, because sends fail and your caller needs to know so it can retry. We'll come back to retries and idempotency in chapter 4.

## How to build and manage email templates

A template is a reusable email design with placeholders for the data that changes per send. Hardcoding HTML strings in your application code works for one email and becomes unmaintainable by the tenth, so you'll want to move to templates early.

You have three broad options. **Code-based templates** keep the markup in your repository using a templating language like Handlebars or a library like React Email; they version with your code and suit engineering-owned email. **Provider-hosted templates** live in your ESP's dashboard, so non-engineers can edit copy without a deploy, at the cost of splitting your email across two systems. **Dedicated template or notification platforms** centralize templates across providers and channels, which helps once you outgrow a single ESP.

Whatever you pick, a few practices hold. Separate content from logic so copy changes don't require code changes. Build HTML email defensively, because email clients render with inconsistent, dated engines: use tables for layout, inline your CSS, and test across clients with a tool like Litmus or Email on Acid. Always include a plain-text version. And keep templates under version control or a clear change history, so a broken receipt template is traceable to the change that broke it.

## How to use partials and shared components

As your template library grows, you'll notice the same header, footer, button styles, and legal text repeated across every email. Copying that markup into each template means a footer change becomes a find-and-replace across dozens of files, and the one you miss ships broken. Partials solve this: a partial is a reusable fragment, like a header, a footer, or a button, that you define once and include in many templates.

It's the same idea as components in application code. Keep each shared element in one place, reference it everywhere, and a single edit propagates to every template that uses it. Most templating systems support this directly (Handlebars partials, React Email components), and notification platforms usually have an equivalent shared-block concept. Partials are what keep a library of ten or fifty templates maintainable instead of turning every brand tweak into a migration.

## How to handle dynamic content and personalization

Personalization is the practice of inserting per-recipient data into a template at send time: a name, an order total, a list of items, a confirmation link. Done well, it's what makes a transactional email useful rather than generic.

Most personalization is straightforward variable substitution, where you pass a data object and the template renders the values:

```javascript
const sgMail = require("@sendgrid/mail");
sgMail.setApiKey(process.env.SENDGRID_API_KEY);

async function sendShippingUpdate(user, shipment) {
 await sgMail.send({
 to: user.email,
 from: "shipping@yourstore.com",
 templateId: "d-1234567890abcdef", // a dynamic template stored in SendGrid
 dynamicTemplateData: {
 firstName: user.firstName,
 trackingNumber: shipment.trackingNumber,
 estimatedDelivery: shipment.eta,
 items: shipment.items, // an array the template can loop over
 },
 });
}
```

Two rules keep personalization from backfiring. Escape and validate any user-provided data you render, because an unescaped value is an injection risk and a rendering bug waiting to happen. And always define fallbacks for missing fields, so a null `firstName` renders "Hi there" instead of "Hi ,". Conditionals (show a block only when data exists) and loops (render a row per order item) cover the rest of what most transactional email needs.

## How to handle internationalization and localization

Internationalization (often shortened to i18n) is designing your email system so it can send the right language and regional formatting to each recipient. Localization is the act of producing those translated, region-aware versions. If you have users outside one country, you'll need both sooner than you think.

There's more to it than translating strings. A localized transactional email has to get several things right:

- **Language**: the subject, body, and call-to-action text in the recipient's language, including pluralization rules that differ by language.
- **Locale formatting**: dates, times, numbers, and currency formatted to the recipient's region (`$1,000.00` versus `1.000,00 €`).
- **Direction and encoding**: right-to-left layout for languages like Arabic and Hebrew, and proper UTF-8 encoding throughout.
- **Locale resolution**: choosing the correct locale at send time from the user's stored preference, with a sensible default when it's missing.

The naive approach, maintaining a separate template per language, multiplies your template count and gets unmanageable fast: ten emails in eight locales is eighty templates to keep in sync. The better pattern is one template with localized content resolved at send time, so a change to the layout applies everywhere at once. This is one area where notification infrastructure helps: Courier, for example, stores per-locale translations within a single template and resolves the recipient's locale at send time, so you maintain one template instead of one per language.

Whichever approach you choose, store each user's locale as a first-class field on their profile and pass it with every send. The piece that's easiest to get wrong is resolution: what to do when the stored locale is missing or isn't one you support. Always fall back deliberately rather than letting a template render half-translated.

```javascript
function resolveLocale(user, supportedLocales, defaultLocale = "en-US") {
 const preferred = user.locale; // e.g. "fr-CA", or undefined

 // 1. Exact match on the stored preference
 if (preferred && supportedLocales.includes(preferred)) {
 return preferred;
 }

 // 2. Fall back to the language without the region ("fr-CA" -> "fr-FR")
 const language = preferred?.split("-")[0];
 const languageMatch = supportedLocales.find((locale) => locale.startsWith(`${language}-`));
 if (language && languageMatch) {
 return languageMatch;
 }

 // 3. Fall back to a safe default rather than rendering untranslated
 return defaultLocale;
}
```

That three-step fallback (exact locale, then language, then a safe default) keeps a user with an unusual or missing locale from receiving a broken email, which is the failure mode that turns internationalization from a feature into a bug report.

## How to test and preview before you send

Email is unusually unforgiving to ship blind: once it's sent you can't edit it, and it renders across dozens of clients with inconsistent, dated engines. Build a testing step into your workflow before anything reaches a real user.

A few practices cover most of the risk:

- **Send seed tests.** Send the real template, with realistic data, to your own addresses across Gmail, Outlook, and Apple Mail before you ship a change.
- **Preview across clients.** Tools like Litmus and Email on Acid render your email in dozens of clients at once, catching the Outlook table quirk or the dark-mode inversion you'd never see locally.
- **Check your spam score.** A tool like mail-tester.com scores a real send against common filters and flags authentication or content problems before your users hit them.
- **Test the data, not only the layout.** Render with missing fields, very long names, zero-item orders, and right-to-left text, because the broken email your users actually get is usually a data edge case, not a design flaw.

Treat a template change like a code change: review it, test it, and keep a way to trace a broken receipt back to the edit that broke it.

## Frequently asked questions

### Should I use SMTP or an HTTP API to send transactional email?

Use an HTTP API when you can. APIs are faster, return richer responses like message IDs and structured errors, and are easier to debug than SMTP. SMTP is the universal fallback that works when a system can only speak SMTP, but for new integrations an API is the better default.

### Which transactional email provider is best?

There's no single best provider; it depends on volume, stack, and budget. Amazon SES is cheapest at scale, Postmark optimizes for transactional speed and deliverability, Resend leads on developer experience, and SendGrid is a full-featured general-purpose default. Match the provider to your sending pattern rather than its feature-list length.

### How many email templates do I need?

Fewer than you'd expect if you use partials and localization. Define shared elements like the header, footer, and buttons once as partials, keep one template per message type, and resolve language at send time instead of duplicating templates per locale. That keeps even a large library maintainable.

How transactional email gets delivered, how to choose and compare email providers, and how to send your first one, with templates, personalization, and i18n.

How to Send Transactional Email

The practical core: how a message travels from your application to the inbox, how to choose and compare email service providers, and how to send your first one. Includes runnable code for sending, personalization, templates, and localization.

*Last updated: June 2026*

Getting an email accepted by a mail server is easy. Getting it into the inbox is the actual challenge, and it's where most transactional email problems live. This chapter covers the authentication that proves you are who you say you are, the factors that shape your deliverability, and how to handle the bounces and complaints that protect your reputation over time.

## How to set up SPF, DKIM, and DMARC

SPF, DKIM, and DMARC are three DNS records that prove your email is legitimate and not spoofed. Mailbox providers now treat them as table stakes: [Gmail and Yahoo require authentication for bulk senders](https://support.google.com/a/answer/81126), and unauthenticated mail is likely to land in spam or be rejected outright. Set up all three before you worry about anything else.

**SPF (Sender Policy Framework)** is a DNS TXT record listing the servers allowed to send email for your domain. When a message arrives, the receiving server checks the sending source against that list.

```text
v=spf1 include:sendgrid.net include:amazonses.com -all
```

One catch: SPF allows a maximum of 10 DNS lookups, and each `include` counts against it. Chain too many providers and SPF silently breaks. Keep includes minimal, and once you're confident every legitimate sender is listed, prefer `-all` (hard fail) over `~all` (soft fail):

```text
// Too many includes: risks blowing the 10-lookup limit
v=spf1 include:a.com include:b.com include:c.com include:d.com ~all

// Better: only the providers you actually send through, hard fail
v=spf1 include:sendgrid.net include:amazonses.com -all
```

**DKIM (DomainKeys Identified Mail)** adds a cryptographic signature to every message. You publish a public key in DNS (usually a CNAME or TXT record your provider generates) and the provider signs each message with the private key, so receivers can verify the message wasn't altered in transit. Confirm a record exists with a quick lookup:

```bash
dig +short TXT selector._domainkey.yourdomain.com
```

**DMARC (Domain-based Message Authentication, Reporting, and Conformance)** tells receivers what to do when a message fails SPF or DKIM, and where to send reports. It lives at `_dmarc.yourdomain.com`:

```text
v=DMARC1; p=none; pct=100; rua=mailto:dmarc@yourdomain.com
```

Roll it out progressively. Start at `p=none` to monitor without affecting delivery, read the aggregate reports to confirm your legitimate mail passes, then tighten to `p=quarantine` and finally `p=reject`. DMARC also requires alignment: the visible `From` domain has to match your authenticated SPF or DKIM domain, exactly for strict alignment or by subdomain for relaxed.

**BIMI (Brand Indicators for Message Identification)** displays your logo next to authenticated messages in supporting inboxes like Gmail and Apple Mail. It's a premium step, not a starting point: it requires DMARC at `p=quarantine` or `p=reject`, a square SVG logo served over HTTPS, and usually a Verified Mark Certificate (VMC), which runs about $1,000 to $1,500 a year. For most senders, solid SPF, DKIM, and DMARC are enough; add BIMI once you're sending at real volume and want the brand lift.

**A pre-send authentication checklist:**

1. Add your provider's `include` to your SPF record, watching the 10-lookup limit.
2. Configure DKIM keys with your provider and publish them in DNS.
3. Publish a DMARC record at `p=none` and start collecting reports.
4. Send a test message to a tool like mail-tester.com for a full deliverability score.
5. Watch DMARC reports for unauthorized senders, then raise enforcement to quarantine and reject.

## What affects email deliverability

Deliverability is the likelihood that your email reaches the inbox rather than the spam folder or the void. It's driven by your sending reputation, which mailbox providers calculate from a mix of signals.

The big ones:

- **Sender reputation**: a score mailbox providers assign to your domain and sending IP, based on your history. This is the foundation everything else feeds into.
- **Authentication**: SPF, DKIM, and DMARC, covered above. Failing these is an instant deliverability hit.
- **Engagement**: opens, clicks, replies, and (negatively) deletions and spam complaints. Mailbox providers watch how recipients treat your mail and adjust accordingly.
- **List hygiene**: sending to invalid or inactive addresses generates bounces and spam-trap hits that damage reputation quickly.
- **Content**: spam-trigger phrasing, a bad text-to-image ratio, link-heavy bodies, and broken HTML can all push a message toward spam.
- **Infrastructure**: whether you send from a shared IP (reputation pooled with other senders) or a dedicated IP (your reputation alone, but you must warm it up by ramping volume gradually).

Mailbox providers publish concrete limits. [Gmail asks bulk senders](https://support.google.com/a/answer/81126) to keep the spam-complaint rate below 0.3%, and ideally under 0.1%. Cross it and your delivery gets throttled or filtered to spam, sometimes for weeks. Keep hard bounces under about 0.5% and soft bounces under about 1.5% to stay clear of provider thresholds.

The throughline is that reputation is earned and easily spent. Consistent volume, clean lists, authenticated mail, and engaged recipients build it up. Spikes, bounces, and complaints tear it down.

## How to avoid the spam folder

Staying out of spam comes down to looking legitimate to both the filters and the recipient. There's no single trick; it's a checklist you maintain.

- Authenticate everything with SPF, DKIM, and DMARC.
- Send from a real, monitored domain, not a no-reply address on a throwaway subdomain. Use a reply-to that reaches a human.
- Keep your lists clean by removing hard bounces immediately and suppressing addresses that complain.
- Keep transactional and marketing email on separate streams or subdomains so promotional complaints don't poison your transactional reputation.
- Write honest subject lines that match the body. Mismatched or clickbait subjects train filters and recipients against you.
- Balance content: avoid all-image emails, excessive links, and the spam-trigger phrasing that filters flag.
- Make sure every message has a plain-text version alongside the HTML.

Most spam-folder problems trace back to one of two things: an authentication gap or a reputation problem from poor list hygiene. Fix those two and you've handled the majority of cases.

## How to handle bounces, complaints, and unsubscribes

A bounce is an email that couldn't be delivered; a complaint is a recipient marking your message as spam. Handling both correctly is what protects your sending reputation over the long run, and ignoring them is how good senders slowly go bad.

> **Watch out:** The single fastest way to wreck a sending reputation is to keep emailing addresses that hard-bounced or complained. A suppression list isn't optional, and it has to update automatically.

Bounces come in two kinds. A **hard bounce** is permanent (the address doesn't exist), and you must stop sending to that address immediately and remove it from your list. A **soft bounce** is temporary (a full mailbox, a server hiccup), and you can retry a few times before giving up. Your ESP reports both, usually through webhooks, and the non-negotiable rule is to maintain a suppression list: addresses you never send to again because they hard-bounced or complained.

Complaints are even more direct signals. When a recipient hits "report spam," mailbox providers often relay that through a feedback loop your ESP subscribes to. Treat a complaint as an immediate suppression. For unsubscribes, remember that genuinely transactional email generally doesn't require an unsubscribe link, but the moment a message drifts toward promotional content, you need one, and as of recent bulk-sender requirements, one-click unsubscribe is expected for non-transactional mail. The practical setup is to wire your ESP's bounce and complaint webhooks to an endpoint that updates a suppression list automatically, so reputation protection happens without a human in the loop.

## Frequently asked questions

### Do I really need SPF, DKIM, and DMARC?

Yes. Gmail, Yahoo, and other major providers require all three for bulk senders, and unauthenticated mail is far more likely to be filtered to spam or rejected. All three are DNS records you can set up in an afternoon, and they're the highest-impact thing you can do for deliverability.

### What is a good email deliverability rate?

Aim for a delivery rate of 98-99% or higher for transactional email, since recipients expect and engage with these messages. Below 98% usually points to an authentication gap, list-hygiene problems, or a blocklist. Inbox placement, not only delivery, is the number that really matters.

### Why are my transactional emails going to spam?

Most spam-folder problems come down to two causes: missing or misconfigured authentication, or a damaged sending reputation from poor list hygiene. Fix SPF, DKIM, and DMARC first, remove hard bounces and complainers, keep transactional and marketing mail on separate streams, and send from a real, monitored domain.

Keep transactional email out of spam: set up SPF, DKIM, and DMARC, understand what drives deliverability, and handle bounces, complaints, and unsubscribes.

Email Deliverability: Land in the Inbox

Getting accepted by a mail server is easy; reaching the inbox is the real challenge. Covers SPF, DKIM, and DMARC authentication, what drives deliverability, how to avoid the spam folder, and how to handle bounces, complaints, and unsubscribes.

How to Land in the Inbox, Not Spam

*Last updated: June 2026*

Sending one email is easy; running a transactional email system that's reliable, observable, and ready to scale is the part that earns its keep. This chapter covers the operational concerns that separate a prototype from production: making sends reliable, measuring what matters, knowing when email alone isn't enough, and deciding whether to build or buy.

## How to make sends reliable: retries and idempotency

In production, email sends fail intermittently: a provider has a blip, a network request times out, your process crashes mid-send. Reliability means handling those failures without losing email and without sending duplicates, and the two tools for that are retries and idempotency.

**Retries** handle transient failures. When a send fails with a temporary error, you try again, ideally with exponential backoff (wait 1 second, then 2, then 4) so you don't hammer a struggling provider. A durable queue in front of your sends makes this robust: enqueue the send, process it with a worker, and let the queue redeliver the job if the worker dies.

**Idempotency** keeps retries from causing duplicates. If your worker sends an email and then crashes before recording success, a naive retry sends the email twice, and now your user has two password reset codes and no idea which is real. An idempotency key solves this: you attach a unique key to each logical send, and the provider (or your own dedup layer) ignores a second request with the same key.

```javascript
async function sendWithRetry(message, idempotencyKey, maxAttempts = 3) {
 for (let attempt = 1; attempt <= maxAttempts; attempt++) {
 try {
 // The idempotency key ensures a retried request never sends twice
 return await emailProvider.send(message, { idempotencyKey });
 } catch (error) {
 if (!error.isTransient || attempt === maxAttempts) {
 throw error;
 }
 const backoffMs = 2 ** (attempt - 1) * 1000;
 await new Promise((resolve) => setTimeout(resolve, backoffMs));
 }
 }
}
```

Derive the idempotency key from something stable about the event, like `password-reset:${userId}:${requestId}`, rather than generating a random one per attempt. That way every retry of the same logical send carries the same key, and the duplicate is caught.

> **Key takeaway:** Retries without idempotency are worse than no retries. A random key per attempt defeats the whole mechanism. Always derive the key from the event, not the attempt.

## How to keep transactional email secure

Transactional email often carries the keys to an account: reset links, login codes, verification tokens. That makes it a security surface, not only a delivery problem, and a few rules keep it from becoming a liability.

- **Expire and single-use your tokens.** A reset or magic link should be valid for minutes, not days, and should stop working after one use. A reset link that lives forever in an inbox is a standing account-takeover risk.
- **Avoid open redirects.** If your links route through a redirect or click-tracking URL, validate the destination. An unvalidated redirect in a trusted email is a phishing gift.
- **Keep sensitive data out of the body.** Email isn't a secure channel and ends up in logs, backups, and previews. Send a link to the receipt or the data, not full card numbers, government IDs, or complete account details.
- **Don't leak through enumeration.** A "we've sent a reset link if that account exists" message keeps attackers from probing which addresses are registered.
- **Authenticate to prevent spoofing.** SPF, DKIM, and DMARC (chapter 3) aren't only deliverability tools. DMARC at enforcement is what stops someone sending account-takeover phishing from your own domain.

None of this is exotic, but it's the part teams skip when they treat transactional email as plumbing. The messages that matter most for reliability are usually the same ones that matter most for security.

## Which transactional email metrics to track

You can't operate what you can't see, so instrument your transactional email from day one. The metrics that matter fall into five groups, and most ESPs expose the first four through dashboards and webhooks. The fifth, business impact, you have to connect yourself, and it's the one that tells you whether the email is doing its job.

| Category | Key metrics | Healthy target |
|---|---|---|
| Delivery | Delivered rate, bounce rate, rejection rate | Delivered 98-99%+, hard bounce <0.5%, soft bounce <1.5% |
| Deliverability | Inbox placement, spam-folder rate, spam-complaint rate | Spam complaints <0.3% (ideally <0.1%) |
| Engagement | Open rate, click rate, time to open | Directional; investigate sudden drops |
| Technical health | Send latency, API error rate, queue depth, retry rate | Time-critical sends in seconds, low error rate |
| Business impact | Action-completion rate, support deflection, revenue influenced | Trending up over time |

**Delivery and deliverability** are your reputation early-warning system. Keep your delivered rate at 98-99% or higher; a drop usually points to authentication, list-hygiene, or blocklist problems. Keep hard bounces under about 0.5%, and keep your spam-complaint rate below 0.3% (and ideally under 0.1%), because crossing Gmail's threshold throttles your delivery fast. Inbox placement is the metric that actually matters: a 99% delivered rate means nothing if half of it lands in spam.

**Engagement** matters less for transactional email than for marketing email, but it's not noise. A sudden drop in open rate is often the first sign you've started landing in spam, before the complaint numbers catch up.

**Technical health** is the part only you can see, so set alerts on it. Watch send latency closely for time-critical email like login codes, because a slow send is a failed send from the user's point of view. Queue depth and retry rate tell you your pipeline is backing up before your users do.

**Business impact** is where it's easy to stop short, and it's what separates a metric you watch from a metric that earns budget. Tie each email to the action it exists to drive: for a password reset, the real number is how many recipients successfully reset, not how many emails you sent. For a receipt, it's how many "where's my receipt?" support tickets you avoided. For a failed-payment notice, it's recovered revenue. These numbers connect your email system to outcomes the rest of the business cares about, and they're the ones worth putting in front of leadership.

## When email isn't enough: going multi-channel

Email is the right default for most transactional messages, but it isn't always the fastest or most reliable channel, and some messages need to reach people who aren't checking their inbox. That's when you reach for SMS, push, or in-app notifications alongside email.

The channel should match the message. A login code or fraud alert often belongs on SMS or push, because it's time-critical and email latency is unpredictable. A comment notification might live best as an in-app notification with email as a backup. A receipt is fine as email, since people expect to find it there later. Going multi-channel introduces new problems: you have to respect each user's channel preferences, avoid sending the same notification four ways, and coordinate fallback logic (try push, fall back to email if it isn't delivered). This is the point where you stop thinking in terms of "sending email" and start thinking in terms of "sending notifications" across whatever channel fits, which changes how you architect the whole system.

## Should you run your own mail server?

One option sits underneath all of these: running your own mail server (Postfix or a similar SMTP stack on your own IPs) instead of sending through a provider. It's worth understanding why most teams shouldn't.

The appeal is real: total control and the lowest possible per-message cost at very high volume. But you take on everything a provider otherwise handles for you:

- **IP warming.** A new sending IP has no reputation. You have to ramp volume gradually over weeks before mailbox providers trust it, or your mail goes straight to spam.
- **Feedback loops and bounce parsing.** You register for the feedback loops major providers offer (many only grant them to established senders), then parse bounces and complaints across dozens of inconsistent formats.
- **Reputation and blocklist monitoring.** Land on a blocklist and the remediation and delisting are yours to chase.
- **Compliance and security.** CAN-SPAM, CASL, and GDPR obligations, plus the operational security of an internet-facing mail server, all fall on you.

For all but the largest, most specialized senders, that's a full-time job for several engineers and rarely pays off against a provider doing it at scale. So the realistic decision for almost everyone isn't "self-host vs. provider," but which point on the provider spectrum below to choose.

## Build it yourself vs. use a service

By now the scope is clear: providers, authentication, templates, localization, deliverability, suppression lists, retries, idempotency, metrics, and eventually multiple channels. The real build-versus-buy question isn't whether you can build it, but whether maintaining it is a good use of your engineering time.

It helps to think of this as a spectrum rather than a binary, because you don't have to choose between "raw ESP" and "buy everything." There are three points along it:

1. **Raw ESP.** You send directly through a provider's API and build everything else yourself: templating, suppression, retries, idempotency, and your metrics pipeline. Maximum control and the lowest per-email cost. A reasonable choice when email is your only channel, your volume is modest, and your needs are stable.
2. **ESP plus your own abstractions.** You stay on an ESP but build a thin internal layer around it: a send wrapper that handles retries and idempotency, a template registry, a suppression service. This is where most email systems end up, and it's a sensible middle ground. The risk is that this layer quietly grows into a notification platform you didn't plan to maintain.
3. **Notification infrastructure.** You send through a service that sits above the providers and handles templating, localization, preferences, retries, and multi-channel routing through one API. Platforms like Courier fit here. You trade some control and per-message cost for not building and operating those pieces yourself.

There's no universally correct answer, and the honest version of the trade-off is about trajectory, not today. If email is all you'll ever send and you have the engineering capacity to maintain it, building on an ESP directly is fine. The moment you're juggling multiple channels, user preferences, and a growing template library, that homegrown abstraction layer from option 2 is usually the most expensive thing your team maintains, and the math starts favoring infrastructure. The useful question isn't "build or buy?" but "how much of this layer do I want to own a year from now?"

## How to ship transactional email that works

Transactional email rewards getting the fundamentals right and punishes treating it as an afterthought. If you take away a handful of things from this guide, make it these.

Know what you're sending: transactional email is event-driven, one-to-one, and expected, which is what earns it inbox placement and exempts it from most marketing rules. Get the foundation right before anything else: authenticate with SPF, DKIM, and DMARC, send from a real domain, and keep transactional mail on its own stream. Choose a provider that fits your volume and stack, and lean on its API rather than raw SMTP. Build for production from the start with templates, fallbacks, retries, idempotency, and a suppression list wired to your bounce and complaint webhooks. And measure continuously, watching delivery, deliverability, engagement, and technical-health metrics so you catch problems before your users do.

Start with one email done properly, a password reset or a receipt, with authentication, a clean template, and error handling in place. Get that landing reliably in the inbox, then expand. When you outgrow a single channel or a single ESP, that's the signal to evaluate notification infrastructure that can carry the same rigor across email, SMS, push, and in-app.

## Frequently asked questions

### Which transactional email metric matters most?

Inbox placement rate, because it measures whether your email actually reaches users where they'll see it. Delivery rate can look high while messages quietly land in spam. After placement, track the action each email exists to drive, like password-reset completion, rather than opens.

### Why are my open rates inaccurate?

Open tracking relies on a pixel, and privacy features like Apple Mail Privacy Protection pre-load that pixel whether or not the user opens the message, which inflates reported opens. Treat open rate as a directional trend and lean on click-through and task completion for accuracy.

### Should I build my own transactional email system or buy one?

For almost all teams, build on an email service provider rather than running your own mail server. Whether you then add a thin abstraction layer or adopt notification infrastructure depends on trajectory: once you're juggling multiple channels, user preferences, and a growing template library, infrastructure usually costs less than maintaining that layer yourself.

**Related resources:**
- [Courier documentation](https://www.courier.com/docs/welcome)
- [Courier API reference](https://www.courier.com/docs/reference)

Run transactional email in production: retries and idempotency, the metrics to track, going multi-channel, and the build-versus-buy decision explained.

Operating Transactional Email at Scale

The operational concerns that separate a prototype from production: making sends reliable with retries and idempotency, the metrics that matter, knowing when email alone isn't enough, and deciding whether to build or buy.

Charcoal guide cover with aurora gradient panel and Courier mark.

The Developer's Guide to Transactional Email - cover

A developer's guide to transactional email: how it works, how to send it, choose a provider, authenticate your domain, land in the inbox, and scale it.

The Developer's Guide to Transactional Email

Transactional email is the quiet workhorse of almost every product: password resets, receipts, order confirmations, and verification codes that users actually wait for. This guide starts high-level, so you know exactly what transactional email is and why it behaves the way it does, then goes deep into the implementation details: how to send it, choose a provider, authenticate your domain, stay out of spam, and run it reliably at scale. It's written for developers, but product managers and engineering leaders weighing a build-versus-buy decision will get value from it too.

The Developer's Guide to Transactional Email

Highlights

Contents

Products

Solutions

Platform