Email Types: Transactional vs Marketing

Almost every deliverability problem, compliance fine, and angry "why am I getting this?" reply traces back to one root cause: an email was classified, and therefore sent, as the wrong type. This chapter answers how to tell transactional from marketing email, why the line matters both legally and technically, and how to wire your sending so the two never contaminate each other.

This guide gives general legal information, not legal advice. Email law varies by jurisdiction and changes over time. Consult a qualified lawyer before relying on any legal point below for your specific situation.

Quick answers to what this chapter covers:

• What is the difference between a transactional and a marketing email?
• Why does the transactional/marketing split matter so much?
• How do I tell which type an email is?
• What do the laws (CAN-SPAM, GDPR, CASL) require for each type?
• What about gray-area emails like abandoned cart and welcome emails?
• Why do I need separate subdomains for each type?

The single most important sentence in this entire guide: the type of an email is a property of its content and purpose, not a property of how your code happens to send it. A message is transactional or marketing because of what it contains and why you sent it, not because you routed it through your "transactional API" or your "campaign tool." Filters, regulators, and recipients all judge the message, never your architecture. Every rule below follows from that one fact.

What is the difference between a transactional and a marketing email?

A transactional email confirms or completes something the user just did or is waiting for. A marketing email is something you send because you want the user to read it, not because they triggered it.

Put another way: transactional email is something the user is waiting for; marketing email is something you want them to read.

• A transactional email is triggered by a specific user action (a signup, a purchase, a password request) or by a legal duty you owe the user. It carries information the user needs and expects. Examples: password resets, order confirmations, OTP/2FA codes, shipping notices, receipts.
• A marketing email is sent on your schedule to promote, inform, or re-engage. Its purpose is to drive a future action (buy, click, return). Examples: newsletters, product announcements, promotional offers, abandoned-cart nudges.

The classification decides three things at once: which laws apply, whether you need consent and an unsubscribe link, and which sending subdomain the message should leave from. Get the type wrong and you break at least one of those.

The three independent axes of classification

It helps to stop thinking of "transactional vs marketing" as a single switch and instead see three axes that usually align but can diverge. When they diverge, you have a gray-area email and you must classify defensively.

When all three poles point "transactional," you have an unambiguous transactional email. When all three point "marketing," it is unambiguously marketing. The dangerous emails are the ones where the trigger looks transactional (a real cart, a real signup) but the content axis points marketing (an offer, a discount). The content axis wins. Regulators and filters read the message, not your trigger logic. A receipt with a 20%-off footer is a marketing email that happens to also contain a receipt.

Why mailbox providers care about this at all

It is tempting to treat the split as a legal artifact. It is not. As of February 2024, the three largest consumer mailbox operators, Google (Gmail), Yahoo, and Microsoft, enforce concrete bulk sender requirements that hinge directly on this distinction:

• Authentication. Every sending domain must pass SPF (RFC 7208) and DKIM (RFC 6376), and the organizational domain must publish a DMARC (RFC 7489) policy of at least p=none with alignment.
• Spam complaint rate below 0.3%. Measured by the provider (e.g. via Google Postmaster Tools), this is a hard ceiling. Sustained rates above 0.3% get your mail throttled or junked; the soft target is below 0.1%.
• One-click unsubscribe on bulk mail. Marketing-class messages must implement RFC 8058 one-click unsubscribe (the List-Unsubscribe and List-Unsubscribe-Post headers together), and must honor the request within two days.

"Bulk" is generally read as roughly 5,000+ messages per day to a given provider, but the prudent assumption is that any marketing stream will eventually cross that line, so you design for it from day one. Crucially, the 0.3% complaint ceiling is computed across your sending identity. If marketing complaints and transactional mail share a domain, a single bad campaign can push your combined rate over the line and bury your password resets. That is the technical reason, independent of any law, to separate the streams. See Sending Reliability for how reputation accrues per identity.

Why does the transactional/marketing split matter so much?

Because it is not a stylistic choice. It changes the rules you must follow and the technical setup that keeps your mail in the inbox. Getting it right buys you three concrete things:

1. Lower legal exposure. Marketing email is regulated far more strictly than transactional. Misclassifying a marketing message as transactional, to skip consent or the unsubscribe link, is one of the most common and most expensive compliance mistakes.
2. Better deliverability. Mailbox providers (Gmail, Outlook, Apple Mail) score senders on engagement and complaints. Mixing promotional content into a password reset trains spam filters to distrust your most critical mail.
3. More user trust. People expect a receipt to look like a receipt. The moment a "transactional" email tries to upsell them, the implicit contract breaks and complaint rates climb. A complaint rate above 0.3% (Gmail's threshold) starts hurting every email you send.

What goes wrong if I get the type wrong?

• Marketing dressed as transactional: you send without consent, omit the unsubscribe link, and expose yourself to fines under GDPR (up to 20 million euro or 4% of global turnover) or CAN-SPAM (up to 53,088 USD per email in the US).
• Transactional dressed as marketing: users unsubscribe from "your emails" and then never get their password reset or receipt, generating support tickets and account lockouts.
• Both mixed on one subdomain: a single bad campaign drags down the reputation that delivers your receipts, and password resets start landing in spam.

How the failure modes actually compound

The reason this matters more than a clean two-by-two table suggests is that the failures feed each other. Walk one realistic chain:

1. A growth team adds a "Save 15% on your next order" block to the order-confirmation email. It is now legally a marketing email, but it still routes through the transactional system, so it has no unsubscribe link.
2. Recipients who do not want promotions cannot unsubscribe, so a fraction of them hit "Report spam" instead, the only button available to them.
3. The complaint rate on the shared domain climbs past 0.3%. Gmail begins junking mail from that domain.
4. Because the same domain carries password resets, those start landing in spam too. Users who can no longer log in file support tickets and, in frustration, also report the password-reset mail as spam, pushing the rate even higher.
5. Now both streams are damaged, recovery takes weeks of careful re-warming, and the original "15% off" experiment never even got measured cleanly.

Every link in that chain is a direct consequence of the one decision in step 1. This is why the split is treated as architectural, not cosmetic.

How do I tell which type an email is?

Run the email through this checklist before you send any new type. If a single email gives conflicting answers, it is a hybrid and you should split it.

• Is the email triggered by a specific user action or legal obligation? Leans transactional.
• Does it contain any offer, promo, upsell, or cross-sell? It is marketing.
• Would the user be blocked or harmed if it did not arrive? Transactional.
• Am I relying on consent to send it? It is marketing.
• Does it carry an unsubscribe link? It should be marketing.
• Am I sending it from the marketing subdomain? It should be marketing.

A decision procedure you can run in your head

When the checklist gives mixed answers, resolve in this fixed order. Stop at the first rule that fires:

1. Does the content contain any offer, upsell, cross-sell, discount, or "while you're here" promotion? → Marketing. (Content axis overrides everything.)
2. Could you withhold this email and the user would be blocked, locked out, or left without a record they need? → Transactional.
3. Is the email's primary purpose to drive a future action rather than confirm a past one? → Marketing.
4. Are you relying on the user's consent (rather than a contract or a clear user action) as your reason to send? → Marketing.
5. None of the above fired cleanly? → Treat it as marketing. The cost of wrongly adding an unsubscribe link to a transactional email is near zero; the cost of wrongly omitting one from a marketing email is a fine plus a deliverability hit.

That last default, "when in doubt, marketing", is deliberate. The asymmetry of consequences means the safe failure direction is over-classifying as marketing, never under-classifying.

How do I recognize a transactional email?

Ask these questions. If the answer to most is "yes," it is transactional:

• Did the user just do something that this email confirms or completes?
• Would the user be confused, blocked, or worried if it did not arrive?
• Is it free of offers, cross-sells, and "while you're here" content?
• Would you be comfortable sending it even to someone who never consented to marketing?

A simple analogy: transactional emails are everything that would leave you with a paper receipt in the real world. Invoices, a parking ticket, a booking confirmation. If a physical paper trail would naturally exist, the digital equivalent is almost always transactional.

Transactional characteristics:

• User-initiated or expected
• Time-sensitive and actionable
• Required for the user to complete an action
• Contains no promotional material or offers
• Can be sent without explicit opt-in (with limits)

Common transactional examples: password reset links, order confirmations, account verification, OTP/2FA codes, shipping notifications, receipts, security alerts, billing notices.

The "one trigger, one recipient, one outcome" test is a fast way to confirm: a transactional email is sent to exactly one person as the direct result of exactly one event, and it would be nonsensical to send it to anyone else. You would never "schedule a campaign" of password resets to a segment. The moment an email is addressed to a list or a segment, it has left the transactional category, regardless of content.

How do I recognize a marketing email?

• Its goal is to drive a future action (buy, read, click, return) rather than confirm a past one.
• It would still "work" if you delayed it by a day or a week.
• Removing it would not break any flow the user started.
• Its success is measured in opens, clicks, and conversions rather than delivery.

Marketing characteristics:

• Promotional or informational content
• Not time-sensitive to complete a transaction
• Requires explicit opt-in (consent) in opt-in regions
• Must include an unsubscribe option
• Subject to stricter compliance requirements

Common marketing examples: newsletters, product announcements, promotional offers, company updates, educational content, re-engagement campaigns, and abandoned-cart emails (see the gray-area question below).

What does the side-by-side comparison look like?

A subtle but important row is suppression scope. Marketing mail must respect a suppression list that includes unsubscribes and complaints; transactional mail generally must not honor a marketing unsubscribe (or it would stop sending the receipts the user needs). Keeping these suppression scopes separate is a hard requirement, covered in List Management.

What do the laws require for each type?

Reminder: the following is general information, not legal advice. Laws differ by country and change. Verify the current rules for the markets you send to.

The short version: the US uses an opt-out model, the EU uses an opt-in model, and Canada uses a consent model with two flavors. If you serve more than one region, design to the strictest standard that applies (typically EU opt-in plus a visible unsubscribe). That keeps a single sending flow compliant across markets.

A useful mental model: the law mostly regulates the marketing stream. Transactional email is the carve-out that exists in every regime precisely because the user needs it. That is why "is this transactional?" is also the question "am I allowed to skip consent?", and why the temptation to misclassify exists at all.

What does CAN-SPAM (US) require?

The US uses an opt-out model. You do not need prior consent to send marketing email, but you must honor unsubscribe requests.

CAN-SPAM uses a content-based three-way classification, transactional or relationship, commercial, and dual-purpose, rather than the simple two-way split. A message whose primary purpose is commercial is a "commercial message" and carries the full obligations; a message that is purely transactional or relationship content is exempt from most of them but still may not contain false or misleading headers.

Transactional emails under CAN-SPAM:

• Can be sent without opt-in
• Must be related to a transaction
• Cannot contain promotional content (with narrow exceptions)
• Must identify the sender and provide contact information

Marketing emails under CAN-SPAM:

• Require an opt-out mechanism (not opt-in in the US)
• Must include clear sender identification
• Must not use deceptive subject lines or "From" fields
• Must include a valid physical mailing address
• Must honor opt-out requests within 10 business days

The "primary purpose" rule is what kills the receipt-with-an-offer pattern in the US specifically: when a message mixes transactional and commercial content, the FTC looks at whether a recipient would reasonably interpret the subject line and the bulk of the body as commercial. A receipt with a dominant promotional banner can flip to "commercial" and lose its exemption.

Practical takeaway: even though the US does not require opt-in, the deliverability cost of sending to people who did not ask is high. Treat opt-in as a best practice everywhere, even where the law permits opt-out.

What does GDPR (EU) require?

The EU uses an opt-in model. Consent must be freely given, specific, informed, and unambiguous. Pre-ticked boxes and bundled consent do not count. In practice the operative rule for email marketing in the EU comes from the ePrivacy Directive (the "cookie and electronic communications" directive), with GDPR governing the underlying personal data and defining what valid consent looks like.

Transactional emails under GDPR:

• Can be sent based on legitimate interest or contract fulfillment
• Must be necessary for service delivery
• Cannot contain marketing content without separate consent

Marketing emails under GDPR:

• Require explicit opt-in consent
• Must clearly state the purpose of data collection
• Must provide an easy unsubscribe
• Are subject to data protection requirements, including the right to erasure

Why this matters: under GDPR, the lawful basis for a transactional email is usually "performance of a contract." You send it because you owe the user the service. The moment you add a promo banner, that basis no longer covers the message, and you have effectively sent unconsented marketing.

There is one narrow EU exception worth knowing: the soft opt-in. The ePrivacy Directive permits marketing to an existing customer about your own similar products, provided you collected the address during a sale, you gave a clear opt-out at collection time, and every subsequent message offers an easy unsubscribe. It does not cover prospects, third-party data, or unrelated products, and several member states implement it more strictly. Do not lean on it without local advice, but know it exists, because it is why a post-purchase "you might also like" email can sometimes be legal in the EU without a fresh checkbox.

What does CASL (Canada) require?

Canada's CASL is among the strictest regimes. It distinguishes between express consent (the user actively agreed) and implied consent (for example, an existing business relationship). Penalties reach up to 10 million CAD per violation for organizations.

Transactional emails under CASL:

• Can be sent without consent if related to an ongoing business relationship
• Must be factual and not promotional

Marketing emails under CASL:

• Require express or implied consent
• Must include an unsubscribe mechanism that works for at least 60 days
• Must identify the sender clearly with valid contact information

CASL is the strictest of the three because it regulates the sending of a commercial electronic message at all, not just the content rules around it. Implied consent from an "existing business relationship" is also time-boxed (commonly two years from the last purchase, or six months from an inquiry), after which it expires and you need express consent. If you serve Canada, your consent records must store when and how consent was obtained, because the burden of proof is on the sender. See Email Capture for how to record this at signup.

Which consent model applies in each region?

Designing one flow that satisfies all three

You do not want region-specific sending logic scattered through your app. The maintainable pattern is to build to the strictest common denominator and store enough metadata to prove it:

• Collect explicit opt-in everywhere (satisfies EU and CASL express consent; exceeds US requirements).
• Record consent provenance on every subscriber: timestamp, source (which form/checkbox), the exact wording shown, and IP/locale. This is the artifact you produce if a regulator asks.
• Put a working unsubscribe in every marketing message, implemented as one-click (RFC 8058) so it also satisfies the Gmail/Yahoo/Microsoft bulk-sender rules, plus a visible in-body link and your physical postal address (CAN-SPAM).
• Honor unsubscribes immediately in practice, even though the law allows up to 10 business days, modern recipients expect instant removal, and slow removal drives complaints.
• Never apply marketing suppression to transactional sends. Unsubscribe scope is marketing-only.

For the full breakdown of legal requirements per email type, see Compliance.

When should I use each type?

When should an email be transactional?

• The user needs the email to complete an action
• The email confirms a transaction or account change
• The email provides security-related information
• The email is expected based on a user action
• The content is time-sensitive and actionable
• You are required to serve a notification for compliance

When should an email be marketing?

• You are promoting products or services
• You are sending newsletters or updates
• You are sharing educational content
• You are announcing features or company news
• The content is not required for any transaction

What about gray-area emails that feel like both?

Some emails sit on the fence. Here is how to classify the common ones.

Is an abandoned-cart email transactional or marketing?

Marketing, in most jurisdictions. Many teams assume cart-recovery emails are transactional because they reference a real cart. But the user did not complete a transaction, and the email's purpose is to persuade them to buy. Treat it as marketing: require consent and include an unsubscribe link.

Is a welcome email transactional or marketing?

It depends on content. A welcome email that confirms the account and explains how to get started can be transactional, as long as it carries no promotion. Add a discount code, a "check out our other products" block, or a newsletter pitch, and it becomes marketing and needs consent plus an unsubscribe link.

What other emails commonly get misclassified?

• Product update / changelog emails: marketing unless the change is something the user must act on (for example, a required migration or a security fix). Informational "look what's new" content is marketing.
• Re-engagement / "we miss you" emails: marketing. They drive a future action and need consent.
• Receipts with an upsell footer: the receipt is transactional, but the upsell footer makes the whole message marketing. Strip the footer.
• Survey and feedback requests: usually marketing, unless the survey is a required part of a service the user is mid-flow on.

A reference table for the hardest cases

The pattern across every row is identical: the email starts transactional or marketing based on its trigger, and it flips toward marketing the instant promotional content is added. It never flips the other way. There is no content you can add to a marketing email that makes it transactional.

How do I handle a true hybrid that mixes both?

Some emails genuinely mix transactional and marketing content (for example, a newsletter with a small order-status update wedged in). This is not best practice and should be avoided.

Why hybrids are dangerous:

• They lose the legal protection of the transactional category. The promotional content can require consent and an unsubscribe link even though the email also carries critical information.
• If a user unsubscribes from the "newsletter half," you may inadvertently stop sending them the order updates they actually need.
• They blur reputation between your transactional and marketing streams, dragging down deliverability for both.

How to fix a hybrid:

1. Identify the single most important purpose of the email.
2. Strip everything that does not serve that purpose.
3. If the removed content still matters, send it as a separate email of the correct type.
4. Route each email through the matching subdomain and consent rules.

A common safe pattern: a transactional order confirmation with no promotion, followed (only if the user consented to marketing) by a separate "you might also like" campaign.

Worked example: splitting a contaminated order confirmation

Suppose product wants the order confirmation to also drive repeat purchases. Resist merging them. Split into two messages:

// provider is a generic, ESP-agnostic wrapper around whatever you use
// (Amazon SES, Postmark, SendGrid, Mailgun, Resend, Brevo, SparkPost…).
// The point is that NO ESP specifics leak into this code.
import { provider } from './lib/email';

type Order = { id: string; email: string; total: string; items: string[] };

// 1) TRANSACTIONAL: always sent, no consent needed, no promo, no unsubscribe.
async function sendOrderConfirmation(order: Order) {
  await provider.send({
    from: 'Acme Orders <orders@t.yourdomain.com>', // transactional subdomain
    to: order.email,
    subject: `Order ${order.id} confirmed`,
    text:
      `Thanks for your order.\n\n` +
      `Order: ${order.id}\n` +
      `Total: ${order.total}\n` +
      `Items:\n${order.items.map((i) => `  - ${i}`).join('\n')}\n\n` +
      `We'll email you again when it ships.`,
    // No List-Unsubscribe header: this is transactional.
  });
}

// 2) MARKETING: only if the user opted in. Separate subdomain, unsubscribe required.
async function sendPostPurchaseUpsell(order: Order, unsubscribeUrl: string) {
  const consented = await hasMarketingConsent(order.email);
  if (!consented) return; // hard gate, never send marketing without consent

  await provider.send({
    from: 'Acme <hello@m.yourdomain.com>', // marketing subdomain
    to: order.email,
    subject: 'Picked for you, based on your order',
    text: `You might also like…\n\nManage preferences: ${unsubscribeUrl}`,
    headers: {
      // RFC 8058 one-click unsubscribe, required for bulk marketing mail.
      'List-Unsubscribe': `<${unsubscribeUrl}>, <mailto:unsubscribe@m.yourdomain.com>`,
      'List-Unsubscribe-Post': 'List-Unsubscribe=One-Click',
    },
  });
}

// Calling site: the transactional send is unconditional; the marketing send is gated.
export async function onOrderPlaced(order: Order, unsubscribeUrl: string) {
  await sendOrderConfirmation(order);             // always
  await sendPostPurchaseUpsell(order, unsubscribeUrl); // only if opted in
}

// Stand-in for your real consent store; see chapter 06 (Email Capture).
declare function hasMarketingConsent(email: string): Promise<boolean>;

Two emails, two subdomains, two sets of rules, zero contamination. The transactional message can never be blocked by a marketing unsubscribe, and the marketing message can never drag down the transactional domain's complaint rate. See Transactional Email Design and Marketing Emails for the content best practices on each side.

Which transactional emails does my app actually need?

For a complete catalog of transactional emails and recommended combinations by app type, see the Transactional Email Catalog.

Quick reference, the essentials for most apps:

1. Email verification is required for account creation.
2. Password reset is required for account recovery.
3. Welcome email is good user experience (and must not be promotional).

The catalog includes detailed guidance for:

• Authentication-focused apps
• Newsletter / content platforms
• E-commerce / marketplaces
• SaaS / subscription services
• Financial / fintech apps
• Social / community platforms
• Developer tools / API platforms
• Healthcare / HIPAA-compliant apps

Why do I need separate subdomains for transactional and marketing?

Because mailbox providers track reputation per sending domain. If a marketing blast triggers complaints, an isolated m. subdomain absorbs the damage while your t. subdomain, the one carrying password resets and receipts, stays clean. Never send your password resets from the same domain as your promotions.

Benefits of separation:

• Protects transactional deliverability
• Lets you use different authentication domains
• Gives each stream independent reputation
• Makes compliance management easier

Implementation: use different subdomains, for example t.yourdomain.com for transactional and m.yourdomain.com for marketing. Configure SPF, DKIM, and DMARC on each. See Deliverability for the authentication setup.

Subdomains, streams, and IP pools, what is actually being separated?

"Separate subdomains" is the headline, but there are four levels of isolation, and they are not the same thing. Understand which ones you control:

1. From-domain (subdomain) reputation. The most important and the one you always control. Mailbox providers attach reputation to the organizational domain and the specific sending subdomain. Distinct subdomains (t. vs m.) give the two streams independent reputation histories. This is mandatory.
2. DKIM signing domain (d=). Your DKIM signature carries a d= domain. Aligning it to the matching subdomain reinforces the separation and is what DMARC alignment checks. Sign transactional mail with d=t.yourdomain.com and marketing with d=m.yourdomain.com.
3. Sending "streams" / "subusers." Many providers expose a logical "message stream" or "subaccount" concept so you can keep configuration, suppression lists, and analytics separate even before IPs. Use these to keep transactional and marketing suppression lists from leaking into each other.
4. IP pools. At sufficient volume you put the two streams on separate dedicated IPs (or IP pools), so an IP's reputation cannot bleed across streams. Below a few tens of thousands of messages a month, a well-managed shared IP is usually fine and a dedicated IP can actually hurt (you cannot keep it warm). IP separation is a high-volume concern; domain separation is a day-one concern.

The rule of thumb: always separate at the domain/subdomain level from day one; add IP-pool separation only when volume justifies a dedicated IP. Warming and reputation mechanics live in Sending Reliability.

Copy-paste DNS for two clean sending subdomains

These are illustrative records. Your provider gives you the exact CNAME/TXT values for DKIM (the selector and key are theirs); the SPF include and DMARC policy are yours to set. Replace yourdomain.com, the DKIM selector, and the provider include with your real values.

Transactional subdomain t.yourdomain.com:

; SPF (RFC 7208), authorize your provider's sending hosts for this subdomain
t.yourdomain.com.            IN  TXT   "v=spf1 include:_spf.yourprovider.example -all"

; DKIM (RFC 6376), provider supplies the selector + public key (CNAME or TXT)
sel1._domainkey.t.yourdomain.com.  IN  CNAME  sel1.dkim.yourprovider.example.

; DMARC (RFC 7489), published on the subdomain; start at none, then tighten
_dmarc.t.yourdomain.com.    IN  TXT   "v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com; adkim=s; aspf=s"

Marketing subdomain m.yourdomain.com:

m.yourdomain.com.            IN  TXT   "v=spf1 include:_spf.yourprovider.example -all"
sel1._domainkey.m.yourdomain.com.  IN  CNAME  sel1.dkim.yourprovider.example.
_dmarc.m.yourdomain.com.    IN  TXT   "v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com; adkim=s; aspf=s"

Notes that matter:

• adkim=s; aspf=s request strict alignment so the From: domain must exactly match the DKIM d= / SPF domain. Strict alignment is what makes per-subdomain separation enforceable.
• Start every DMARC record at p=none with rua reporting on, read the aggregate reports for a week or two, confirm both SPF and DKIM pass and align, then move to p=quarantine and finally p=reject. Jumping straight to p=reject before reading reports is the classic way to junk your own mail.
• The organizational _dmarc.yourdomain.com policy applies to subdomains unless you publish subdomain-specific records like the ones above. Publishing per-subdomain records lets you tighten the marketing domain on its own schedule without risking transactional delivery.

Verifying the setup with dig

Before sending a single message, confirm each record resolves:

# SPF on the transactional subdomain
dig +short TXT t.yourdomain.com

# DKIM public key (swap in your real selector)
dig +short TXT sel1._domainkey.t.yourdomain.com
dig +short CNAME sel1._domainkey.t.yourdomain.com

# DMARC policy for the subdomain
dig +short TXT _dmarc.t.yourdomain.com

# Repeat all three for m.yourdomain.com
dig +short TXT m.yourdomain.com
dig +short TXT _dmarc.m.yourdomain.com

If a lookup returns nothing, the record has not propagated or the name is wrong (a frequent mistake is double-appending the domain, e.g. publishing t.yourdomain.com.yourdomain.com). Send a test message to a Gmail and a Microsoft account, open "Show original" / message headers, and confirm SPF=PASS, DKIM=PASS, and DMARC=PASS with the expected d= domain before going live.

Optional but recommended: hardening beyond SPF/DKIM/DMARC

Once the three core records pass, these standards harden the channel and improve how some providers treat your mail. They are stream-agnostic, apply them at the organizational domain:

• MTA-STS (RFC 8461) and TLS-RPT (RFC 8460): enforce TLS for inbound mail to your domain and get reports on TLS failures. Relevant if you also receive mail at the domain.
• ARC (RFC 8617): Authenticated Received Chain preserves authentication results across forwarders/mailing lists. You mostly benefit from receivers honoring it rather than publishing anything yourself, but it matters when your transactional mail is auto-forwarded.
• BIMI: lets you display a verified brand logo in supporting inboxes, but it requires p=quarantine or p=reject DMARC first (and, for most providers, a Verified Mark Certificate). Treat it as a reward for getting DMARC enforcement right, not a starting point.

These are covered in depth in Deliverability.

What should I look for in an email service?

Choose a service that:

• Provides reliable delivery for transactional emails
• Offers separate sending domains
• Has a good API for programmatic sending
• Provides webhooks for delivery events
• Supports authentication setup (SPF, DKIM, DMARC)
• Lets you isolate transactional and marketing into separate streams (and IP pools at volume)
• Maintains per-stream suppression lists so a marketing unsubscribe never blocks a receipt

Dedicated email providers (such as Amazon SES, Postmark, SendGrid, Mailgun, Resend, Brevo, SparkPost, or Mandrill) are designed for high-deliverability sending and provide the infrastructure and tools needed for reliable delivery. Most also offer marketing features for the other stream. None of this guide assumes a specific provider, every code sample uses a generic provider/emailClient wrapper or raw standards, so the patterns port to any of them.

What does a clean transactional send look like in code?

A transactional send should be triggered directly by a user action and contain no promotional content. The identifiers below are intentionally in English even in the Polish edition.

// emailClient is a thin, provider-agnostic wrapper around whatever ESP you use
// (Amazon SES, Postmark, SendGrid, Mailgun, Resend, Brevo, …) configured with EMAIL_API_KEY.
import { emailClient } from './lib/email';

// Triggered immediately when the user requests a password reset
export async function sendPasswordReset(email: string, resetUrl: string) {
  await emailClient.send({
    // Note the dedicated transactional subdomain
    from: 'Acme Security <security@t.yourdomain.com>',
    to: email,
    subject: 'Reset your password',
    text: `We received a request to reset your password.\n\nReset it here (expires in 1 hour): ${resetUrl}\n\nIf you didn't request this, you can safely ignore this email.`,
    // No List-Unsubscribe header, no promo, no marketing suppression check.
  });
}

What does a compliant marketing send look like in code?

The marketing counterpart differs in three concrete ways: it is gated on consent, it leaves from the marketing subdomain, and it carries RFC 8058 one-click unsubscribe headers. Below, the one-click POST endpoint is implemented against the raw standard, no SDK required.

import { emailClient } from './lib/email';

export async function sendNewsletter(email: string, body: string, unsubscribeUrl: string) {
  // Consent gate: never send marketing without a recorded opt-in.
  if (!(await hasMarketingConsent(email))) return;

  await emailClient.send({
    from: 'Acme <news@m.yourdomain.com>', // marketing subdomain
    to: email,
    subject: 'This month at Acme',
    text: `${body}\n\nUnsubscribe: ${unsubscribeUrl}`,
    headers: {
      // RFC 8058: both headers must be present for one-click to work.
      'List-Unsubscribe': `<${unsubscribeUrl}>, <mailto:unsubscribe@m.yourdomain.com?subject=unsubscribe>`,
      'List-Unsubscribe-Post': 'List-Unsubscribe=One-Click',
    },
  });
}

declare function hasMarketingConsent(email: string): Promise<boolean>;

// RFC 8058 one-click handler, a plain HTTP POST endpoint, no ESP SDK involved.
// The mailbox provider POSTs here directly; there is no human click and no
// confirmation page, so the unsubscribe must take effect on this request alone.
import type { IncomingMessage, ServerResponse } from 'node:http';

export async function handleOneClickUnsubscribe(req: IncomingMessage, res: ServerResponse) {
  // The provider sends application/x-www-form-urlencoded with
  // List-Unsubscribe=One-Click. The unsubscribe token comes from the URL.
  const url = new URL(req.url ?? '', 'https://m.yourdomain.com');
  const token = url.searchParams.get('token');

  if (req.method !== 'POST' || !token) {
    res.writeHead(400).end();
    return;
  }

  const subscriber = await resolveUnsubscribeToken(token); // opaque, signed, single-purpose
  if (subscriber) {
    await suppressMarketing(subscriber.email); // marketing scope ONLY, never touch transactional
  }

  // Always 200 on a valid request, even if already unsubscribed (idempotent).
  res.writeHead(200).end();
}

declare function resolveUnsubscribeToken(token: string): Promise<{ email: string } | null>;
declare function suppressMarketing(email: string): Promise<void>;

The critical detail is the comment on suppressMarketing: the unsubscribe writes to the marketing suppression scope only. A user who unsubscribes from the newsletter must still receive their receipts and password resets. Conflating the two scopes is the single most common way teams accidentally break transactional delivery. See List Management for the suppression model and Webhooks & Events for processing the complaint and unsubscribe events that feed it.

What is the implementation checklist?

• Transactional and marketing run on separate subdomains
• SPF, DKIM, and DMARC are configured for each sending domain (start DMARC at p=none, then tighten)
• DKIM d= aligns to the matching subdomain; DMARC uses strict alignment (adkim=s; aspf=s)
• All three records verified with dig and a real test send before launch
• Transactional emails contain zero promotional content
• Marketing emails always include an unsubscribe link, a physical address, and RFC 8058 one-click headers
• One-click unsubscribe POST endpoint is implemented and idempotent
• Consent (with provenance: when, where, wording) is recorded before any marketing send
• Marketing suppression scope is fully separate from transactional sends
• Spam complaint rate is monitored per domain and kept below 0.3% (target below 0.1%)
• Delivery, bounce, and complaint webhooks are wired up for both streams
• No email is classified as transactional purely to skip consent

What are the most common mistakes to avoid?

• Tucking a promo banner or upsell into a receipt or password reset, then calling it transactional.
• Sending both streams from one domain, so a marketing complaint spike poisons your receipts.
• Treating abandoned-cart and "we miss you" emails as transactional to skip consent.
• Letting an unsubscribe from marketing also kill the user's transactional emails. Keep the preference scopes separate.
• Assuming the US opt-out rule is safe everywhere. It is not, and even in the US it hurts deliverability.
• Believing that routing a message through your "transactional API" makes it transactional. The classification is about content and purpose; filters and regulators read the message, not your code path.
• Buying a dedicated IP at low volume and failing to keep it warm, then wondering why deliverability dropped.
• Jumping DMARC straight to p=reject before reading aggregate reports, junking your own legitimate mail.
• Shipping marketing mail without the List-Unsubscribe-Post header, so Gmail/Yahoo/Microsoft do not recognize your one-click unsubscribe and start counting "Report spam" clicks instead.
• Sending to a Canadian audience on expired implied consent (an existing-business-relationship window that has lapsed) without re-collecting express consent.

What should I read next?

• Transactional Email Catalog: which transactional emails each app type needs, with content guidance
• Deliverability: SPF/DKIM/DMARC, reputation, and getting mail to the inbox
• List Management: suppression scopes, consent records, and keeping marketing and transactional preferences separate
• Transactional Email Design: best practices for writing and structuring transactional emails
• Email Capture: collecting and recording consent at signup
• Marketing Emails: best practices for consent, content, and frequency
• Compliance: legal requirements for each email type in detail
• Sending Reliability: IP pools, warming, and reputation mechanics
• Webhooks & Events: processing delivery, bounce, complaint, and unsubscribe events
• Index