Cold email
infrastructure that survives 2026.

Cold email reaches people who never asked to hear from you. That single fact changes everything downstream. A transactional password reset has an engaged recipient who is waiting for it; a newsletter has a subscriber who opted in. A cold message has neither, so it draws complaints at a rate that the other two categories almost never see. Spamhaus has been blunt about it, stating publicly that cold emailing as practiced today is spam. We do not agree with the framing for well-targeted, consent-adjacent B2B outreach, but we take the operational consequence seriously: cold mail routinely produces complaint rates of 0.5 to 1 percent, and the receivers now treat anything above 0.3 percent as grounds to stop delivering.

That complaint exposure is why a cold program cannot ride the same IPs as anything else you send. If your outreach IP picks up a spam-source listing, every message behind it suffers — and if that IP also carried your invoices or your product notifications, those die too. The architecture we build for cold separates it completely. The cold IPs never touch the bulk pool, never touch the transactional stream, and never touch your primary domain. Sending cold mail from a company's main domain burns that domain within about thirty days; we have watched it happen to senders who came to us after the fact, asking whether the reputation could be recovered. Often it cannot, and the domain has to be retired.

The economics follow from the architecture. To send a meaningful cold volume safely you need many low-volume sending identities rather than a few high-volume ones, because the receivers cap how much any single mailbox can send before the pattern looks automated. That means dozens of domains, dozens of IPs, dozens of mailboxes, each warmed independently, each monitored independently. Provisioning and warming that fleet, then defending its reputation week after week, is the work you are paying for. The €1,399 entry price buys 32 IPs across 32 domains with managed warmup running on all of them — not a bigger quota on a shared machine.

Gmail moved first and hardest. Through most of 2024 and early 2025 a message that failed authentication or came from a high-complaint sender got a temporary 4xx error — delivery was delayed, but the server could retry. Starting in November 2025 those became permanent 5xx rejections. The message bounces back with no retry, and the recipient never sees it. Google also retired the legacy Postmaster Tools in October 2025 and replaced it with Postmaster Tools v2, which reports a blunt binary Compliance Status rather than the older graded view. You either meet the bar or you do not.

Microsoft skipped the gentle phase entirely. Since 5 May 2025, any sender pushing more than 5,000 messages a day to Outlook or Hotmail addresses without correct SPF, DKIM and DMARC gets an immediate bounce carrying the error code 550 5.7.515 — not a spam-folder placement, a hard rejection at the door. Yahoo, for its part, rejects DKIM keys shorter than 1024 bits outright, so the older 512-bit setups that lingered in some stacks simply stop working.

The complaint threshold is the line that decides everything. A spam-complaint rate at or above 0.30 percent makes a domain ineligible for Gmail's delivery mitigation, and recovery is slow: the rate has to stay below 0.30 percent for seven straight days before the domain becomes eligible again. The practical target sits much tighter. By the time a program reaches 0.25 percent it is already in the danger zone, because the receivers throttle without warning. We run cold programs to a target below 0.10 percent complaints and below 2 percent bounces, which leaves headroom before any receiver reacts. Google has reported that its 2024 enforcement drove 265 billion fewer unauthenticated messages to Gmail users, a 65 percent reduction — the filter works, and it is not going to loosen.

Spamhaus treats a brand-new domain as inherently suspect, because spammers churn through fresh domains faster than anyone else. Its Combined Spam Sources list is reactive and IP-based — it lists individual addresses (a /32 for IPv4, a /64 for IPv6) the moment their sending behaviour looks like low-reputation mail. A single spamtrap hit during warmup can trigger a listing, and a new domain has no accumulated trust to absorb the blow. So the warmup has to be both slow and clean: slow enough that volume never spikes in a way that mimics a spammer, clean enough that the lists you send to never contain a trap.

The mechanics are unforgiving and specific. Each mailbox stays under roughly 50 sends a day, and that ceiling includes the warmup traffic itself — if the warmup engine is sending 25 reputation-building messages, only 25 slots remain for real outreach. You do not push a single mailbox harder; you add mailboxes, three to five per domain, which is why the fleet grows to dozens of identities. Volume ramps on a disciplined curve: roughly doubling early, then 1.5x in the 100-to-500-per-day band, then 1.25x above 500, with warmup traffic held at 15 to 40 percent of total volume throughout. A clean cold domain stabilises in four to eight weeks. Skip the warmup, or rush the curve, and the program is dead before it starts.

We run this as a managed service because the discipline is the product. Each provider — Gmail, Microsoft, Yahoo — builds reputation independently, so we segment the warmup by receiver and throttle them separately when one drifts. We watch the gating metrics daily through Postmaster Tools v2, Microsoft SNDS and the Spamhaus reputation checker, and we cut volume the moment a metric drifts toward a warning rather than after it crosses into a stop. The named engineer who runs your warmup is the same one who defends the reputation afterward, because warmup is not a one-time setup — it is the opening phase of a relationship with the receivers that never really ends.

A dedicated IP becomes worth its cost at around 100,000 sends a month, the point where you want full control of your own reputation rather than a share of a pool's. Below that, a shared pool spreads risk usefully; above it, the pool becomes a liability because someone else's behaviour can sink your placement. Cold email sits firmly in dedicated-IP territory from the first send, and we go one step further by pinning a single domain to each IP. The DKIM signing domain, the Return-Path, and the From domain each carry their own reputation, and isolating them one per IP means a problem on any single domain stays contained to that one address.

The Basic plan provisions 32 IPs across 32 domains. The Pro plan provisions 64 across 64. The ratio never changes — if you scale to a custom volume, the IP and domain counts grow together. This is what lets a program absorb the occasional bad campaign without cascading. If one domain picks up a complaint spike or a listing, you pause that single sending identity, diagnose it, and let the other thirty-one keep running while it recovers. A program built on a handful of shared IPs has no such firebreak: one bad day takes down everything at once.

All of it runs on EU infrastructure in our own jurisdiction, with SPF, DKIM and DMARC configured correctly before the first message leaves, and one-click unsubscribe under RFC 8058 wired into every campaign so recipients have an alternative to hitting the spam button. The cold IPs are physically and reputationally separate from every other product we run — they never share space with the bulk relay pool or the transactional stream, because the entire point is that cold risk stays sealed off from everything else you depend on.