A promotional send goes out on a Tuesday afternoon. Nothing unusual, a list you've mailed a hundred times before. By Thursday, a support ticket lands: a customer never got their password reset email. Then another one. Someone on the product team notices signup verification emails arriving late, some not arriving at all, and nobody can immediately say why, because nobody touched the authentication flow and marketing didn't do anything they haven't done a dozen times before.
This is the most common way we see companies discover, the hard way, that their transactional and marketing email have been sharing infrastructure they were never designed to share.
Why the two get lumped together in the first place
Inbox providers don't read your org chart. Gmail, Outlook and Yahoo have no idea that a password reset comes out of your application code and a product newsletter comes out of your marketing platform. What they see is a sending domain, a DKIM signing key, and often a sending IP, and they build a reputation against whichever of those is doing the identifying. If your marketing platform and your transactional email both send from mail.yourdomain.com using the same DKIM key, the two streams are, as far as any inbox provider is concerned, one sender.
That matters because the two streams behave nothing alike. Marketing mail goes out in bulk, to a list that always includes some people who've gone quiet, and it lives or dies on open rates, click rates and, most importantly here, complaint rates. A send to 40,000 people that irritates half a percent of them generates 200 spam complaints in an afternoon. Transactional mail is sent one at a time, triggered by something the recipient just did themselves: they signed up, they asked for a password reset, they made a purchase. Almost nobody marks a password reset they requested as spam. Complaint rates on genuinely transactional mail sit close to zero, almost by definition.
Put both streams on the same infrastructure and the marketing stream's complaint rate effectively becomes the whole domain's complaint rate. The transactional mail didn't do anything to earn that. It's just standing next to something that did.
There's a second layer to this worth knowing about if you're on a shared IP pool, which most companies below enterprise volume are. Dedicated IPs carry their own reputation, but a shared pool's reputation is already an average across every sender on it, which is mostly outside your control anyway. Domain and subdomain reputation is the lever you actually own, which is exactly why it's the one worth getting right, regardless of what your IP situation looks like.
How to tell if you've already got this problem
Before getting into the fix, it's worth checking whether this is actually costing you anything right now. Three quick things to look at:
- Open your DNS records and check whether your transactional email and your marketing platform are both authenticated under the exact same subdomain, or worse, the same root domain with no subdomain at all. If they are, they're sharing a reputation whether either team knows it or not.
- Check Google Postmaster Tools, if you have it set up. If you're sending what feels like two distinct types of mail but only see one identity listed, that's the same problem showing up from a different angle: everything is signing under one domain, so Google has no way to show you two separate pictures even if you wanted one.
- Unsubscribe a test account from your marketing mail, then trigger a password reset on that same account, and see what actually happens. More on why that specific test matters below.
The fix is architectural, not editorial
None of this gets solved by writing better subject lines or trimming a list, though both are worth doing on their own terms. It's solved by giving each stream its own identity in the eyes of the inbox provider, which in practice means separate subdomains.
A workable version looks something like this: transactional mail goes out from something like mail.yourdomain.com or txn.yourdomain.com, and marketing goes out from a different subdomain, commonly something like news.yourdomain.com or hello.yourdomain.com. Each one needs its own SPF include and its own DKIM selector and key pair. They can sit under the same root domain and the same DMARC policy without any conflict. DMARC does have a subdomain policy tag, sp=, that lets you set enforcement separately if you ever need to, though most senders end up running the same policy across both once everything is authenticated properly.
If your platform supports it, most of the major providers give you a proper way to do this rather than a workaround. SendGrid separates by subuser and IP pool. AWS SES ties distinct sending identities to configuration sets. Postmark is built transactional-only for exactly this reason, which is why a fair number of engineering teams run it purely for the transactional stream and send marketing from somewhere else entirely. Whatever you're on, the question to ask your platform is the same one: can this send two authenticated identities that genuinely don't share a reputation, or does everything default to going out under one domain regardless of what I tell it?
One practical thing worth planning for: a brand new subdomain has no sending history at all, which inbox providers treat with some caution at first. If your transactional volume is significant, don't flip every password reset and receipt over to the new subdomain in one go. Ramp it up over a week or two the same way you would with any new sending identity, so the new domain builds a track record before it's carrying your most time-sensitive mail.
For anyone sending meaningful volume into UK inboxes specifically, this is worth taking seriously beyond the general principle. Microsoft 365 is the default inbox for a large share of UK B2B, and Microsoft's own reputation tool, SNDS, reports at IP level rather than domain level. If your transactional mail shares an IP with a marketing stream that's had a rough week, Microsoft isn't distinguishing between the two when it decides whether your mail lands in someone's junk folder.
The detail that makes this worth doing properly, not just doing at all
Here's the part of this that tends to land hardest with engineering teams, because it isn't just about protecting the transactional stream. It's about being able to see it at all.
Google Postmaster Tools, the main window most senders have into how Gmail actually treats their mail, tracks reputation against the domain in your DKIM signature, the d= tag, not the domain in your From address. If your ESP signs outgoing mail under its own domain rather than yours, which some do by default on lower-tier plans, you have no Postmaster visibility into your own reputation whatsoever. You're sending mail into one of the largest inbox providers in the world and have no dashboard telling you how it's actually being received.
Separate your streams properly, with each one signing under a subdomain you control, and you get two genuinely distinct entries in Postmaster Tools: one tracking how Gmail sees your transactional mail, one tracking marketing. That's the difference between finding out about a reputation problem from a spike in support tickets several days after it started, and watching the spam rate creep upward on a dashboard before a single customer has noticed anything at all.
The suppression list mistake that isn't really a deliverability problem
There's a specific way this goes wrong that deserves calling out on its own, because it's less about inbox placement and more about a compliance and user experience problem hiding inside what looks like an infrastructure decision.
Some platforms apply a single global suppression list across every send type by default. A customer unsubscribes from your monthly product update, and because the suppression list isn't scoped to marketing specifically, they stop receiving password reset emails too. They never asked to stop receiving those, and now they can't recover their own account. Nothing bounced, nothing landed in spam, so it won't show up in any deliverability report you're likely to be checking. The underlying cause is identical either way: two streams that should never have shared infrastructure, sharing infrastructure.
This is exactly why the test from earlier is worth actually running rather than assuming the answer. Unsubscribe a test account from marketing, trigger a password reset, and check whether it arrives. If it doesn't, you have a real problem that a clean bill of health from any deliverability tool will completely miss.
Where this sits in the bigger picture
If you've read the earlier parts of this series, this post assumes the groundwork from Part 2 is already in place: SPF, DKIM and DMARC configured and properly aligned. Stream separation doesn't fix broken authentication. It makes sure that once authentication is right, one stream's sending patterns stop being able to determine the other's fate.
It also sets up the next piece properly. Once transactional and marketing mail have separate, monitorable identities, you can actually watch each one for the early signs of trouble rather than one combined signal that tells you something's wrong without saying which half of your programme is responsible.
None of this is a large engineering project. Standing up a second subdomain, generating a second DKIM key, and pointing your transactional sends at it is usually a matter of days, most of which is DNS propagation rather than actual work. What it buys you is out of proportion to the effort involved: a marketing send having a bad week stops being something that can take your password reset emails down with it.
If you want to check whether your own setup already has this problem, the free health check will tell you within a minute whether your transactional and marketing mail are currently sharing a signing domain. If the results raise more questions than they answer, book a free check-up: 15 minutes, no obligation, and we'll walk through exactly what's happening on your domain.
