The conversation we have most often with the engineering team responsible for transactional email at our customers is the same one. They tell us that their receipts and password resets started landing in spam folders for some recipients, and they cannot work out why. The rest of the system has not changed. The volume has not changed. The senders, in their view, have done nothing different.
What has changed, almost without exception, is that someone in the same company stood up an outbound sales program on the same domain, and the outbound has been quietly damaging the shared reputation for months. By the time the transactional team notices, the damage has accumulated, and the recovery is going to take longer than the program was running.
We see this often enough that it has become the first thing we ask when an engineering team comes to us about a sudden deliverability problem on transactional. Have you launched outbound recently. About four times out of five, the answer is yes, and the program is being run by a sales operations person who does not know that the choice of sending domain matters. The infrastructure decisions that should have been made when the program launched were made by default, and the default was the company's primary domain.
The mechanism is straightforward. Receivers track reputation per sending domain and per IP. They do not distinguish between transactional and marketing traffic on the same domain. They average. The transactional engagement is excellent because the recipients asked for the receipts and reset their passwords. The outbound engagement is, in even the best programs, much lower because most cold outreach does not get opened. The averaged reputation drifts in the wrong direction, and the receivers respond by placing more of the company's mail in spam.
The fix is operational. The outbound goes on its own sending identity, separate from the transactional. A subdomain, a parallel domain, or a deliberately distinct sending domain are all reasonable choices. The transactional reputation no longer averages with the outbound reputation. The two streams can be tuned and operated independently. When the outbound has a bad week, the transactional is unaffected.
The decision to separate has implications beyond reputation. Authentication should be configured per sending identity. SPF and DKIM records, DMARC policies, and BIMI marks all live with the sending domain. The outbound team can be more aggressive with policy on the outbound domain than the company would dare to be on the transactional domain, because the consequences of getting it wrong are isolated.
The separation should also be enforced at the application layer. The transactional service should not be able to accidentally send from the outbound identity. The outbound tool should not be able to address the transactional sender. Both should fail safely if misconfigured rather than allowing the cross-contamination that produced the problem in the first place.
For engineering teams running into this for the first time, the easiest path forward is to engage the sales operations team in the conversation. The sales side of the company often does not know that their tool's default behavior is creating risk on the transactional side. The conversation is usually constructive once both sides understand what is at stake. The fix is bounded, the cost is small, and both teams end up with cleaner operating posture afterward.
The teams that have done this separation tend not to have the same conversation again. The outbound program continues, the transactional reputation stays healthy, and the deliverability incidents that used to consume engineering time become rare. The teams that have not done it are still in the cycle of fixing transactional issues that the outbound program will recreate next quarter.
The separation is not difficult. It is mostly a question of who in the company has the standing to insist that the program adopt the right pattern, and a small amount of unglamorous infrastructure work to set up the second identity. Both are achievable. The cost of skipping the conversation is paid in deliverability incidents that the engineering team will continue to take the blame for, even when the source of the problem is not in their part of the system.
This is a guest post from the team at Mailapult, who design and stand up B2B outbound programs with a deliverability-first posture. Mailapult helps sales teams run outbound programs that produce sustained pipeline without damaging the company's email reputation.