*Last updated: June 2026*

## Key takeaways

- **Transactional email is one-to-one and event-driven.** It's triggered by a user's action and carries information they're expecting, which is what earns it inbox placement and exempts it from most marketing-email rules.
- **Authentication is mandatory, not optional.** SPF, DKIM, and DMARC are required by Gmail, Yahoo, and Microsoft for bulk senders, and unauthenticated mail is filtered to spam or rejected.
- **Use an email service provider, not your own mail server.** A provider handles IP reputation, bounce processing, and deliverability, which is a full-time job to run yourself.
- **Inbox placement is the metric that matters most.** A high delivery rate means nothing if half your mail quietly lands in spam.
- **Build for production from day one.** Templates with fallbacks, retries with idempotency, and a suppression list wired to bounce and complaint webhooks are what separate a prototype from a reliable system.
- **Reach for notification infrastructure when you outgrow a single channel or ESP.** It carries the same rigor across email, SMS, push, and in-app without rebuilding the plumbing each time.

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 matters more than usual, since a dropped password reset locks someone out and a duplicated charge receipt erodes trust. And the rules keep moving: Google and Yahoo made authentication mandatory for bulk senders in 2024, Microsoft followed for high-volume Outlook.com senders in 2025, and the bar will keep rising.

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. Operating the mail server is the straightforward bit; the real ongoing work is maintaining the sending reputation and the relationships with mailbox providers that get you to the inbox.

## 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](https://www.courier.com/blog/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](https://www.courier.com/docs/platform/content/elemental/locales) 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 the inbox view, not just the body.** The Gmail app cuts the subject around 35 characters and the preview text around 45, so [preview the sender name, subject, and preheader](https://www.courier.com/tools/mobile-inbox-preview-generator) the way a phone will show them.
- **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*

A mail server will happily accept your message. Whether it then lands in the inbox or the spam folder is a separate question, 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 as of May 2025 [Microsoft requires the same](https://postmaster.outlook.com/policies.aspx) for high-volume senders to Outlook.com, Hotmail.com, and Live.com. Unauthenticated mail is likely to land in spam or be rejected outright, so 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](https://bimigroup.org/) (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,300 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. When a single message shows as delivered but never reaches someone, [work through a delivery-debugging checklist](https://www.courier.com/docs/tutorials/monitoring/how-to-debug-delivery-issues) to find where it dropped.

## 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 (as of May 2025) Microsoft 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

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.

Cover image for A Comprehensive Guide to Transactional Email.

Transactional Email Guide 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 powers password resets, receipts, confirmations, and verification codes. This guide covers how it works, how to send it, how to choose a provider, authenticate your domain, improve deliverability, and run email reliably at scale.

A Comprehensive Guide to Transactional Email

Highlights

Contents