Transactional versus marketing email: the difference
Receipts and promotions differ in law, in deliverability and in how they should be sent. Why running both through one stream is a mistake.
· 5 min read
The line is the trigger, not the tone
A transactional email exists because one specific person did one specific thing and is expecting a response to it: an order receipt, a password reset, a shipping update, a booking confirmation, a payment failure notice. A marketing email exists because you decided to send it. That is the whole distinction, and it is about causation rather than about content or tone.
The test that resolves most arguments is to ask what would happen if the message were not sent. If a customer would be left waiting for something they initiated — wondering whether their payment went through, unable to log in — it is transactional. If nobody would notice its absence except you, it is marketing. A newsletter is marketing even when it is genuinely useful. A receipt is transactional even when it is dull.
This matters because almost every other decision downstream follows from the classification: which sending identity it uses, whether it carries an opt-out, whether a suppression list applies to it, and how much reputational risk it can be exposed to.
Why the distinction is technical, not just editorial
The two categories have opposite risk profiles. Transactional mail is low volume per recipient, expected, rarely complained about, and urgent — a password reset that arrives an hour late has failed. Marketing mail is high volume, unexpected by definition, occasionally complained about, and almost never time-critical to the recipient.
Sending both through the same identity means the reputational consequences of the second land on the first. A marketing campaign that draws complaints degrades the reputation of the domain and IP carrying it, and if password resets share that identity, they start arriving slowly or landing in spam. The customer affected is not the one who complained; it is the one trying to get back into their account.
The standard answer is separation: distinct subdomains for the two streams, so each accumulates its own reputation, and often distinct providers, since the requirements genuinely differ. Marketing platforms are built around lists, segments and scheduling. Transactional delivery is built around latency and per-message reliability.
The mixing mistake, and how ordinary it is
The usual way the separation collapses is small and well-intentioned: somebody adds a promotional block to the order confirmation, because it is the message with the highest readership in the business. A recommendation carousel, a discount on the next order, a newsletter signup.
That single addition changes what the message is. It now has a promotional purpose alongside its transactional one, which affects how it should be treated for consent and opt-out, and it invites a complaint on a message that previously never attracted any — on the stream you least want complaints against.
The second failure is the mirror image, and it is worse. If both streams share one suppression list, a customer who unsubscribes from your newsletter can stop receiving their own order confirmations. From the customer's side this looks like a broken shop: they paid, and nothing arrived. It is invisible to you unless you specifically test it, because the mail was suppressed as designed and no bounce or error was generated.
Unsubscribe: required for one, wrong for the other
Marketing mail needs a working, obvious opt-out, and for bulk senders to the major consumer providers that now includes one-click unsubscribe implemented in the message headers rather than only as a footer link.
Transactional mail is different, and the difference is not a loophole. A customer cannot meaningfully opt out of the receipt for a purchase they just made, or of a notice that their payment failed — those messages are part of the transaction. Putting a standard marketing unsubscribe footer on them is confusing at best and, if the link actually works against your transactional suppression, actively harmful.
The practical rule is that suppression scope follows the category. A marketing opt-out must suppress marketing and must not touch transactional. Where a genuine preference exists inside transactional mail — shipping updates by email versus by message, say — that belongs in account settings rather than in an unsubscribe link, because it is a delivery preference and not consent to be marketed to.
Where the obligation comes from in India
India has no email-specific statute of the kind the United States has in CAN-SPAM. The Telecom Regulatory Authority's unsolicited commercial communication framework, including the registers people use to block promotional contact, governs telephone calls and text messages rather than email. Businesses looking for the email rulebook in that framework do not find one, and sometimes conclude incorrectly that nothing applies.
What does apply is data protection. The Digital Personal Data Protection Act, 2023 frames the handling of personal data — including email addresses — around notice, consent and use limited to the purpose consented to. That is the layer under which 'they gave us their address for an invoice, so we added them to the newsletter' becomes a question worth answering rather than an obvious yes.
Separately, and with the most immediate day-to-day force, sit the mailbox providers' own sender requirements. These are not law and they are enforced faster than law: the penalty is filtering, applied automatically. Anyone mailing recipients outside India should also expect other regimes to apply to those recipients, which is a reason to keep consent records rather than to reconstruct them later.
Setting it up so the two stay separate
The configuration that keeps this straight is mostly done once. Use separate subdomains for the two streams and authenticate each properly, so SPF, DKIM and DMARC pass independently for both. Keep the sending paths separate, whether that is two providers or two clearly divided streams inside one.
Keep the suppression scopes separate, and test that separation deliberately: unsubscribe a test address from marketing, then place an order with it and confirm the receipt arrives. This is a five-minute check that catches the most damaging misconfiguration in the whole setup, and almost nobody runs it.
Monitor the two streams separately as well. Reputation dashboards report by domain, so if both streams share one domain you cannot tell which is causing a problem — the visibility is lost at the point you most need it.
Then keep transactional mail genuinely transactional. Its value is that people trust it and open it, and that trust is exactly what a promotional block spends.
Common questions
Can I put a small promotion in an order confirmation?
You can, and it changes the message's character — it acquires a promotional purpose, which affects how consent and opt-out should be handled, and it invites complaints on the stream where you can least afford them. If the shop genuinely depends on that placement, the safer form is a plain related-items list rather than an offer with its own call to action, and it should never be the reason a receipt is delayed or filtered.
Do I need two separate email providers?
Two separate sending identities matter more than two vendors. Many providers support both streams with distinct subdomains and distinct suppression scopes, which achieves the isolation that matters. Businesses often end up with two vendors anyway, because transactional delivery optimises for per-message latency and reliability while marketing platforms optimise for lists, segments and scheduling.
Is a shipping update transactional if I add a discount code to it?
It becomes a mixed message, which is the case worth avoiding. The shipping information is genuinely transactional and the code is not, so the message ends up with two different sets of expectations attached to it. Sending the update clean and the offer separately keeps both classifications honest and keeps the update trusted.
What about a password reset — does that ever need consent?
A password reset is triggered by the account holder's own request and is part of delivering the service they asked for, so it is not a marketing communication. The thing to protect is its reliability: keep it on a sending identity that never carries promotional volume, so its delivery does not depend on how last week's campaign performed.
Related pages