One plan for transactional and marketing, two reputations

Transactional and marketing email can live in one API, on one plan, under one key, as long as they never share a reputation. That is the whole design, and the interesting part is not the slogan but the list of places where the line has to run, and the shorter list of places where it deliberately does not.

We have written about the commercial half already: why we do not charge for contacts, and why pricing marketing higher than transactional teaches customers to mislabel their campaigns. This post is the technical half.

What goes wrong when they share

Mailbox providers judge mail largely by the domain it comes from. A password reset, an invoice and a Friday newsletter sent from the same domain are scored as one sender.

The two kinds of mail behave nothing alike. Nobody marks their own password reset as spam. A newsletter to a list that has not heard from you in four months will collect complaints, some bounces and a lot of silence, and all of it lands on the domain. When the domain's standing drops, the provider does not filter the newsletter and spare the reset. It filters the domain. The people who feel it are the ones trying to log in.

So "our campaign went badly" becomes "our users cannot sign up", on a timescale of hours, and the fix takes weeks.

Where the line runs

Two identities per domain. Adding acme.com creates two sending identities in one call: mail.acme.com for transactional mail and news.acme.com for marketing. Each has its own DNS records, its own DKIM keys, and its own sending configuration. Reputation earned by one is not spent by the other.

Every message has a risk_class. It is transactional unless you say marketing, and the sending identity is resolved from it. A From on news.acme.com without risk_class: "marketing" does not quietly go out on the wrong side. It fails with 422 no_verified_identity, because there is no verified transactional identity by that name. Campaigns and automations only ever send as marketing; there is no field to change that.

Suppression has a scope. An unsubscribe writes a suppression with scope: "marketing". Someone who leaves your newsletter still gets their receipts and their password resets, which is what they asked for and what the law expects. A permanent bounce or a spam complaint writes scope: "all", because an address that does not exist, or a person who called your mail spam, should hear from neither side. Transient bounces write nothing at all.

Warm-up is per identity, and only for marketing. A new marketing identity is capped on a fourteen-day ramp from its first send, starting at 200 a day. The warm-up post has the incident behind that and the numbers. Transactional mail is never capped. A password reset cannot wait for tomorrow's step, and it does not need to: it rides a different subdomain with a different history, which is the reason the two were split in the first place.

Marketing carries what marketing must carry. Every marketing message gets a one-click List-Unsubscribe header and a footer with an unsubscribe link and the sender's postal address. A marketing send without a postal address on the workspace is refused with no_postal_address, because made optional it is the field nobody fills in. And a marketing message has exactly one recipient across to, cc and bcc, since its unsubscribe link belongs to one person. A transactional message carries none of this, because a receipt with an unsubscribe link is a receipt someone will try to unsubscribe from.

Tracking is per identity, on your own name. Click and open tracking are served from link.mail.acme.com and link.news.acme.com, one hostname for each identity, and never from a domain shared with other senders. A shared tracking domain carries every tenant's link reputation, which would rebuild across customers exactly the coupling the split removes inside one. An identity without an active tracking hostname sends its links unchanged and records no opens.

Where it does not run, on purpose

The meter. A campaign email and a password reset cost the same, on the same allowance. The moment marketing costs more, the cheapest thing a customer can do is send the newsletter as transactional, and that one relabel undoes everything above: the newsletter's complaints land on the reset's domain, and the unsubscribe link disappears. One price removes the reason to lie about the label, so the label stays true, and the label is what the reputations hang on.

The key. One API key can send both. What limits a key is its own guardrails (a daily cap, a recipient allowlist, an approval hold), not which kind of mail it sends. Splitting keys by risk class would add a credential to manage and protect nothing the identities do not already protect.

The contacts and the log. An audience is one list whether you mail it a receipt or a campaign, and the message log shows both in one place. "Why did this person not get their reset?" is often answered by a marketing event, such as a complaint two weeks ago, and that answer should not live in another product.

The account health gate. Before a campaign starts, SendRaven reads the workspace's permanent-bounce and complaint rates over the last fourteen days, across both identities, and once there are at least a thousand sends to judge, refuses the campaign if either is past a ceiling set short of the thresholds at which a sending account gets reviewed. This check is deliberately not per identity. Two domains protect you from mailbox providers judging your resets by your newsletter. They do nothing about the layer underneath, the sending infrastructure itself, where a bad enough campaign can pause everything a workspace sends. That is the one place transactional and marketing have to be judged together, and it is the one place a campaign is refused outright rather than paced.

What you do with it

Verify the domain once and publish both sets of records. Send receipts, resets and replies from mail.. Send campaigns, sequences and anything someone opted into from news., and mark one-off marketing sends with risk_class: "marketing". The rest is enforced where it cannot be forgotten: in the one function every send goes through.

If you are moving from two providers, one for each kind of mail, you already have the reputations split. What you give up is two bills, two sets of contacts, and the second place to look when someone says an email did not arrive. The details are on the deliverability page and in the sending docs.