Cold email infrastructure that does not burn your domain

Send cold outreach from your company's root domain and one bad batch can drag your invoices, password resets, and customer replies into the spam folder with it. That is the most expensive mistake in cold email, and most of the tooling built around the channel either quietly encourages it or swings to the opposite extreme: buy twenty burner domains, blast until they die, rotate, repeat.

We run our own mail infrastructure and write down what we enforce. This guide is the durable middle: a sending setup you build once, warm with real mail, and keep for years. Every number in it is either enforced in our own send path or carries a named source and a date.

What cold email infrastructure actually covers

Cold email infrastructure is everything between "I wrote a message" and "a stranger's inbox displayed it": the sending domain and its DNS, the mailboxes and relay that transmit, the warm-up schedule, the volume throttle, the suppression list, the inbound path that catches replies, and the monitoring that tells you when any of it breaks. If you are still deciding whether the channel fits your business at all, start with what cold email is and come back.

Copy is the part everyone optimizes because it is the part you can see. Infrastructure decides whether the copy is ever seen. A mediocre email that lands beats a brilliant one in spam, every time.

The market splits into two camps. One sells burn and churn: dozens of domains, dozens of mailboxes, engagement pods, rotate when deliverability dies. It can produce meetings, and we will not pretend otherwise; the tradeoff is that you are permanently buying domains, permanently warming, and permanently one enforcement change away from losing the whole apparatus. The other camp, the one this guide describes, treats the sending domain as an asset: fewer sends, better lists, a reputation that compounds. It scales slower. It also still works the week the pod networks get caught.

Never send from your root domain

The argument is blast radius. Your root domain sends invoices, password resets, contracts, and support replies. Cold outreach, mail to strangers who did not ask for it, is the riskiest sending you will ever do. Put both on one domain and your riskiest mail shares a single reputation with your most valuable mail.

The damage is not symmetric either. A separate sending domain costs about $10 a year and 3 to 4 weeks of warming to replace. A damaged root follows you: under Google's bulk-sender rules (February 2024, updated 2025), once your spam-complaint rate reaches 0.3%, Gmail withholds delivery mitigation until you have stayed under 0.3% for 7 consecutive days, and reputation recovery in general runs on weeks. All the while, every password reset your product sends is fighting the reputation your outreach earned.

One honest caveat, because it cuts against newsletter advice you may have read, including ours. For opted-in newsletters we recommend a subdomain of your root. For cold outreach we do not. A subdomain gives isolation, not a wall; sustained bad behavior rolls up to the parent domain's reputation. Opted-in mail on a subdomain is a reasonable risk. Strangers' spam buttons on a subdomain of the domain your business lives on is not a risk we would take.

So buy a separate domain. The usual patterns: get-yourbrand.com, yourbrand-hq.com, tryyourbrand.com. Redirect the bare domain to your real site so a suspicious prospect who types it in lands somewhere legitimate, publish real MX records because you must receive replies (much more on that below), and authenticate it fully before the first send. The complete walkthrough, registrar to first message, is in our cold email domain setup guide.

What domain reputation actually is

Warm-up services talk about reputation like a currency they can deposit. It behaves more like a credit history. Each mailbox provider keeps its own running assessment of your domain, built from what real recipients do with your mail: complaints, deletes without reading, replies, rescues out of the spam folder, plus your bounce rate, your authentication record, and how consistent your volume is. Google exposes a slice of its view through Postmaster Tools. Microsoft and Yahoo keep theirs mostly opaque. None of it transfers between domains, and none of it can be bought.

A new domain has no history, and providers treat no history as risk. That is the entire reason warm-up exists: reputation matures over roughly 4 to 8 weeks of consistent, well-received sending. The ramp we enforce in our own send path, adapted from Resend's documented domain-warming schedule, looks like this:

Two things about that table. First, it lives in code, not in a policy doc: our send path halts itself at a 0.3% complaint rate or a 2% bounce rate, with no human judgment in the loop. Second, those ceilings assume opted-in recipients. For cold outreach the shape holds but the numbers shrink, because engagement will be worse: start at 10 to 20 sends per mailbox per day, raise volume no more than 30% a day (10 to 20% is better), and never skip days. Consistency is itself a signal. A domain that sends 100 every weekday reads very differently from one that sends 700 every Friday.

The warm-up network problem

Warm-up networks put your mailbox in a pool of other members' mailboxes that automatically open each other's mail, reply with generated text, and drag messages out of spam folders. The pitch is that this simulates engagement. It does, roughly the way a treadmill simulates a commute.

The first problem is that the pattern is detectable, and the parties who would need to be fooled literally operate the mailboxes. Pod engagement forms a closed graph: the same cohort of addresses opening and replying to each other, on schedule, with templated content, and with no engagement from anyone outside the loop. Resend, a sending provider with every commercial incentive to make warming sound easy, put it flatly in a January 2026 post: Gmail and Outlook "can determine when engagement exists only inside a closed loop of artificially connected inboxes," and warm-up services "temporarily mask the absence of real engagement and often decrease reputation once the artificial signals end."

The second problem is arithmetic. The number that gets senders blocked, the spam-complaint rate, is computed from what real recipients do with your mail. Pod opens do not subtract complaints. If your list generates complaints above 0.3%, no volume of fake positivity changes that ratio. You have added noise on top of the number that matters and left the number alone.

So what does a pod actually buy you? A few weeks of engagement-shaped activity while the domain is new, a cliff when you switch it off, and poolmates whose behavior you do not control. Spend the ramp weeks on real one-to-one mail from the new domain instead: introductions, replies, scheduling, vendor threads, and the smallest, best-researched slice of your prospect list at trickle volume. Slower. Also the only engagement that is real.

Volume discipline: the real caps math

Start by unlearning the most repeated number in cold email. Google's bulk-sender rules define a bulk sender as anyone reaching 5,000 or more messages a day to Gmail accounts, and half the industry read that as a safe harbor: stay under 5,000 and the rules do not apply. That reading is wrong twice over. Authentication has been required of every sender since February 2024 and became a hard rejection in November 2025. Complaint rates are ratios, and ratios have no volume floor. The 5,000 line mainly decides when the formal checklist (a published DMARC policy, one-click unsubscribe) becomes mandatory, and you should be doing those things anyway. We follow the bulk-sender rules at dozens of sends a day, and we say so in print.

Small volume is more fragile, and this arithmetic is what should actually set your caps. The complaint target is under 0.1%: one complaint per thousand sends. The never-exceed line is 0.3%, the level at which Gmail withholds delivery mitigation until you are back under it for 7 straight days. Now run the division at cold-email scale. At 200 sends a day, one spam-button press is 0.5% for that day. Two complaints across a 500-send week is 0.4%. At small volume you do not get a complaint budget; you get a requirement that complaints be nearly nonexistent, which is why list quality and targeting set your safe volume long before copy does. The worked examples, per mailbox and per domain, are in how many cold emails per day.

Sequences multiply everything, and people forget to count them. A four-step sequence fed 100 new prospects a day settles at roughly 400 sends a day once the steps overlap. Your follow-up schedule is a volume commitment; plan for it up front rather than discovering it when a daily cap cuts step three mid-sequence.

Ignore per-account ceilings as targets, too. A Google Workspace account may send up to 2,000 messages a day (Google Workspace sending limits, checked August 2026). Treat that the way you treat a bridge's engineering tolerance rather than its speed limit: a cold mailbox anywhere near it is a complaint generator. Bursts carry their own penalty besides. A quiet domain that suddenly fires a Friday blast looks like a compromised account, because that is exactly what compromised accounts look like.

Authentication is a gate now

The era when unauthenticated mail merely scored worse ended in 2025. Microsoft began rejecting non-compliant bulk mail to outlook.com, hotmail.com, and live.com on May 5, 2025 with a 550 5.7.515 error. Gmail moved from spam-foldering to outright 550 rejection of unauthenticated mail in November 2025. On a new sending domain, all three records go in before the first message.

SPF authorizes your relay to send for the domain. One TXT record, exact value from your provider:

TXT   getyourbrand.com          "v=spf1 include:_spf.yourrelay.com ~all"

DKIM is a cryptographic signature your relay adds; the DNS record lets receivers verify it. The relay generates the key, you paste the record:

TXT   s1._domainkey.getyourbrand.com   "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3..."

DMARC ties them together and must align with your visible From domain. Start observing, not enforcing:

TXT   _dmarc.getyourbrand.com   "v=DMARC1; p=none; rua=mailto:dmarc-reports@getyourbrand.com"

DMARC is a progression, not a checkbox: publish p=none, read the aggregate reports for a few weeks, move to p=quarantine, and finish at p=reject once everything legitimate passes. Alignment is the detail that trips people up. SPF or DKIM has to pass for your From domain specifically, not merely for your relay's shared domain, which is how "SPF passed" and "DMARC failed" end up both true on the same message. Reverse DNS and TLS, the other entries on the compliance floor, belong to the relay's IPs; confirm once that your provider handles them and move on.

None of this is specific to outreach, and that is the point. The receiving side has no lenient mode for cold mail. The full compliance floor, with every threshold we hold our own sends to, is in the email deliverability handbook.

Suppression before every send

A suppression list is the set of addresses you will never mail again: hard bounces, spam complainants, unsubscribes, and, for cold email specifically, everyone who replied anything that means no. It is checked before every send. Not per campaign. Per send.

The rules we run: hard bounces are suppressed permanently the moment they occur; soft bounces retry about 3 times over 14 days, then convert to suppressions; complaints and opt-outs are immediate and irreversible. Keep your observed bounce rate under 2%, which in practice means verifying addresses before the first touch. An unverified scraped list will blow through 2% on day one and take the whole warming ramp down with it.

Two traps are specific to outreach operations. First, suppression must be global across the operation, because an opt-out attaches to you as a sender, not to whichever domain the mail happened to come from. Under CAN-SPAM, mailing a prospect from domain B after they opted out on domain A is the same violation with extra steps. Domain rotation does not reset anyone's no. Second, suppression must be automatic. We wired every delivery, bounce, and complaint event from our relay into a send_event table that triggers suppression on its own, because a human "I'll remove them later" workflow has latency measured in days, and the downstream stakes are absolute: Amazon SES pauses entire accounts at a 5% bounce or 0.1% complaint rate (AWS SES sending-review thresholds). We built auto-suppression before we were big enough to need it, precisely so that scale never depends on diligence.

Reply handling: the deliverability signal nobody manages

Mailbox providers weight engagement roughly as replies over clicks over opens, and opens barely mean anything now that Apple Mail Privacy Protection auto-fetches images and inflates them (we score our own sends on clicks and replies, never opens). A reply is the strongest positive signal a stranger can send about your mail. Which makes it strange that the standard cold stack treats inbound as an afterthought: sending domains with no real inbox, replies forwarded away through a registrar rule, interested prospects answered three days late.

There are two failure modes, one visible and one not. The visible one: nobody truly reads the outreach inbox, so "interested, call me Thursday" waits, "wrong person, try our VP of ops" never updates the list, and out-of-office autoresponders get logged as engagement by the sequencer. The invisible one we can quantify from our own incident. Email forwarding silently breaks DMARC. In June 2026 we were mirroring our production inbound into Gmail over SMTP forwarding and found Gmail rejecting 73% of the forwarded copies on DMARC grounds. No error surfaced anywhere on our side; the mail simply vanished. We rebuilt the mirror as a direct Gmail API insert and kept forwarding only as a last-resort fallback. If your outreach domain's replies ride a forwarding rule into your main inbox today, assume some fraction is not arriving, and that you cannot see which.

What we run instead, and recommend in any form you can get it: a real inbound path on the sending domain. A catch-all routes every address on the domain into one pipeline, the raw message is parsed once and stored as the source of truth, and replies go out from the same address with In-Reply-To and References headers so the thread stays intact in the prospect's mail client. Because inbound failures are silent by nature, we also monitor the path itself: every 2 hours a canary message round-trips the full production route (DNS, routing, worker, parser, database), and the owner gets an email if it fails. Silence means healthy. You do not need our exact stack. You do need each property: replies land somewhere real, threading works, a human answers interest the same day, and something notices when inbound breaks before a week of replies disappears.

Content that works with the infrastructure

Persuasion belongs to the subject line and template guides, but a handful of content decisions are really infrastructure decisions:

• Send multipart/alternative with a genuine plain-text part. For cold email, plain-looking text usually is the whole message, and should be.
• Keep links on your sending domain and skip link shorteners entirely. A bit.ly in a cold email is a filter heuristic you volunteered for.
• Hold a stable From identity: same display name, same address, across the entire sequence and every follow-up.
• No fake "Re:" or "Fwd:" subjects. Beyond being a filter signal, a deceptive subject line is a CAN-SPAM violation in its own right.
• Images are optional at best; if you use any, keep the message mostly text (60:40 or more) and give them alt text.

The compliance floor: CAN-SPAM and GDPR

In the United States, cold email is legal as an opt-out channel. CAN-SPAM requires accurate header and From information, a subject line that is not deceptive, identification of the message as an advertisement, a valid physical postal address in every message (a registered PO box or commercial mailbox qualifies, per the FTC's compliance guide), and a working opt-out honored within 10 business days and kept functional for at least 30 days after the send. The maximum civil penalty is $53,088 per email (FTC inflation adjustment effective January 17, 2025), and every recipient counts as a separate violation, which is how one sloppy 2,000-recipient campaign becomes nine figures of theoretical exposure. On top of the statute, mailbox providers require RFC 8058 one-click unsubscribe headers on bulk marketing mail; we stamp both required headers on every campaign send and honor opt-outs immediately, though the rule allows 2 days.

The EU is where tool marketing gets dishonest. GDPR does not flatly ban cold email: Article 6(1)(f) permits processing on legitimate interest, and Recital 47 names direct marketing as a possible one. But the lawful basis for holding the data is only half the question, because each country's ePrivacy rules govern the send itself, and they diverge hard. Germany requires prior consent even for B2B under UWG §7. The UK's PECR exempts corporate subscribers from its consent rule. Other member states land in between. A "GDPR-compliant" checkbox for cold outreach does not exist; what exists is a documented legitimate-interest assessment, disclosure of where you got the address, an effortless opt-out, targeting tied to the recipient's actual role, and a country check before you load the list. The fuller country-by-country picture is in is cold email legal. We are operators, not lawyers; treat all of this as practice notes rather than legal advice.

The build order

1. Buy a separate sending domain. Redirect the bare domain to your real site; publish MX records.
2. Publish SPF, DKIM, and DMARC at p=none before the first message leaves.
3. Create one to three mailboxes on it and connect your relay. Confirm reverse DNS and TLS are the relay's problem, solved.
4. Warm for 3 to 4 weeks with real one-to-one mail on a ramp: small, rising no more than 30% a day, no gaps, no pods.
5. Verify the list, then set sequence volume from the complaint math above, not from the tool's default slider.
6. Wire a global suppression list into the send path: bounces, opt-outs, complaints, and every reply that means no, across all domains you operate.
7. Put a real inbox on the sending domain. Thread replies correctly and answer interest the same day.
8. Add the CAN-SPAM footer (postal address plus opt-out) everywhere, and RFC 8058 headers on anything bulk.
9. Watch Postmaster Tools, your bounce and complaint rates against the 2% and 0.1%/0.3% lines, and the inbound path itself.
10. Hold volume steady. When any number spikes, pause first and diagnose second.

Most of that list is DNS records and discipline. The parts people skip, the suppression wiring and the real inbox on the sending domain, are the parts we built our product around; if you would rather run them than build them, see LetterDuck for cold outreach. Either way, build the infrastructure before you write the sequence. Domains are cheap to buy and expensive to burn.