Transactional Email: The Class That Needs Its Own Domain

A transactional email is an automated message sent to one named recipient because of something that recipient just did: a password reset, an order confirmation, a receipt, a shipping notice, an account alert. Its defining property is that the person is expecting it, often watching for it, and its content is specific to them rather than promotional.

That expectation is what makes the class worth naming separately. Every other kind of business email competes for attention. Transactional mail has already been asked for, which changes what it needs from the infrastructure underneath it and changes what it costs when it fails.

The legal definition, and why it is narrower than people assume

Most teams use "transactional" as a loose label for anything triggered by software. The regulatory line is narrower and it is worth knowing, because it decides which messages need an opt out.

The FTC's CAN-SPAM guidance defines a commercial message as one "the primary purpose of which is the commercial advertisement or promotion of a commercial product or service", and states plainly that "The law makes no exception for business-to-business email". Against that, it describes a set of "five categories of" message it calls "transactional or relationship", and its instruction to senders is direct: before sending a message without an unsubscribe link, "be sure that the primary purpose of the message fits within one of the five categories".

The test is primary purpose, not trigger. A receipt with a product recommendation block bolted underneath it is a mixed message, and once the promotional content is the primary purpose it is a commercial message wearing a receipt's subject line. Teams reach that state by increments rather than by decision, which is why the label on the template usually stops being accurate long before anybody notices.

Google's published sender guidelines draw the same line from the other direction. Their one click unsubscribe requirement is scoped: "Marketing messages and subscribed messages must support one-click unsubscribe". Transactional mail sits outside that requirement, and it sits fully inside every other one on the page, including "Set up SPF or DKIM email authentication for your sending domains" and the instruction to "Keep spam rates reported in Postmaster Tools below 0.3%".

TransactionalThe recipient acted first

• Triggered by something that specific person did
• Expected, and often waited for
• Content is unique to the recipient
• Outside the one click unsubscribe requirement, inside every other sender rule
• Failure is a support ticket the same hour

MarketingThe recipient opted in

• Sent to a list of people who asked to hear from you
• Promotional primary purpose
• Requires a working opt out under CAN-SPAM
• One click unsubscribe required above provider thresholds
• Failure is a slow decline in engagement

Cold outboundNo prior relationship

• Sent to a person who has not heard from you
• Commercial primary purpose, so an opt out is required
• Complaint rate is the governing risk
• Judged on the sending domain's reputation from a standing start
• Failure is reputation damage that outlives the campaign

Why the three never share a domain or an IP

This is the part a generalist definition leaves out, and it is the part that costs money.

Reputation at a mailbox provider attaches to a sending identity: the domain, and where a dedicated address is in play, the IP. Everything sent under that identity contributes to it. A programme that sends password resets, a monthly newsletter and a cold campaign from one domain has pooled three very different complaint profiles into one score, and the score is set by the worst of them.

The asymmetry decides the architecture. Cold outbound generates complaints at a rate no transactional stream ever will, because it reaches people who did not ask. Marketing sits in between. Transactional mail generates almost none, and it is the stream where a delivery failure is felt immediately, because the person is refreshing their inbox waiting for the link. Putting the highest complaint class and the least tolerant class on one identity means the least tolerant one absorbs damage it did nothing to cause.

The failure mode is specific and it is quiet. Nothing bounces. The password reset simply lands in a spam folder for a subset of recipients, support tickets rise, and the connection back to last month's cold campaign is invisible from every dashboard the sending team looks at. By the time somebody makes it, the reputation has been building for weeks and it recovers over weeks more.

1. Step 1One identity

   Transactional, marketing and cold mail all leave under the same domain, and often the same address.

2. Step 2Complaints accrue

   The cold stream draws complaints at a rate the other two never generate.

3. Step 3The score moves

   The provider scores the identity, not the campaign, so every stream inherits the result.

4. Step 4The wrong mail suffers

   Password resets and receipts start landing in spam for a subset of recipients.

5. Step 5Nobody connects it

   Nothing bounced and no campaign report shows it, so the cause is found weeks later.

The separation is cheap to build and expensive to retrofit. A sending domain per class, authenticated on its own records, is a provisioning decision made once. Merging them and then splitting them later means starting a new domain from a standing start while the old one carries a history you cannot delete, and warming a domain is measured in weeks rather than days.

What transactional mail needs that the other classes do not

Speed, and a route that does not queue behind a campaign. A receipt that arrives in four hours has failed even though it was delivered. Transactional streams normally go through an SMTP relay or an API rather than through a mailbox, precisely so that a large marketing send cannot put them in a queue behind it.

A relay whose terms permit what you are sending. This is the clause that catches teams moving in the other direction. Many transactional relay services permit only mail the recipient asked for and prohibit unsolicited commercial email in their acceptable use policy, which makes them the correct home for receipts and the wrong home for cold outbound. Reading the acceptable use policy before the pricing page is the cheaper order.

A volume that can justify a dedicated address. A dedicated IP only earns its place above a volume floor, because reputation on an address with sparse traffic is built from too little evidence to be stable. Transactional streams at real volume are usually the best candidate in a business for one, and a low volume cold programme is usually the worst.

Plain, readable formatting. Transactional mail is read for its content rather than its design, and the plain text end of the spectrum carries less that can break in an unusual client. A receipt that renders as a blank rectangle on a phone is a support ticket regardless of how the campaign version looks.

How this decides things in an outbound programme

For a team running cold email, the transactional class matters mostly as the thing to keep away from. Three rules cover it.

The corporate domain is not the sending domain. The domain that carries invoices, password resets and staff mail is the one asset a cold programme must not put at risk, which is the whole argument for sending outbound from separate domains that carry nothing else. That is a containment decision rather than a deliverability trick.

A subdomain is weaker containment than it looks. A subdomain can publish its own authentication records and build a reputation that is at least partly its own, which makes it a reasonable boundary for transactional mail sitting under a corporate parent. It is a much weaker boundary for cold outbound, because the organizational domain is still visibly yours.

Suppression crosses all three classes. Somebody who opts out of your marketing has not opted out of their own password reset, and that is correct. Somebody who opts out of your cold outreach must not receive the marketing list either, and that is the direction teams get wrong when the two lists live in different tools. One suppression store consulted by every send is the only version of this that survives contact with a second platform.

Separating the three classes properly

• ✓Yes: Transactional mail leaves on a domain that carries no cold outbound
• ✓Yes: Cold outbound leaves on domains that carry no corporate or transactional mail
• ✓Yes: Each domain publishes its own SPF, DKIM and DMARC records
• ✓Yes: The relay's acceptable use policy permits the class of mail sent through it
• ✓Yes: One suppression store is consulted by every sending system
• ✓Yes: Any promotional block added to a receipt is reviewed against the primary purpose test
• ✕No: Sending cold campaigns through the transactional relay because it is already set up
• ✕No: Treating a subdomain of the corporate domain as containment for cold outbound

The review item in that list is the one worth scheduling rather than trusting. Promotional content arrives in transactional templates by increments, usually because a growth experiment needed a placement and the receipt had the highest open rate in the business. Each addition is small and the cumulative effect changes the message's primary purpose, which changes its legal obligations, and nobody re-reads the template after the change that crossed the line.

Related terms

SMTP relay is the delivery route most transactional mail takes, and dedicated IP is the address question that follows once volume is real. Sending domain covers the identity all three classes are judged on, and one click unsubscribe covers the opt out mechanism the marketing and subscribed classes are required to support.

For the infrastructure decisions underneath, SPF, DKIM and DMARC for cold email covers the authentication each domain needs, warming a domain covers what a new sending domain costs in time, and Gmail bulk email sending covers the architecture question of what to send through which system. If placement has already degraded on a shared identity, the spam rate benchmarks are where the damage first becomes visible.

The short version

A transactional email is an automated message triggered by one person's own action, carrying content they are expecting. The regulatory test is primary purpose rather than trigger, so a receipt with enough promotion attached becomes a commercial message with a commercial message's obligations.

Operationally the class exists to be kept separate. Transactional, marketing and cold mail generate complaints at rates that differ by orders of magnitude, mailbox providers score the identity rather than the campaign, and the stream least able to absorb damage is the one that suffers first. Separate domains cost nothing at provisioning time and cannot be added retroactively without paying for a new reputation.

RevenueFlow runs cold email and LinkedIn outreach for B2B teams on sending infrastructure that carries no corporate or transactional mail. See how the campaigns work.

Regulatory and platform requirements verified as of September 2026 against the FTC's CAN-SPAM guidance and Google's sender guidelines. Verify current obligations with counsel and with the source before relying on them.