Ready to send better email?
Brew is the AI-native ESP. Define your brand once, ship on-brand email in minutes.
Brew is the AI-native ESP. Define your brand once, ship on-brand email in minutes.
What counts as transactional under CAN-SPAM, why carts and trial expiry usually do not, and how Brew's transaction object differs from a campaign.
A transactional email is mail the reader already asked for by doing something in your product. A receipt, a password reset, a shipping notice, a security alert. It isn't a newsletter with a receipt stuffed in the footer.
That distinction is legal, not aesthetic. It decides whether you need a promotional unsubscribe, whether Gmail will let you skip one-click unsubscribe, and whether a mailbox provider will treat the sending IP like a marketer.
CAN-SPAM does not care what your ESP calls the message. It cares about the primary purpose.
The FTC's implementation rule, 16 CFR 316.3, looks at the subject line and the body together. If either one is promotional on its face, treat the message as commercial. A "your order shipped" subject with a full-width sale underneath is still commercial. So is a password-reset body that spends most of its pixels on an upgrade.
Mixed messages are the usual failure. The FTC's own examples turn on balance. A shipping update that also sells is judged by what the reader is actually being asked to do.
| Trigger | Usually transactional? | Why |
|---|---|---|
| Order receipt, invoice, refund | Yes | Completes a transaction the user started |
| Password reset, magic link, 2FA | Yes | Account security they requested |
| Shipping or delivery update | Yes, if the body stays on the shipment | Fulfills the order |
| Confirm-your-email after signup | Usually yes | Confirms the address they just gave you |
| Security alert, new login or password change | Yes | Account notice, not a pitch |
Abandoned cart. Nobody completed a purchase. You are asking them to come back and buy. That is commercial. Klaviyo's own docs say the same. Cart mail is a campaign, not a transactional drop.
Trial expired, please upgrade. The trial ending is a product event. The mail is still a sales pitch. Primary purpose is commercial.
Digest of things you missed in-app. If the point is to pull them back into the product so they keep paying, it is marketing with a product-shaped subject.
If you are unsure, send it as promotional. Physical address, working unsubscribe, honest subject. The cost of being conservative is one extra line. The cost of being wrong is a spam complaint on the IP that also sends receipts.
Gmail's sender requirements require one-click unsubscribe on marketing mail once you pass the daily-recipient threshold. Transactional mail is out of that requirement. Gmail also publishes spam-rate ceilings for bulk senders. Keep spam reports under 0.1%, and never hit 0.3%, or you risk throttling and junk. Those figures are on the same page.
Yahoo's sender help tells high-volume senders to split marketing and transactional across different IPs, and preferably different domains. A cart campaign that shares an IP with password resets will land those resets in the same reputation bucket as the campaign.
One-click unsubscribe itself is RFC 8058. You need List-Unsubscribe plus List-Unsubscribe-Post: List-Unsubscribe=One-Click. That is a header contract. It is not a footer link that dumps someone on a preferences page with five checkboxes.
In Brew, a transactional email is a versioned object with an id like txn_.... You create the object first. Creating it does not send.
Live sends go through POST /v1/sends with transactionId, to, and an optional payload. The payload fills the variables in that version: order_id, reset_url, ship_date. Test sends can still use the Brew default address. Live sends need a verified domain you own. Analytics for these sends live under transactional, not campaign.
That split is the point. A receipt is an API call with a stable template. A launch campaign is a list, a schedule, and a story. Don't run both through the same send path and hope the inbox sorts it out.
If the reader would be confused that the message arrived, it is probably marketing. If they would be confused that it didn't, it is probably transactional.
When the body does both jobs, the law will pick the commercial one. Write two emails.
If an agent is the one composing the receipt, keep the send path on the transaction object. The inbox rules do not change because software hit send. That is the point of what still applies when an agent sends. For the rest of inbox placement, start with email deliverability. To contact us about this article, write Brew support.
A transactional email is a message the reader already asked for by doing something in your product. Receipts, password resets, shipping updates, and security alerts are the usual cases.
CAN-SPAM still applies. The primary-purpose test looks at the subject and the body. A shipping update that sells is commercial.
Usually no. Nobody finished the purchase. You are asking them to come back and buy. Treat it as promotional automation.
Create a versioned txn_... object first. Creating it does not send. Live sends go through POST /v1/sends with transactionId, to, and an optional payload. Live From addresses need a verified domain you own.
