Transactional email vs marketing email: the differences, and how to send each

A transactional email is a message sent to one person as the direct result of something that person did. A receipt after a payment. A password reset after a reset request. A shipping notice after a parcel moved. One recipient, one cause, and a message that is close to worthless an hour later.

That definition does the work, because every practical rule follows from it. Nobody has to opt in to a receipt: buying the thing is the request. There is nothing to unsubscribe from, because the mail is not a series. The timing is not yours to choose — it is decided by the event. And the volume is whatever your customers happen to do today.

Transactional mail is also the mail people notice when it is missing. A newsletter that arrives a day late is a newsletter. A password reset that arrives a day late is a support ticket, and probably a lost customer.

A marketing email — bulk mail, a campaign, a broadcast, a newsletter — is sent to many people because you decided to send it. The recipients are a list you built. The timing is yours. The content is promotional, or at least discretionary: an announcement, a digest, an offer.

Because you chose to send it, the burden shifts. The recipient has to have agreed to be on the list, they have to be able to get off it in one action, and the message has to say who you are and where you are. In the United States those last points are statutory: the FTC’s CAN-SPAM guidance requires a valid physical postal address and a working opt-out in commercial email. Elsewhere the consent rules are stricter still.

Most comparisons of transactional email vs marketing email stop at “one is triggered, one is scheduled”. The differences that actually change your code are further down.

Mailbox providers do not score your company. They score the domain and the address the mail came from, and they do it on the behaviour of the people who receive it: opens, replies, complaints, and how many messages went to addresses that do not exist.

That is the whole argument for separating the two. A campaign to a list that has gone stale will draw complaints — that is what stale lists do. If the campaign went out from acme.example and your password resets also go out from acme.example, the complaints are spent from the same balance, and the first thing you notice is resets landing in spam for people who never saw the campaign.

The fix is boring and effective: a subdomain each. Send transactional mail from something like mail.acme.example and bulk mail from send.acme.example. They are separate sending domains, so they are separately authenticated, separately signed, and separately scored. Google’s sender guidelines say the same thing in their own words, and add the requirements every bulk sender now has to meet: authenticate with SPF and DKIM, publish a DMARC record, keep complaints low, and support one-click unsubscribe.

Verify both domains in Rasket, publish the generated DKIM, SPF and DMARC records for each, and the split costs you one afternoon and nothing thereafter. The domains page walks through what each record does.

A transactional send is one call. The message names one recipient, and it carries an idempotency key derived from the event that caused it — the order, not a random string — so that a retry after a timeout replays the original response instead of sending a second receipt.

const { body: email } = await rasket.emails.send(  {    from: "Acme <billing@acme.example>",    to: ["ronald.williams@example.com"],    subject: "Your receipt for order 1042",    html: receiptHtml(order),  },  { idempotencyKey: `receipt-${order.id}` },);

Three things are deliberately absent. There is no list, because there is no list. There is no unsubscribe, because there is nothing to unsubscribe from. And there is no schedule, because the event already decided when this goes out.

What you do want is the id that comes back, stored against the order, so that when the customer says they never got the receipt you can answer with what actually happened to it rather than with a shrug. Delivery, bounce and complaint events arrive as signed webhooks against that same id.

A broadcast is three objects rather than one: the people, what they agreed to hear about, and the message. Contacts hold the addresses and their properties. A topic is a thing somebody subscribes to — “Product updates”, “Security bulletins” — so that unsubscribing from one does not silence all of them. A broadcast goes to a segment, under a topic.

const { body: topic } = await rasket.topics.create({  name: "Product updates",  description: "What shipped, once a month.",});
await rasket.contacts.create({  email: "ronald.williams@example.com",  first_name: "Ronald",  topic_ids: [topic.id],});
const { body: broadcast } = await rasket.broadcasts.create({  name: "September product update",  segment_id: segment.id,  topic_id: topic.id,  from: "Acme <news@send.acme.example>",  subject: "What shipped in September",  html: "<p>Hello {{{FIRST_NAME|there}}} …</p>",  send: true,});

List-Unsubscribe: <https://www.rasket.com/u/…>, <mailto:unsubscribe@…>
List-Unsubscribe-Post: List-Unsubscribe=One-Click

Keeping the two kinds of mail apart does not mean keeping them in two vendors. What it means is that one product has to offer two genuinely different paths — and a great many products offer one path and a checkbox.

• A single send that is idempotent, immediate and unsubscribe-free, for mail caused by an event.
• An audience — contacts, properties, segments, topics — and a broadcast that runs through the same delivery pipeline, with consent and one-click unsubscribe enforced on the way out.
• Separate domains, separate keys and one log, so you can answer “what happened to this message” the same way for both.

That is the shape Rasket is built in: an email API for developers that sends transactional mail and broadcasts, behind one key, with the two paths kept honestly separate. The email API page covers the first, broadcasts covers the second, and the glossary defines the words this post used without stopping to explain.