Transactional vs Marketing Email: Differences, Rules, and Infrastructure
Every product sends two fundamentally different kinds of email, and mixing up how you handle them causes both compliance problems and deliverability damage. Here's where the line actually sits.
The definitions that matter
Transactional email is triggered by a user's action and delivers information they expect: password resets, receipts, shipping notifications, magic links, security alerts, usage warnings. The recipient's signup for your product is the consent; delivery speed and reliability are the whole game.
Marketing email promotes: newsletters, product announcements, onboarding nurture, win-backs, promotions. It requires consent (opt-in), a working unsubscribe, and your physical address in most jurisdictions (CAN-SPAM in the US; stricter consent rules under GDPR/PECR in Europe and CASL in Canada).
The legal test in the US is primary purpose: a receipt that mentions a related product in the footer is still transactional; a promotion that happens to include your order number is marketing. When in doubt, classify as marketing — the compliance bar is higher, so it's the safe default.
Why the distinction is technical, not just legal
Mailbox providers treat the two differently because recipients do. Password resets get opened within seconds and never marked spam; newsletters get ignored and occasionally reported. That behavioral gap means:
Reputation must be isolated. If both types share a sending identity, one bad campaign raises complaint rates on the same domain your password resets use. The standard pattern is subdomain separation — acme.com (or txn.acme.com) for transactional, mail.acme.com for marketing — because providers score reputation per domain. MailBlastr gives every domain isolated reputation, and paid plans include 10 to 1,000 domains precisely so this pattern is free to implement.
Suppression must be shared — carefully. A hard bounce on either stream means the address is bad for both: one shared suppression list prevents re-mailing dead addresses from a different stream. But unsubscribes are stream-specific: unsubscribing from the newsletter must not block receipts. That's what per-topic unsubscribe (topics/preference centers) is for.
Unsubscribe rules differ. Marketing mail needs a visible unsubscribe and RFC 8058 one-click headers (required by Gmail and Yahoo for bulk senders). Transactional mail generally shouldn't be unsubscribable at all — imagine opting out of password resets — but recurring notification mail sits in between and deserves granular settings.
Speed expectations differ. A magic link that arrives in 90 seconds is broken; a newsletter that takes 10 minutes is fine. Transactional sends should skip batching queues and campaign pacing entirely — on MailBlastr, POST /emails is the fast path while campaigns run through their own scheduler.
One platform or two?
Teams often end up with Postmark (or SES) for transactional plus Mailchimp (or Brevo) for marketing. It works, but you pay for it operationally: two suppression lists to reconcile, two sets of webhooks, two dashboards during incidents, and contacts that exist in one system but not the other.
The alternative is one platform that does both with proper isolation. That's the architecture MailBlastr is built around — API sends and campaigns in every plan, per-domain reputation, one audience store, one webhook stream, one 30-day searchable log. The comparison against Mailchimp's split model shows the cost difference, and for teams currently stitching SES to a campaign tool, the Amazon SES comparison covers what you'd stop maintaining.
A checklist for running both correctly
- Separate sending identities (subdomains at minimum) per stream
- SPF/DKIM/DMARC on every identity
- Shared bounce/complaint suppression; per-topic unsubscribes
- One-click unsubscribe headers on all marketing mail
- No promotion in security-critical templates (keeps them cleanly transactional)
- Physical address + honest From: on marketing mail
- Alerting on bounce/complaint rates per stream, not blended
Get those seven right and each stream protects the other — receipts stay instant, newsletters stay out of spam, and neither drags the other down.
Frequently asked questions
What legally counts as a transactional email?
Mail whose primary purpose is to complete or confirm a transaction the recipient initiated, or to deliver information they're owed: receipts, shipping updates, password resets, security alerts, account notices. Under CAN-SPAM, primary purpose is the test — a receipt with a small cross-sell footer is usually fine; a promotion with a receipt attached is marketing.
Do transactional emails need an unsubscribe link?
Legally, generally no (they're exempt from CAN-SPAM's opt-out requirement when genuinely transactional). Practically, security-critical mail like password resets should never be unsubscribable, while nice-to-have notifications benefit from granular notification settings — users who can't reduce noise eventually mark it spam.
Should transactional and marketing email use different domains?
Different sending identities, yes — at minimum different subdomains (mail.acme.com for marketing, acme.com or txn.acme.com for transactional). Mailbox providers score reputation per domain, so a bad campaign can't take down your receipts. Whether those identities live on one platform or two is an operational choice, not a deliverability requirement.
Can one email service handle both types?
Yes, if it isolates reputation per domain and keeps one shared suppression list. That's MailBlastr's model: API sends and campaigns in every plan, per-domain isolation, shared suppressions. Some services handle only one side — Amazon SES and Postmark are transactional-focused; Mailchimp is marketing-first with transactional as a paid add-on.
Do Gmail's bulk sender rules apply to transactional email?
Authentication requirements (SPF, DKIM, DMARC) apply to everything you send. The one-click unsubscribe requirement targets commercial/promotional mail; a password reset doesn't need List-Unsubscribe, but your newsletter absolutely does.