🧙‍♂️ Your domain architecture is part of your product infrastructure

Every week I pick a topic, break down a problem, and send it to you. This week I continue the series of series on what AI startups get wrong before launch.

A marketing email should never hurt the reputation of the email that sends your password reset.

When you put it that way, it seems obvious. Still, many startups ignore this. They set up one domain, connect an email service, and send everything through it: account notifications, product updates, onboarding emails, and the occasional promotion. At first, it works because the volume is low. But as marketing increases, engagement drops, complaints rise, and suddenly your password reset emails end up in spam along with unwanted newsletters. Two different types of emails share one reputation, and one can ruin the other.

Silent churn is costing you money. Merlin rewards your best readers with points, perks, and tiers. Apply for the beta at getmerlin.app

I previously set up the email system for a company which made that decision right from the beginning. The primary domain was used exclusively for communication between people and never had any automated emails at all. One of the subdomains was used for transactional and lifecycle emails, such as those sent when an account is created, passwords are reset, and billing notices are issued. We also set aside a further subdomain for bulk marketing, kept it separate intentionally, and only began using it when it was necessary to do so.

This is usually what people mean when they talk about separating your domains:

The main point isn't having three domains, and you don't have to copy this arrangement exactly. I've also come across cases where a company has run a large campaign using the same subdomain as that for their normal customer notifications. When complaints increased as a result of the campaign, the notification emails began to fail to appear in inboxes, even though there had been no change on that side. Since the email providers didn't distinguish between the two, the entire domain was affected.

The reputational risks and business consequences associated with different emails are not the same. In the case of a password reset ending up in the spam folder, you receive a support request along with a frustrated user immediately. With a marketing email that ends up in the spam folder, all you see is a reduced open rate in your dashboard. Since the stakes are different, they should not lead to the same result.

If you consider it from this point of view, the true issue is not how many domains you require but rather which kinds of emails are able to share risks and which aren't. Transactional emails are very rarely able to do so, and product emails generally can't either, particularly in the case of customers who depend on them. Marketing emails, along with cold outreach and experiments, can take on more risk provided that they are not linked to something more important.

The primary reason for setting this up at an early stage isn't that it's complicated rather, it's that it's cheaper. If you delay action, you'll be forced to move the live traffic, re-authenticate the domains, and rebuild your sender reputation on the new systems, all while your product continues to depend on the old setup. When you do it early, all you need to make the change is a few hours' work involving just a DNS adjustment.

It is far easier to alter your email settings before you have a million messages depending on them.

You can find part1 here: Your email strategy should exist before your emails

Before You Go: Here's How I Can Help

— Pavel