Sending transactional and marketing email from one domain
Most teams end up with two email vendors, two sending identities and two reputations to watch. Consolidating is usually right, splitting by subdomain is sometimes right, and a few behaviours must differ either way.
The short version
- Reputation attaches largely to the domain in your DKIM d= value, so what shares a domain shares a fate.
- At low to moderate volume, one well-authenticated domain is simpler and performs fine.
- At higher volume, or if your marketing mail attracts complaints, move bulk to a subdomain and keep transactional on the cleaner one.
- Whatever you choose: unsubscribes must apply to marketing and must not block transactional.
- Never put marketing content in a transactional message. It reclassifies the message and takes its exemptions with it.
How the split usually happens
Nobody designs this. Engineering needs password resets to work, so they wire up an email API. Later someone wants to send a product update, and a marketing tool is the obvious thing for that, so it gets set up separately. Both work. Nothing looks wrong.
What you have acquired is two sending identities on the same brand, two reputations that mailbox providers score independently, two dashboards to check when a customer says an email never arrived, and two invoices for what is arguably one job. The cost is not obvious until the day the two interact.
What reputation actually attaches to
Mailbox providers score several identities at once: the sending IP, the domain in your DKIM d= value, and increasingly the brand as a whole. For most senders on shared provider infrastructure, the domain is the identity that matters most, because the IP is shared with other customers and the provider manages it.
That has a direct consequence. If your marketing campaigns and your password resets both sign as d=example.com, they share one reputation. A campaign that collects complaints degrades the deliverability of the mail your product depends on, and a password reset that lands in spam is a support ticket and possibly a lost customer.
The conservative response is subdomain separation: bulk mail signs as mail.example.com, transactional as notify.example.com or the root. Reputation is then tracked mostly separately, and a bad campaign is contained.
When to consolidate and when to split
| Your situation | What to do |
|---|---|
| Under a few tens of thousands of emails a month, permission-based list, complaint rate well under 0.1% | One domain. The operational simplicity is worth more than the marginal isolation |
| Growing volume, or campaigns to a list you did not build entirely yourself | Split: bulk on a subdomain, transactional on the root or its own subdomain |
| Any history of deliverability trouble on the marketing side | Split, and keep transactional as far from it as you can |
| Two vendors today, both working, low volume | Consolidating is still usually worth it for the single reputation and single allowance, but this is the least urgent case |
The thing worth avoiding in all four rows is the accidental version: two vendors, two reputations, nobody watching either, discovered when something breaks. Choosing one shape deliberately beats drifting into the other.
What must differ between the two kinds
Whether or not they share a domain, transactional and marketing mail have to behave differently in three specific ways.
- Unsubscribes apply to marketing and must not apply to transactional. Someone who left your newsletter still needs their password reset and their receipt. Suppressing those because of a marketing opt-out is a broken product, not compliance.
- Hard bounces and complaints apply to both. A dead address is dead whatever you send it, and continuing to mail it damages your reputation regardless of the message type.
- One-click unsubscribe headers go on marketing only. Putting RFC 8058 headers on a password reset invites someone to opt out of a message they need.
There is a fourth rule that is less about mechanics and more about not undermining yourself: do not put marketing content into transactional messages. A receipt with a promotion attached is, in most regulators' view and certainly in most recipients' view, a marketing message. It then needs an unsubscribe mechanism, and worse, it teaches people that your transactional mail is worth ignoring. The value of a receipt is that it is always relevant. Spend that carefully.
The operational argument for consolidating
The reputation argument cuts both ways, which is why the deciding factor for most small teams is operational rather than technical.
With one system, a customer saying "I never got the reset" is one search. Monthly volume is one number against one allowance rather than two subscriptions sized independently and both slightly wrong. Domain authentication is done once. Bounce and complaint rates are one pair of gauges rather than two you have to remember to check separately. There is one place suppressions live, so an address that hard-bounced on a campaign is also refused for transactional, which is what you want and is easy to get wrong across two vendors.
That last point is the underrated one. Split across two systems, suppression lists diverge. The marketing tool knows an address bounced; the transactional service does not, and keeps trying. Every one of those attempts is a small deposit against your reputation.
How day3 handles it
Campaigns and transactional email both leave the same verified domain and draw on the same monthly allowance, so a month of 18,000 password resets and 2,000 launch notes is a 20,000-email month on one bill. POST /v1/emails takes an Idempotency-Key so a network retry can never double-send a reset, even when the retry races the original request.
The behavioural differences above are built in rather than left to you: unsubscribes are ignored for transactional and enforced for campaigns, hard bounces and complaints are refused for both from one shared suppression list, and one-click unsubscribe headers are added to campaigns only. If you would rather split by subdomain, verify the subdomain as its own sending domain and use it for campaigns.
Questions
- Should I use a separate subdomain for marketing email?
- At higher volume or if your campaigns attract complaints, yes: put bulk mail on a subdomain and keep transactional on a cleaner one, so a bad campaign does not degrade your password resets. Under a few tens of thousands of emails a month with a permission-based list, one well-authenticated domain is simpler and performs fine.
- Can transactional and marketing email share a sending domain?
- Yes, and for small teams it is usually the better trade: one reputation to keep clean, one suppression list, one allowance, one place to look when an email does not arrive. The risk is that complaints on campaigns affect transactional deliverability, which is what subdomain separation mitigates.
- Do unsubscribes apply to transactional email?
- They should not. Someone who unsubscribed from your newsletter still needs their password reset and receipts, so a marketing opt-out must not suppress transactional mail. Hard bounces and spam complaints do apply to both, because those addresses damage your reputation whatever you send.
- Can I put a promotion in a receipt?
- Better not to. Adding marketing content to a transactional message tends to reclassify it as marketing, which brings unsubscribe obligations with it, and it trains recipients to treat your transactional mail as ignorable. The value of a receipt is that it is always relevant.
- What is the risk of using two separate email vendors?
- Two reputations scored independently, two dashboards, two allowances, and most importantly two suppression lists that drift apart. When the transactional service does not know an address hard-bounced on a campaign, it keeps mailing it, and every attempt costs you reputation.