Transactional and Marketing Email on One Domain: Where It Goes Wrong
Your password reset leaves the same domain as Friday’s newsletter. So does the invoice, the two-factor code and the shipping notification. To you these are different systems with different owners and different urgency. To a receiving mail server they are one sender with one reputation. Transactional and marketing email on one domain works until it stops working, and when it stops, the part you cannot afford to lose goes down first. A campaign with thin engagement drags the domain average down, and the reset email rides along. It works the other way too, in theory, but good transactional volume rarely lifts a bad campaign as much as people hope. Worth defining the categories precisely. Transactional mail is triggered by a user action and expected within minutes. Marketing mail is broadcast and, at best, tolerated. This is what we see from running our own sending fleet, not a checklist lifted from a vendor blog.
Why Filters Treat the Two Streams Differently
Receivers do not read your intent. They read behaviour, and the behaviour of the two streams diverges sharply.
Engagement is the first split. A password reset gets opened within minutes because someone is sitting there waiting for it. A newsletter often gets nothing at all, and inaction is data. Complaint rates are the second. Nobody marks an order confirmation as spam. An imported list will collect complaints on the first send, and complaints carry more weight than almost anything else. Since February 2024 the two largest providers put numbers on this: the Gmail and Yahoo requirements for bulk senders set a complaint threshold that a mixed domain crosses much faster than a separated one.
Volume shape matters too. Transactional traffic is steady and roughly predictable across the week. Marketing arrives in spikes, and a sudden spike from a quiet domain has the same signature as a compromised account. Big filters build a profile of your domain from all of this mixed together. Mix the streams and the profile blurs. And when a decision finally lands, it lands on the domain or the sending IP range, not on the individual message. Separation is containment.
The Failure Modes We Actually See
The symptoms repeat. You start recognising them after a few rounds:
- Reset emails start landing in spam a day or two after a campaign goes out.
- Delivery slows to one large provider only, while everything else stays normal.
- Greylisting that never resolves, so mail sits in the queue and retries forever.
- Bounce spikes from an old imported list dragging the whole domain down.
The classic case looks like this. Transactional mail ran clean for years. Somebody imported a list, sent to it once, and the queue backed up behind thousands of hard bounces. Those bounces counted against the same Return-Path as the invoices, because nobody had ever needed to separate them.
Recovery is slow. Removing the cause is necessary but not sufficient, since reputation decays gradually in both directions. Days to weeks is normal. We write up these patterns as we hit them, and most of them end up filed under everything about deliverability.
Tip: before you touch DNS, check whether the drop hits one provider or all of them. One provider means a filter-specific block. All of them means something structural. The answer changes the diagnosis entirely.
Subdomain Separation: How It Is Done Properly
The standard split uses three lanes. Root domain for person-to-person mail. One subdomain for transactional. Another for marketing. Subdomain reputation is partly inherited from the parent, so you limit the damage without becoming an unknown sender overnight.
Each subdomain needs its own records. Own SPF, own DKIM selector, and a Return-Path aligned to the host that actually sends. DMARC can stay at the organizational domain with relaxed alignment; strict alignment breaks the moment a subdomain diverges from the parent. PTR for the sending IP must resolve and match forward. A mismatch there is one of the cheapest reasons to get filtered.
- Choose the subdomains and decide which stream lives where.
- Publish SPF for each subdomain, listing only its own sending hosts.
- Generate a separate DKIM key pair and selector per subdomain.
- Set the Return-Path so bounces return to the sending host, not the root domain.
- Confirm forward and reverse DNS agree for every sending IP.
- Send the first message only after all of the above resolves publicly.
Once the records resolve, point each stream at the subdomain that belongs to it. If you are wiring the transactional side from your application, the first request over REST takes about ten minutes and confirms the whole path at once.
Warmup After a Split, and Why People Skip It
A fresh subdomain has no history. From the filter’s side it is a stranger that showed up sending bulk mail, which is exactly the profile it is built to distrust. Warmup fixes that. Slowly.
Start with your most engaged segment, the people who open reliably. Raise volume in steps. Watch deferrals per provider rather than a global delivery number, because a global average hides the single filter that is throttling you.
Transactional subdomains warm themselves almost for free, since the engagement is genuine and immediate. Marketing subdomains need patience and a schedule.
On our own fleet we keep separate IPs for separate streams, run warmup schedules per destination, and read deferral logs daily. That is the boring part of running our own email sending infrastructure, and it is most of the work. But let me be clear about what warmup does: it buys you a track record. It does not buy inbox placement for bad content, and nobody can promise you a way around spam filters.
Consent Is Part of the Infrastructure
The marketing stream sits under RODO and article 398 of the PKE. Consent is required in B2B too. A company address is not a loophole, and treating it as one is a decision you will have to defend later.
Transactional mail needs no marketing consent, which is exactly why dropping a promo block into an invoice creates a legal problem on top of a deliverability one. Add an offer to a transactional message and it becomes marketing in the eyes of both the regulator and the filter. And the filter will notice the change in content long before anyone files a complaint.
Keep consent records tied to the address and the timestamp. You will need them when handling complaints, and feedback loops with the large providers are easier to work with when you can answer who subscribed and when.
Tip: audit your transactional templates for promotional blocks before you audit your DNS. It is faster, and it is often the actual cause.
What to Fix First
Order matters more than completeness. Stop the bleeding first: pause the campaign that caused the drop. Then separate the streams onto their own subdomains. Then warm up. Only then optimize content and cadence.
Measure before and after per provider, never as an average. Averages hide the one filter that is blocking you, and that filter is usually the one holding most of your list.
Be honest about the limits. Some blocks require a delisting request and then a wait, and no configuration change shortcuts that queue. You fix the cause, you file the request, you wait.
Separation is unglamorous infrastructure work. It pays off on exactly one day, the day something goes wrong, which is the entire point of doing it beforehand. If you would rather run this on managed sending servers than build and maintain your own, that is what we do at MailCraft.
