Cold email is a rate-limited distributed system with a reputation score attached to each sending identity. Mailbox providers act as the rate limiter and the scorer; the score is per-domain, earned slowly, lost quickly, and shared across everything that domain sends. The engineering constraints — warm-up as a ramp, roughly twenty-five sends per address per day, suppression as idempotency, bounces as a hard error class — follow from that and are not arbitrary vendor rules.
Cold email is usually explained in the language of persuasion, which is why it bounces off technical people. Described accurately, it is not a persuasion problem with some tooling attached. It is a rate-limited distributed system with a reputation score per sending identity, an adversarial filter on the receiving end, and a set of failure modes that are entirely legible if you have ever run anything in production.
Here it is in that language.
The system
You are a client. Mailbox providers — Gmail, Outlook and a long tail — are the servers. They are not obliged to accept your requests, they publish no complete specification of their acceptance criteria, and they maintain a score for every identity that talks to them. Your delivery is a function of that score.
The score attaches to the sending domain, not to the message and not to the account. It is earned slowly over weeks of behaviour and lost quickly, in days, on bad signals. Crucially it is shared: everything that domain sends draws on the same score.
That last property is the whole argument for separate sending domains, and it is a blast radius decision rather than a marketing one. Run cold volume on yourdomain.com and a bad month degrades your password resets, your support replies and your investor updates along with your outbound. You would not run an untested batch job against the production database for the same reason.
Warm-up is a ramp
A domain registered yesterday has no history. Two hundred messages from it today is indistinguishable, from the provider's side, from the thing providers exist to stop. There is no prior behaviour to argue otherwise.
Warm-up sends a small and increasing volume, with genuine replies, over roughly three weeks, so that a baseline exists before real traffic begins. You cannot compress it, because the artefact being produced is history, and history takes time by definition. Every tool promising immediate volume on a fresh domain is either pooling you onto shared infrastructure whose reputation you do not control, or quietly setting up a failure that surfaces in week four.
Rate limits, and how to scale
The working convention is about twenty-five messages per address per day at steady state. It is not a published limit. It is the rate that stays inside the heuristics at most providers while an identity is still establishing itself, which makes it a rate limit worth imposing on yourself in the absence of a documented one.
The scaling implication is the one people get wrong. You do not turn the rate up. You add addresses and shard across them — four hundred messages a month is about two addresses, two thousand is closer to three, each at its own steady rate. Horizontal, not vertical, for the same reason you would shard anything else that has a per-node ceiling.
| People per month | Addresses | Roughly |
|---|---|---|
| ~400 | 2 | $10 a month in addresses |
| ~1,600 | 3 | plus warm-up already completed |
| Any | more addresses | never a higher rate per address |
The error classes
Bounces are hard errors, and they damage the caller
A bounce is not a silent no-op. A high bounce rate on a young domain is one of the strongest negative signals available, because it is the clearest evidence of a list that was bought rather than built. This makes verification before send the exact equivalent of validating input at the boundary: cheap, unglamorous, and the difference between a recoverable error and an unrecoverable one.
Complaints are the hard ceiling
A spam complaint is a user telling the provider your identity is bad. The tolerance is very low — a fraction of a percent — and the recovery is slow. Anything that raises complaint rate is not a growth tactic with a downside; it is a request to have your sending privileges reduced.
Silence is not an error
Most messages get no response, and this is the expected case rather than a fault. Two to five percent reply is a good rate. Tuning against a two percent signal means you need volume before the numbers mean anything, which is the same reason you would not judge a latency change on ten requests.
Suppression is idempotency
The failure users actually notice and complain about is being contacted twice — once from one campaign and again from another, or after they already replied, or after they asked you to stop. Every one of those is a duplicate-delivery bug.
So the suppression list is not a compliance checkbox. It is the deduplication layer, and it needs to be global across campaigns rather than per-campaign, checked at send time rather than at list-build time, and permanent. An opt-out is a tombstone.
Follow-ups are backoff
One message is not a test of anything; most replies come from the second or third. But an unbounded retry against a non-responding endpoint is precisely what makes a sender abusive. The working pattern is a bounded retry with increasing intervals — three or four attempts spread over a couple of weeks, terminating immediately on any response including a negative one — which is exponential backoff with a cancellation signal, and you have implemented it before under that name.
Why this is worth automating rather than building
Reading that list, the instinct is reasonable: this is a tractable system and you could build it. You could. It is a few weeks of work, and then it is a thing you maintain — domain rotation, warm-up schedules, bounce handling, per-provider quirks, verification, suppression, and a research step per recipient that is the actual bottleneck and the part that does not reduce to code you can write once.
That research step is the reason this is worth handing over rather than building. Finding out what a specific company shipped last month and why it makes them a candidate is not a rate-limiting problem, and it is the only part that determines whether any of the infrastructure was worth running. Operater's Sales agent owns the whole pipeline — the domains, the ramp, the limits, the suppression, the backoff and the per-person research — and reports what it changed. It is a system you would recognise if you opened it, built by people who had to learn all of the above the expensive way.
Key takeaways
- Sender reputation behaves like a floating score per domain: earned over weeks, lost in days, and applied to everything that domain sends including your customer and investor mail.
- Warm-up is a ramp on an unknown-by-default system. Three weeks is the shape of the ramp, not a vendor's caution.
- Roughly twenty-five messages per address per day is the safe steady-state rate. Scaling means more addresses, not a higher rate per address.
- Bounces are a hard error class that damages the sender, not a silent no-op. Verification before send is the equivalent of validating input at the boundary.
- Suppression is idempotency. Contacting the same person twice through two campaigns is the failure users actually notice and report.