Warm the Domain for 6 Weeks or the AI SDR Torches It in 9 Days

Nine days. That is how long it took to kill a domain a team stood up on a Monday and pointed an AI SDR at on a Wednesday. The domain was three weeks old, the sending tool was configured well, the copy passed a slop lint, and the list was clean. They still lost the domain, and they lost the company’s real mail with it, because they skipped the one step that has no dashboard and books no meetings. They never warmed the domain. On day one the AI SDR sent 40 messages, on day three it sent 300, by day six it was firing 800 from a domain that had never sent a single email before, and Gmail did what Gmail was built to do with a brand-new domain producing spammer-shaped volume overnight. By day nine, renewal notices and DocuSign links from that domain were bouncing.

Warmup is the prerequisite that decides whether every downstream investment pays off or lights itself on fire. You can pick the perfect signal, write copy a human would answer, and gate every send behind a person, and none of it matters if the mailbox provider has decided your domain is a stranger sending like a spammer. The AI SDR made this worse, not because the model is bad, but because volume is the one thing an autonomous tool produces effortlessly, and volume from a cold domain is the exact fingerprint providers hunt. So here is the part no vendor puts on the demo: what warmup actually builds, the ramp schedule that gets you there, the subdomain and DNS that keep the blast radius off your real mail, and why the warmup pools everyone sells are a fading trick.

A new domain starts at zero trust, and volume reads as guilt

Mailbox providers keep a reputation score on your sending domain and the IP behind it. A domain that has never sent mail has no history, so it sits at neutral, which in practice means suspicious. Every provider has watched the same pattern a thousand times: a domain registered last month suddenly sends thousands of messages a day to strangers who did not ask. That pattern is a spammer standing up throwaway infrastructure, and the filter is trained on it. When your AI SDR produces the same shape from a genuine domain, the filter cannot tell the difference, because at the network level there is no difference. Same age, same cold-start volume curve, same low engagement.

Warmup is the process of building that missing history on purpose, slowly, so the provider learns your domain sends mail people open and answer before it ever sends mail at scale. You start with a trickle, you generate real engagement, and you raise volume only as fast as the reputation you are earning can support. The point is to arrive at your target cold-outbound volume with a trust score that treats that volume as normal for you, instead of arriving on day three as an unknown domain doing a passable impression of a botnet.

Since February 2024 for Gmail and Yahoo, and May 2025 for Microsoft, any domain past 5,000 messages a day must pass SPF, DKIM, and DMARC with alignment, honor one-click unsubscribe, and hold spam complaints under 0.30 percent. That cap is live from your very first send. Warmup does not buy you an exemption. It buys you the engagement history that keeps you far under the cap once volume arrives, and it gives the provider a reason to place your mail in the inbox where recipients can engage in the first place. A cold domain that lands in spam gets no opens, no replies, no positive signal, so it can never climb. Warmup breaks that trap by earning placement before it needs it.

The ramp is a curve, not a switch

The single most common mistake is treating volume as a dial you turn to maximum on launch day. The ramp is a slow climb: start at roughly 10 to 20 sends per inbox per day, hold, raise the ceiling every few days as engagement stays healthy, and reach a sustained cold-outbound cap of 40 to 50 per inbox over about six weeks. The exact numbers matter less than the shape. The shape is a line that goes up gradually and never spikes.

Notice where the ceiling lands. Fifty per inbox per day is not a limitation you are working around; it is the sustainable rate for a warmed inbox on cold mail. You scale by adding inboxes and domains, not by pushing any single inbox past what its reputation supports. Ten inboxes at 40 a day is 400 sends from a pool that stays healthy. One inbox at 400 a day is a dead inbox by Friday. The AI SDR does not care which arrangement it runs; the provider cares about nothing else.

Put the schedule in a file so the ramp is a config the sending system reads, not a number a person remembers to raise. This is the artifact I hand to whoever owns the pool.

# ramp-schedule.yaml: per-inbox warmup and cold-send ceiling
domain: go.example.com          # send subdomain, never the root domain
inbox_defaults:
  warmup_days_min: 42           # ~6 weeks before an inbox carries full volume
  cold_ceiling_per_day: 50      # sustained cap after ramp completes
  daily_increase_pct: 30        # raise the ceiling this much, only if healthy

ramp:                           # sends per inbox per day, by week
  - { week: 1, cold_sends: 10 }
  - { week: 2, cold_sends: 20 }
  - { week: 3, cold_sends: 35 }
  - { week: 4, cold_sends: 45 }
  - { week: 5, cold_sends: 50 }
  - { week: 6, cold_sends: 50 }

pool:
  inboxes_per_domain: 3         # spread volume; rotate sends across the pool
  stagger_sends: true           # no bursts; drip across business hours

guardrails:                     # checked every morning against Postmaster
  pause_ramp_if:
    spam_complaint_rate_above: 0.001   # 0.10%, well under the 0.30% hard cap
    bounce_rate_above: 0.02            # 2%; a list or auth problem, not warmup
    reply_rate_below: 0.03             # engagement stalling, hold volume
  on_pause: freeze_at_current_ceiling  # hold, never advance the ramp through trouble

The pause_ramp_if block is the part the autonomous tool never has. A warmup that only knows how to climb is not a warmup; it is a delayed blast. The guardrails hold the ramp in place the moment complaints rise or replies stall, because advancing volume through a reputation problem is how a slow domain becomes a dead one. You raise the ceiling only on a healthy morning, and a healthy morning is one Google Postmaster Tools confirms, not one the dashboard’s send count suggests.

Never send cold from the domain your invoices use

The scar at the top of this piece had a second cause. They sent from the root domain, the same example.com that carries payroll, contracts, and renewal notices. When the root domain’s reputation collapsed, every system that mailed from it collapsed too. Isolate the blast radius before you send anything. Cold outbound goes out from a dedicated send subdomain like go.example.com or mail.example.com, and your corporate mail stays on the root. If the send subdomain gets torched, your real mail keeps flowing, and you re-warm a subdomain without betting the company’s inbox on it.

Some teams go further and register a lookalike domain for cold, like example-hq.com, so the reputation is not even a subdomain of the primary. That is defensible when volume is high enough to torch subdomains faster than you can warm them, but it costs you the trust a recognizable brand name carries and it multiplies the DNS and warmup work. For most teams a send subdomain is the right balance: isolated reputation, shared brand recognition, one set of auth records to maintain.

Authentication is the entry ticket, and it lives in DNS on the send subdomain. Here are the three records, with the DMARC posture that changes as you warm.

; SPF: authorize your sending platform, hard-fail everything else
go.example.com.        TXT   "v=spf1 include:_spf.yoursendingtool.com -all"

; DKIM: the sending tool gives you the selector and public key
sel1._domainkey.go.example.com.  TXT  "v=DKIM1; k=rsa; p=MIGfMA0GCSq...QAB"

; DMARC: start at p=none to MONITOR alignment during warmup,
; move to p=quarantine once reports are clean (usually week 2-3)
_dmarc.go.example.com. TXT  "v=DMARC1; p=none; rua=mailto:[email protected]; adkim=s; aspf=s; pct=100"

Start DMARC at p=none so you can read the aggregate reports and confirm SPF and DKIM align before you enforce anything. Enforcing p=reject on day one, before you know your alignment is clean, bounces your own legitimate mail and looks like a reputation problem when it is a config problem. Once the rua reports come back clean, usually within a couple of weeks, tighten the send subdomain to p=quarantine. Keep the root domain at p=reject, because it is not sending cold and should refuse anything that fails.

The warmup pool is a fading trick, and Google knows the trick

Every warmup tool sells the same mechanism: a pool of thousands of inboxes that send each other mail, open it, reply to it, mark it important, and drag it out of spam. Your new inbox joins the pool, exchanges a few dozen of these messages a day, and accumulates a burst of positive engagement signals that tell the provider your domain sends wanted mail. Instantly, Smartlead, Warmup Inbox, and Mailreach all run a version of this, and for years it worked well enough to be table stakes.

The problem is that the engagement is synthetic, and Google’s 2024 sender guidelines explicitly discount artificial engagement. A pool of accounts that only ever mail each other in predictable patterns is itself a fingerprint, and providers have gotten good at spotting the closed-loop traffic that looks nothing like how real recipients behave. Google has publicly warned that its filters devalue warmup-pool engagement, and I have watched pooled-only warmups plateau at placement rates that never reach what genuine engagement produces. The pool builds a curve that looks like warmup and increasingly is not read as warmup.

That does not make pools useless. It makes them a supplement, not the strategy. The engagement that actually moves reputation is real: internal colleagues who reply to your ramp sends, a handful of friendly customers who answer a warmup message, and the early cold replies your first specific, low-volume sends earn. The pool can fill the gap in week one when you have no real traffic yet, but the plan has to hand off to real engagement fast, because that is the only signal that keeps compounding. A warmup that stays pooled at week six is a warmup that stalled and does not know it.

The gap between those two columns is the difference between an AI SDR that compounds and one that detonates. And placement is the number that shows it. A cold blast from a new domain lands most of its mail in spam from the first week, and once it is in spam it earns no engagement and can never recover. A warmed subdomain arrives at full volume already trusted.

Warmup as a system you operate, not a setup you finish

The reason warmup fails even when teams do it is that they treat it as a one-time setup step instead of a running system with its own metrics and its own kill switch. Warmup has an operating cadence, and it is short: check the health numbers every morning, advance the ramp only on healthy mornings, and stop the moment a guardrail trips. Build it in this order.

Warmup is the least glamorous line item in an AI outbound build and the one that decides whether every other line item survives contact with a mailbox provider. The signal work, the constrained drafting, the human gate, all of it assumes a domain that can reach the inbox, and a cold domain cannot. Point the volume machine at a subdomain you warmed for six weeks and it compounds, because every send lands where a human can answer it. Point it at a fresh root domain and it produces the exact fingerprint the filter was built to kill, and it does it fast. The domain in the scar at the top took nine days. The ramp that would have saved it takes six weeks and a YAML file. Build the ramp before you build anything that sends.