Skip to content
RRAECHLY

Deliverability · 6 min read

Never send cold email from your primary domain

The advice is common, the reasoning usually vague. Here is the specific mechanism, plus the MX trap that nearly took down our company email.

M

Mukesh Yadav

Founder, Raechly

· Updated 2026-08-10

Everyone repeats this rule. Fewer people explain what actually goes wrong, which is why it gets ignored by anyone who has not yet been burned.

Here is the mechanism, and then the specific trap that caught us.

Reputation attaches to the domain

Mailbox providers score senders. Part of that score follows the sending IP, and part of it follows the domain, and the domain half is the one that matters here because it is the part you cannot escape.

Change platforms and the IP reputation resets, because you are on someone else’s infrastructure now. The domain reputation does not reset. It is attached to the name, and the name is the thing your invoices, your password resets, your support replies and your contracts all travel under.

So when a cold campaign generates complaints on acme.com, the damage is not scoped to outbound. Your billing email now has a slightly worse chance of reaching the inbox. Your password resets start landing in spam for some recipients. Nobody reports this, because a password reset that goes to spam looks like a user who did not receive it, and you will spend a quarter blaming your transactional provider.

Recovery is slow and asymmetric. Reputation is built through months of consistent, engaged sending. It is destroyed in about a week by one bad list.

The volume mismatch

There is a second reason, less discussed and just as real.

Normal business email is low volume and high engagement. Dozens of messages a day, most opened, many replied to, almost never marked as spam. That profile is what tells a provider you are a legitimate correspondent.

Cold email is the inverse. High volume, low engagement, occasional complaints — that is the shape even when you are doing it well and your list is clean. It is inherent to messaging people who did not ask to hear from you.

Run both from one domain and you blend the profiles. The provider sees your entire domain as a moderate-volume sender with mediocre engagement, which is a worse position than either activity would occupy alone. You have made your real mail look worse without making your cold mail look better.

The MX trap

This is the part I had not internalised until it nearly cost us.

We had a warmup problem: replies to one of our sending addresses were bouncing, so warmup on that domain was not actually warming. Fixing it meant routing inbound mail for that domain through Cloudflare Email Routing so replies could be captured.

The domain was getbee.app, which is where our real company mail lives, on Google Workspace.

Enabling Email Routing on it would have replaced the MX records. Not augmented them. Replaced them. Every inbound message to every real mailbox on that domain would have stopped arriving at Google and started arriving at a routing rule built for warmup replies.

We would have taken down company email to fix a warmup metric.

The subdomain feature does not help either, in the way people assume it does. Enabling Email Routing on a subdomain still requires routing to be enabled on the apex, which hijacks the apex MX. There is no version of this that lets you bolt inbound capture onto a domain already serving Google Workspace or Microsoft 365 without touching what is already there.

The correct answer was not to find a clever workaround. It was to stop trying to warm from that domain at all.

What to do instead

Buy a dedicated domain for outbound. Not a subdomain of your primary. A separate registration, close enough to be recognisable — getacme.com, acme-mail.com, try-acme.com — and cheap enough that burning one is an operational annoyance rather than a disaster.

That last part is the real argument. A dedicated domain is disposable. If a campaign goes badly, you retire it and register another. Your company domain is not disposable, and treating it as though it might need to be is how you end up with an unusable one.

Give it its own everything. Its own SPF, its own DKIM, its own DMARC, its own MX pointing wherever your reply capture lives. No shared records with the primary domain, so nothing you do to one affects the other.

Warm it properly, from zero. A new domain has no history. Reputation belonged to the old domain and does not transfer, so a mailbox that was warm on your previous platform starts cold here. Ramp it, and make sure replies are genuinely being captured rather than reported.

Run several if you send at volume. Cold email scales by adding domains and mailboxes, not by sending more from each. Distributing volume across three domains at thirty a day is safer than one domain at ninety, and it means a single bad campaign takes out a third of your capacity rather than all of it.

The rule underneath the rule

Separate the mail your business depends on from the mail your business experiments with.

Cold outreach is an experiment. It involves lists of varying quality, copy you have not tested, and recipients who did not ask. Some of it will go badly. Design the setup so that when it does, the blast radius is a domain you can replace for the price of a coffee.

The trap is that everything works fine at first. A new domain sending carefully looks identical to your primary domain sending carefully, so the separation feels like unnecessary ceremony. It becomes obviously correct on exactly one day, and by then it is too late to introduce.


Related reading: sending reputation, reply capture, and why your warmup dashboard is probably lying to you.

Keep reading

Point your assistant at it and see.

Connect the MCP server, register a domain, publish the DNS records it hands you. You will know inside an hour whether this is the setup you want.