Short answer
Transactional email is a message your app sends to one person because of something they did, or something that happened to their account: a sign-in code, a password reset, a receipt, a shipping update, a usage alert. The person expects it, it's usually sent by an API call the moment the event happens, and its content is about them.
Marketing email is sent to promote something, usually to many people at once. The difference matters in law: in the US, CAN-SPAM exempts transactional or relationship messages from most of its rules, and in the UK and EU the consent rules for marketing email don't cover pure service messages. It also matters for delivery, because mailbox providers judge mail by how people react to it, so transactional mail should go out on its own stream, and ideally its own IPs, away from marketing.
A definition you can use
An email is transactional when all four of these are true:
- Something specific triggered it: the person did something (signed up, paid, asked for a reset) or something changed on their account (a payment failed, a limit was reached).
- It goes to one person, or to the people directly involved, such as the members of a team.
- Its content is about that event, for that person: their code, their order, their invoice.
- Its main purpose is to inform or let them act, not to sell them something.
The fourth test is the one that matters legally. A receipt is transactional; a receipt with a large "20% off your next order" banner at the top may not be. US and UK regulators both judge a mixed message by what it's mainly for, and in the UK any promotional content at all can tip it over. More on that below.
You'll also see "triggered email". It overlaps: every transactional email is triggered, but not every triggered email is transactional. An abandoned-cart reminder is triggered by an event and sent to one person, but its purpose is to sell, so it's marketing.
16 examples of transactional email
| Sent when | Free template | |
|---|---|---|
| Sign-in or verification code | Someone signs in or confirms an action with a code | One-time code |
| Magic link | Someone signs in without a password | Magic link |
| Password reset | Someone asks to reset their password | Password reset |
| Email address verification | Someone signs up or changes their address | Email verification |
| New sign-in alert | The account is used from a new device or place | New sign-in |
| Password or email changed notice | A security setting changes | - |
| Team or workspace invite | A colleague invites someone | Team invite |
| Order confirmation or receipt | A payment succeeds | Receipt |
| Invoice | A billing period closes | - |
| Payment failed | A card is declined or expires | Payment failed |
| Subscription renewal notice | A renewal or trial end is coming up | Subscription renewal |
| Refund confirmation | A refund is issued | - |
| Shipping or delivery update | An order ships, is delayed or arrives | - |
| Booking confirmation or reminder | An appointment is made or is coming up | - |
| Usage or limit alert | An account nears or passes a plan limit | Usage alert |
| Account deletion or data export ready | Someone closes their account or asks for their data | Account deletion |
The templates are free and open source, each with a plain-text version. See all templates.
The grey areas
Some emails sit between the two, and it's worth deciding on purpose how you treat them:
- Welcome emails. Confirming that an account was created and how to sign in is transactional. A welcome email that is mostly a product tour with upgrade offers is closer to marketing.
- Onboarding tips, feature announcements and digests. Useful and expected, but the person didn't ask for each one and can live without them. Give them an unsubscribe link.
- Activity notifications ("Ada commented on your doc"). Triggered by an event and about the person, but they're something people want to switch off. Treat them as subscribed mail with a preference or unsubscribe link.
- Abandoned cart, review requests and win-back emails. Triggered, but sent to sell. Marketing.
Groundmail has a separate product category for the middle group: onboarding, lifecycle and notification email. It goes out from its own IPs, and people can opt out of it without losing their sign-in codes and receipts (categories in the docs).
Transactional vs marketing email
| Topic | Transactional | Marketing |
|---|---|---|
| Purpose | Inform the person or let them act on their account | Promote a product, service or offer |
| Trigger | An action or account event | A campaign or schedule |
| Recipients | One person per event | A list or segment |
| Timing | Seconds matter (codes, resets) | Hours rarely matter |
| Unsubscribe link | Not required for pure transactional mail | Required (CAN-SPAM opt-out; one-click for bulk senders at Gmail and Yahoo) |
| Consent in the UK and EU | Marketing consent rules don't apply to service messages; data protection law still does | Prior consent, or the existing-customer "soft opt-in" |
| How it's sent | A transactional email API or SMTP relay | An email marketing platform |
United States: CAN-SPAM
The FTC's CAN-SPAM compliance guide sorts email content into commercial, transactional or relationship, and other. Transactional or relationship content is narrowly defined. It covers messages that:
- facilitate, complete or confirm a commercial transaction the recipient already agreed to;
- give warranty, recall, safety or security information about a product or service they bought;
- notify them of a change in the terms or features of their membership, subscription or account, or of their standing in it, or give periodic account balance information;
- give information about an employment relationship or employee benefits;
- deliver goods or services as part of a transaction the recipient already agreed to.
A message whose primary purpose is transactional or relationship is exempt from most of the Act, including the opt-out, ad-identification and physical address rules, but it still must not contain false or misleading routing information. For mixed messages, the primary purpose decides. The guide treats a message as commercial if the subject line would make a reasonable recipient think it's an ad, or if the transactional content doesn't appear mainly at the beginning. Penalties apply per email, with a maximum that is adjusted for inflation.
UK and EU: PECR, the ePrivacy Directive and GDPR
In the EU, consent for marketing email comes from Article 13 of the ePrivacy Directive: sending direct marketing by email needs the recipient's prior consent, with an exception for existing customers being sent offers for similar products, who must be given an easy, free way to object when their details are collected and in every message. The UK implements the same rules in PECR.
Service messages fall outside those rules. The UK regulator's guidance on identifying direct marketing gives examples such as reminding people how to contact you about a problem and confirming appointments. It is also strict about mixing: if a service message includes any direct marketing, even when that isn't its main purpose, the whole message counts as direct marketing, and a neutral tone doesn't necessarily change that.
Data protection law applies to transactional email too. Under GDPR you need a lawful basis for using someone's address; for account and order email that's usually that the processing is necessary for a contract with them (Article 6(1)(b)). Article 21 gives people an absolute right to object to their data being used for direct marketing, which is one more reason to keep the two kinds of mail apart.
Why transactional email needs its own stream and IPs
Gmail, Outlook and Yahoo decide where your mail goes partly from your sending reputation, and that reputation is built from how people react to everything sent from your IPs and signed with your domain. People open receipts and sign-in codes. Some of them mark newsletters as spam, even ones they signed up for.
If both kinds of mail share IPs and a domain, the complaints from a marketing campaign count against your password resets. Google's sender guidelines ask every sender to keep the spam rate reported in Postmaster Tools below 0.3%, and that number covers all mail from your domain. A bad campaign on Tuesday can be why sign-in codes land in spam on Wednesday.
Keeping them apart protects the mail you can't afford to lose:
- Separate IPs. Transactional mail goes out from IPs that carry nothing else, so marketing complaints don't touch its IP reputation. Ask your provider what its shared pool carries; if the answer is "anything", you share other senders' reputations too. See shared vs dedicated IP.
- A separate subdomain. Send transactional mail from
mail.example.comand marketing fromnews.example.com, both under the brand people know. Each builds its own domain reputation. - Separate unsubscribes. Someone who unsubscribes from your newsletter must still get their password reset. Suppress per stream, not globally.
What a transactional email API does
You can send transactional email from your own mail server, but most apps use a transactional email API, because the work isn't in writing the message. A good one does this for you:
- Accepts a send over HTTPS (one JSON request) or SMTP, and returns a message id at once so your app isn't waiting on delivery.
- Authenticates it as your domain: DKIM signing with your key and a return path on your domain, so SPF, DKIM and DMARC pass and align. See SPF, DKIM and DMARC.
- Delivers it to each recipient's mail server, retrying when a server defers it, and from IPs with a good reputation.
- Handles bounces and complaints, keeping a suppression list so you stop sending to addresses that don't exist or people who marked you as spam.
- Tells your app what happened with webhooks: delivered, delayed, bounced, complained.
- Stores templates so the copy lives outside your code and can be changed without a deploy.
- Keeps logs you can search when a user says "I never got it".
- Makes retries safe with idempotency keys, so a timed-out request doesn't send twice.
import { Groundmail } from "groundmail";
const gm = new Groundmail(process.env.GROUNDMAIL_API_KEY!);
await gm.emails.send({
from: { email: "billing@mail.example.com", name: "Example" },
to: "ada@example.org",
subject: "Your Example receipt",
text: "Thanks for your payment of $20.00 for Example Pro (October).",
html: "<p>Thanks for your payment of <strong>$20.00</strong> for Example Pro (October).</p>",
idempotencyKey: "receipt:inv_1042",
});To compare providers on price, dedicated IPs and features, see the best transactional email APIs, with prices checked against each vendor's own pricing page, and how to choose an email API.
Common mistakes
| Mistake | What happens | Fix |
|---|---|---|
| Promotions in receipts and resets | The message can count as marketing in law, and it draws spam reports | Keep transactional mail to its one job; send offers separately |
| One IP pool and domain for everything | Marketing complaints follow your sign-in codes into spam | Separate streams, IPs and ideally subdomains |
| A global unsubscribe | Someone who left the newsletter stops getting password resets | Unsubscribe per category; never suppress transactional mail for a marketing opt-out |
| Calling a newsletter transactional | No consent, no unsubscribe, and complaints that land on your transactional reputation | Classify honestly; give subscribed mail an unsubscribe link |
| Auth mail behind a batch queue | Codes and links arrive after they expire | Send from the request, or from an urgent-only queue |
| Click tracking on auth links | Redirect domains in security email, and tokens in tracking logs | Turn click tracking off for sign-in and reset mail |
| Sending from an unauthenticated domain | Filtered or rejected, especially at Gmail and Outlook | SPF, DKIM and DMARC aligned with the From domain |
Frequently asked questions
What is transactional email?
Email an app sends to one person because of something they did or something that happened to their account, such as a sign-in code, password reset, receipt, shipping update or usage alert. It's expected, specific to them, and its main purpose is to inform, not to sell.
What are examples of transactional email?
Sign-in codes and magic links, password resets, email verification, new sign-in alerts, team invites, receipts and invoices, payment failed notices, renewal reminders, refund confirmations, shipping updates, booking confirmations, usage alerts and account deletion confirmations.
Do transactional emails need an unsubscribe link?
Not if they're purely transactional. CAN-SPAM exempts transactional or relationship messages from its opt-out rule, and Gmail's and Yahoo's one-click unsubscribe requirement covers marketing and subscribed mail. Activity notifications and digests that people can switch off should have one.
Can I add marketing to a transactional email?
Carefully, if at all. Under CAN-SPAM the primary purpose decides, and the transactional content has to come first. Under the UK's PECR, any direct marketing in a service message makes the whole message direct marketing. Promotions in receipts also tend to draw spam reports against the mail you most need delivered.
Is a welcome email transactional?
A welcome email that confirms the account and explains how to sign in is transactional. One that is mostly a product tour, offers and upgrade pitches is closer to marketing, and should be treated that way.
Do I need consent to send transactional email under GDPR?
The marketing consent rules don't apply to pure service messages, but GDPR still does: you need a lawful basis for using the address, which for account and order email is usually that it's necessary for a contract with the person (Article 6(1)(b)).
What is the difference between a transactional email API and an email marketing platform?
A transactional email API sends one message per event from your code, fast, with webhooks, suppressions and logs. A marketing platform sends campaigns to lists, with list management, segmentation and unsubscribe handling built around consent. Most apps use both, on separate streams.
Sources
Facts on this page about other companies' products, prices and policies come from these public pages. They change, so check them before you decide.