Why Your Cold Email Never Arrived

An MSSP owner told me last year that cold email doesn't work. He'd run a campaign, sent about four thousand messages over six weeks, and got two replies, both negative.

His conclusion was that the market doesn't respond to outreach. The actual finding, once we looked, was that somewhere around the eight-hundredth message his domain's reputation collapsed and the remaining three thousand-odd got filed as spam on arrival. His open-rate reporting looked fine, because tracking pixels fire in some spam-filtering pipelines and not others, and because open tracking has been unreliable since Apple started pre-fetching images in 2021.

He hadn't tested a message. He'd tested a mail server.

That distinction is the most consequential thing in outbound and the one most often skipped, so here's the mechanism in full.

Deliverability is a reputation system

Mailbox providers don't evaluate your message. They evaluate you, and then decide how much attention to give the message.

The inputs are roughly: the sending domain's history, the sending IP's history, authentication (SPF, DKIM, DMARC), how recipients have engaged with your mail before, and the volume and shape of your sending pattern relative to what's normal for you.

That last one is what catches people. A brand-new domain that sends four hundred messages on its first day isn't behaving like a business. It's behaving like a spam operation, because in aggregate that's what spam operations do. The filter doesn't need to read the content to reach that conclusion, and it's right often enough that it won't change its mind for you.

Which is why warmup takes weeks

Warming a domain means establishing that it's a normal correspondent before asking it to do anything at volume. A small number of messages per mailbox per day, growing gradually, with real replies coming back.

You can't compress this. The thing you're establishing is a history, and a history is made of elapsed time. A four-week warmup done in four days isn't a fast warmup. It's no warmup plus a suspicious volume spike.

This is why any campaign build with an honest timeline has weeks of setup in it before the first real send. When a vendor offers to start sending next Tuesday, they're either using infrastructure that's already warm, which means it's shared, which means its reputation is the average of everyone else on it, or they're about to burn a domain on your behalf.

Never your production domain

If there's one operational rule in this article, it's this one.

Cold outreach should run on separate domains, usually close variants of your main one, with their own mailboxes. Your production domain, the one that sends invoices, incident notifications, contract documents and client correspondence, should never send a cold message.

The reason is asymmetry of consequence. If a cold-outreach domain picks up a bad reputation, you retire it and set up another. If your production domain picks up a bad reputation, your alerting emails to a client in the middle of an incident start landing in their junk folder. For an MSSP specifically, that isn't a marketing problem. It's a delivery-of-service problem with contractual consequences.

The three technical records, briefly

Worth stating because they're cheap, mandatory, and still frequently wrong:

SPF lists which servers may send for your domain. Publish it, and keep it within the DNS lookup limit. An SPF record that exceeds ten lookups fails, and failing SPF is worse than no SPF.
DKIM cryptographically signs outgoing mail so the receiver can verify it wasn't altered and did come from you.
DMARC tells receivers what to do when SPF or DKIM fails, and, the underused part, where to send reports. Start on p=none with reporting on, read the reports for a few weeks, then tighten.

None of this makes a bad message work. All of it is table stakes for a good one being seen.

Volume isn't the lever you think

There's a persistent belief that outbound is a numbers game, and that if a campaign is underperforming the fix is to send more.

At low volumes, per mailbox, that's roughly neutral. Past a certain point it actively inverts. Higher volume from a given domain increases the rate at which recipients mark mail as spam, which is the strongest negative signal in the system, which reduces the share of your mail that reaches an inbox at all, including mail to people who would have been interested.

The practical consequence is that a researched list of four hundred accounts, mailed carefully, beats an unresearched list of eight thousand, mailed enthusiastically. Not by a little.

What to check before you rewrite the copy

If a campaign isn't producing replies, run these in order, because they're ordered by how often they turn out to be the actual cause:

Are the messages arriving? Seed a handful of mailboxes across the major providers and look, manually, at where the mail lands. Not opens. The inbox.
Are the records right? Check SPF, DKIM and DMARC on the actual sending domain, not on your main one.
Was there a warmup, and how long? If the answer is less than two to three weeks, you don't yet have data about your messaging.
Is the list researched or bought? A bought list contains stale addresses and spam traps, and hitting either accelerates reputation damage.
Is the targeting right? Is the recipient someone who could say yes?
Then, finally, the copy.

Most people start at six. Six is where the interesting work is, so the instinct is understandable. It's also why the same campaign gets rewritten three times while the mail carries on not arriving.

The commercial version of this argument

If you're an MSSP working out whether to build outbound in-house, deliverability is the part that most reliably makes the honest cost higher than the estimate.

It's learnable. It's well documented. It's also the kind of thing where the tuition gets paid in domain reputation, and the bill arrives some weeks after the mistake, which makes the feedback loop slow enough that learning it properly takes a while.

Worth weighing against the alternative before deciding it's the cheap option.