Transactional email confirms something the recipient did: a password reset, a receipt, a shipping update. Marketing email promotes something you want them to do next: read a newsletter, try a feature, come back. The distinction sounds cosmetic. It decides which laws govern a message, what consent you need before sending it, and whether one bad campaign can knock your password resets into spam.
If you're choosing email infrastructure for a product, this classification is the first architectural decision. It determines your sending domains, your suppression behavior, and your compliance obligations before you write a line of integration code.
What counts as transactional
A message is transactional when a specific action by the recipient triggers it, and the content completes or reports on that action:
- Password resets and magic sign-in links
- One-time passcodes for two-factor authentication
- Receipts, invoices, and payment failure notices
- Order confirmations and shipping updates
- Security notifications: new device sign-in, password changed, plan changed
- Legal notices: terms updates, data processing changes
Two properties define the category. The trigger is an individual event rather than a schedule or a segment. And the recipient expects the message within seconds, because they caused it. A password reset that arrives five minutes late is a support ticket. A newsletter that arrives five minutes late is a newsletter.
What counts as marketing
Marketing email goes out on the sender's initiative, to drive engagement or revenue:
- Newsletters and product announcements
- Promotional offers and seasonal campaigns
- Win-back and re-engagement sequences
- Referral, upgrade, and trial-expiry nudges
You pick the audience and the timing. The recipient might welcome the message, but they didn't request it, and the law treats it accordingly.
The gray areas
A lot of product email sits between the two categories, and this is where teams misclassify:
Onboarding sequences. Signup triggered them, but a day-three "five features to try" email exists to drive engagement. Most legal teams classify drip onboarding as marketing.
Abandoned cart reminders. The user acted by adding items, but the message exists to close a sale. EU and Canadian regulators treat these as marketing, so consent rules apply.
Digests and activity summaries. A weekly report of the user's own workspace activity leans transactional. The same email with an upsell block leans marketing.
Mixed-content messages. A receipt with a promotional banner is the classic trap. CAN-SPAM applies a primary purpose test: if a reasonable recipient would read the subject line and body as commercial, the whole message is commercial. A discount code inside an invoice can flip the message's legal category.
A test that resolves most of the ambiguity: if the user deleted their account today, should they still receive this message? A final invoice, yes. A feature announcement, no.
Why the classification matters
Consent and legal footing
The three regimes most product teams deal with draw the line in different places, but all of them draw it:
- CAN-SPAM (US) exempts transactional and relationship messages from its opt-out and identification requirements. Commercial messages need accurate headers, a non-deceptive subject line, a physical postal address, and an opt-out honored within ten business days.
- GDPR and the ePrivacy rules (EU) require opt-in consent for most direct marketing, with a soft opt-in exception for existing customers being offered similar products. Transactional email rests on a different lawful basis, performance of a contract, so no consent checkbox covers a password reset and none needs to.
- CASL (Canada) requires express or implied consent for commercial electronic messages and carves out transactional purposes narrowly. Penalties reach millions of dollars per violation.
Misclassify a message as transactional and you may be sending marketing without consent. The reverse error is safer legally but costs you in deliverability and user trust.
Deliverability reputation
Mailbox providers score reputation per sending domain and per IP address. Complaints and spam-folder placements earned by one message type attach to the sending identity, and any other mail sharing that identity inherits the damage. A promotional blast to a stale list can push your complaint rate past Gmail's thresholds, and the resulting filtering applies to your one-time passcodes and receipts too. Separating the streams contains the blast radius.
Mailbox provider rules
Gmail and Yahoo require one-click unsubscribe headers (RFC 8058) on promotional mail from bulk senders, alongside spam-rate ceilings and authenticated sending. Transactional mail is exempt from the unsubscribe requirement. Infrastructure that can't distinguish the two forces a bad choice: add unsubscribe headers to password resets, or omit them from campaigns and fall out of compliance. We cover the details in our guide to RFC 8058 and the bulk sender requirements.
Suppression scope
An unsubscribe from your newsletter must not block password resets. If both streams share one suppression list, a user who opts out of marketing locks themselves out of account recovery, and discovers it at the worst possible moment. Marketing suppression should honor unsubscribes and complaints. Transactional suppression should cover hard bounces and little else. That scoping is only possible when the send path knows which kind of message it's carrying.
How teams split the infrastructure
The standard pattern separates the streams at the domain level:
- Transactional on its own subdomain, such as
mail.example.com, with its own SPF and DKIM records. - Marketing on a separate subdomain, such as
news.example.comorupdates.example.com.
Mailbox providers track reputation per subdomain, so a rough campaign week degrades news. placement without dragging mail. down with it. The isolation has limits, since Gmail also weighs the organizational domain, but separation confines most of the damage and makes reputation problems diagnosable per stream.
Beyond domains, teams typically separate:
- Message streams or API keys. Most email platforms model the split. Route sends through the right stream in code, not by convention in a template name.
- Suppression lists, scoped as described above: unsubscribes and complaints suppress marketing, hard bounces suppress both.
- IP pools, once volume justifies dedicated IPs. Below roughly 100,000 emails a month, shared pools tend to behave better, because a dedicated IP needs consistent daily volume to hold a reputation.
- Warm-up behavior. Transactional volume flows steadily and warms itself. Marketing volume spikes, so new marketing domains and IPs need a gradual ramp before the first large campaign.
The From address deserves the same treatment. Transactional mail benefits from a reply path that routes into your product or support tooling, because recipients respond to receipts and shipping notices with real questions. Marketing mail should carry a monitored reply-to as well; a noreply@ address signals to both recipients and mailbox providers that you don't want to hear back, and replies are a positive engagement signal that helps placement. Two streams, two From identities, two reply paths.
Classify at the send site
The classification belongs in code, where the send happens. The engineer adding an email knows whether a user action triggered it; a spreadsheet audit six months later doesn't. Tag sends by type, route them through the matching stream, and make the transactional path refuse promotional content by policy. Teams that enforce the split at the API call don't end up arguing about it in an incident review.
Samva is a modern email API for product teams. The docs cover domain setup and sending, and pricing is usage-based. Start sending.
