Cold email infrastructure, and when not to build it

Cold email infrastructure is the sending stack underneath the sequencer. Domains, mailboxes, DNS authentication, and the ramp that takes a new mailbox from zero to its working volume. The sequencer is the part you shop for, and the infrastructure is the part that decides whether anything you send arrives.

The reason it gets sold as a product is that it is tedious rather than difficult, and buying it is a perfectly legitimate thing to do. Buying it without knowing what you bought is how teams end up paying a monthly fee for fifty mailboxes that send four emails a day each and still land in spam.

The three records, and what each one actually asserts

Authentication is not a spam filter: it is a set of claims about who is allowed to send as you, published in DNS so that a receiving server can check them, and if you get these wrong nothing downstream matters.

SPF publishes the list of servers permitted to send mail for your domain. It is a single TXT record, and it has a limit that catches people out: the record may trigger at most ten DNS lookups when it is evaluated. Chain four vendors together with include: and you will exceed it, at which point the check returns a permanent error and your mail is treated as unauthenticated. Every vendor you add spends part of that budget.

DKIM signs each message cryptographically and publishes the public key in DNS, so a receiver that verifies the signature knows both that the body was not altered in transit and that the signer holds the key. This is the record most sending tools generate for you.

DMARC is the one people skip and the one that now decides the outcome. It tells receivers what to do when SPF and DKIM fail, and it requires alignment: the domain that passed authentication has to match the domain in the visible From address. A message can pass SPF on a vendor's domain and still fail DMARC because the recipient sees your name in the From field, not theirs.

From February 2024 Google and Yahoo both made this mandatory for bulk senders rather than advisory, and the two of them draw the line differently: Google sets it at 5,000 messages a day to Gmail accounts, while Yahoo states no volume threshold at all and applies its requirements to bulk senders without defining a cutoff. Both want SPF, DKIM and DMARC, one-click unsubscribe, and a spam complaint rate kept under 0.3%. Yahoo also says its enforcement was gradually rolled out while it monitored compliance through the first half of that year, so what arrived in February was a tightening rather than a switch being thrown. The practical effect either way is that the optional half of this checklist stopped being optional.

Start DMARC at p=none, which publishes the policy and collects reports without asking anyone to reject your mail, so a misconfiguration costs you a report rather than a week of silence. Move to quarantine once the reports come back clean.

Why the sending domain is never your main domain

Domain reputation is earned slowly and lost quickly, and it does not separate itself by purpose. If cold outbound sends from the domain your invoices and password resets come from, a bad campaign degrades deliverability for mail your business cannot afford to lose.

So outbound runs on separate domains, and the usual shape is a small set of lookalike domains, registered to the same company, each carrying a handful of mailboxes.

Choice	What it protects	What it costs
Separate domain	Primary domain reputation is fully isolated	Recipients cannot verify you from the domain alone; needs a real site behind it
Subdomain of primary	Inherits some recognition, cheaper to stand up	Reputation is not fully isolated; damage can reach the parent
Primary domain	Maximum recognition and trust	One bad list and your invoices start going to spam

A separate domain needs to resolve to something: a recipient who checks, and a filter that checks on their behalf, should find a real page rather than a parked registrar placeholder. This is the step most often skipped, and it is the cheapest of the lot to get right.

Mailboxes and the ramp

A new mailbox has no sending history, and receivers treat sudden volume from an unknown sender as exactly the signal it is, so the first month goes on establishing a pattern rather than on running campaigns.

The ramp is unglamorous: start low, increase gradually, watch the bounce and complaint rates rather than the send count. The number that matters is not how many you sent, it is whether the replies and the complaints look like a human conversation.

Automated warming tools exist, and they send mail between accounts in a pool to manufacture engagement. Treat the output sceptically: they produce activity, and activity is a proxy for reputation rather than reputation itself, because the thing being imitated is a real reply from a real recipient.

How you know whether it is working

Delivered and inboxed are different numbers, and most sequencers report the first. A message accepted by the receiving server counts as delivered whether it landed in the inbox, the promotions tab or the spam folder. A 99% delivery rate alongside a 0.4% reply rate usually means the mail is arriving somewhere nobody looks.

Four numbers are worth watching, and only one of them is about volume.

• Hard bounce rate. Above roughly 3% and the list is the problem rather than the stack, which means verifying addresses before you send rather than discovering them afterwards.
• Complaint rate. The 0.3% ceiling is where enforcement begins, not where trouble begins, and Google says so itself: its guidance is to keep the rate below 0.10% and to avoid ever reaching 0.30%. So treat 0.1% as the point to stop and look, rather than the number you are allowed to run at.
• Reply rate, including the negative replies. A rise in "not interested" is a healthier signal than silence, because silence is the ambiguous case: it is what both a bad message and a filtered one produce.
• Placement, tested directly. Seed a handful of accounts across the providers your list actually uses and check where the mail lands. This is the only one of the four that distinguishes a filtering problem from a copy problem.

That last test is the one worth building a habit around. Without it, every disappointing campaign has two explanations and no way to choose between them, and teams reliably pick the one that implies buying more infrastructure.

When not to build it

This is the section no provider writes, because the honest answer costs them the sale.

Cold email infrastructure earns its cost when volume is the constraint. If you need to reach several thousand strangers a month and the limit is sending capacity, the stack pays for itself. Below that, it is machinery in search of a job.

If your total addressable list is under a few hundred accounts, do not build this. A market that small is worked by hand, one reason at a time. The reply rate from a researched, individually written email to fifty accounts will beat a warmed fleet of mailboxes firing at five thousand, and it will not put your domain at risk. I have watched teams stand up twenty mailboxes to contact a list they could have worked through in a fortnight with a spreadsheet and some patience.

If your problem is that the message does not work, infrastructure will not fix it. Deliverability determines whether a bad email arrives, and it has no opinion whatsoever on whether that email was worth reading. Teams reach for infrastructure when reply rates fall, and the diagnosis is usually wrong: the mail was arriving and being ignored.

If nobody owns it after setup, do not start. This is the one that bites quietly, because the stack is not a build, it is a standing obligation: domains renew, DNS drifts, a vendor changes its sending IPs, a policy tightens. An unmaintained sending stack degrades without announcing it, and the first sign is usually a quarter of missed pipeline that nobody thinks to attribute to DNS.

That last point is why this belongs with the rest of the plumbing rather than off to one side. An unowned sending stack fails the way every unowned system fails, which is quietly, and usually a few months after whoever set it up has moved on to something else. So the decision to build is really a decision about who is on the hook afterwards, which is the same question sitting underneath every other piece of the engine you build around your go-to-market.

The order to do it in

1. Register the sending domains and put a real page on each.
2. Publish SPF, DKIM and DMARC. Start DMARC at p=none and read the reports.
3. Create the mailboxes. Fewer than you think you need.
4. Ramp slowly. Watch bounces and complaints, not volume.
5. Send one campaign. Measure replies before adding capacity.
6. Write down who owns renewals and DNS. Put a date on it.

Steps one to four are an afternoon of work and a month of waiting. Step six is the one that determines whether any of it still functions next year.

Questions people ask