Cold email infrastructure: domains, DNS, and warmup before you send

WORKSHOP

Workshop 19: Cold email infrastructure: domains, DNS, and warmup before you send

Cold email warmup takes 14 days minimum and 21 to do it properly, and it cannot be rushed. That makes infrastructure the most common reason a launch slips: the domains and mailboxes get ordered the same week the campaign was meant to go out.

Getting it wrong costs more than time. Send cold from your main domain and you put the company's real email reputation on the line. Miss one DNS record and replies disappear, or every message lands in spam, and nothing tells you. A burned domain does not come back quickly, and no amount of good copy makes up for it.

This prompt walks you through building the stack properly before a single cold email goes out.

What it does

It works step by step, like a colleague who has set up sending stacks before. It asks how many cold emails a day you need, sizes the domains and mailboxes from that, helps you name and buy the domains, then walks you through each DNS record, mailbox setup, and the warmup schedule. It waits for your answer at every step.

It advises on names, providers, and budget and leaves those calls to you. On deliverability it is firm: if you want to break a rule, it tells you plainly what that costs.

At the end you get a plain-text stack sheet: every domain with a pass or fail for MX, SPF, DKIM, DMARC, and the redirect, the warmup start date, the earliest safe send date, and anything still failing.

What it catches

  • Planning volume on too few mailboxes. The ceiling is 25 cold sends per mailbox per day, on two to three mailboxes per domain. For 300 a day that is 12 mailboxes on four domains, not four mailboxes at 75 each, which burns all four.

  • A missing MX record. Outbound still works, so nobody notices, and every reply is lost.

  • Two SPF records on one domain. A second record makes SPF fail entirely. It also flags +all, which authorizes the whole internet to send as you.

  • Starting DMARC at reject. One gap and every message vanishes. It starts you at p=none with reporting and tightens later.

  • Sending volume above the safe line. Warmup keeps running forever, and warmup plus cold stays under 50 a day per mailbox.

  • Trusting a stored authentication check. On one platform the stored verdict was nearly eight weeks old and only covered domains with a mailbox connected to it, so it reported on the primary domain and none of the sending domains.

  • Spending your data budget on mailboxes. If mailboxes and contact data draw on one credit pool, a few mailboxes can use most of a month's data budget.

How to use it

There is more than one way in, depending on how you work.

  1. Paste it into any chat. Copy the prompt below into ChatGPT, Claude, or any other assistant and answer its questions.

  2. Add it to a Claude Project. Upload the prompt as a file. If you connect Apollo or your sending platform, it can check records and do the work itself, and it asks before anything that costs money. Setup: the Claude setup guide.

The prompt

Copy the whole prompt below, from the first line to the last.

You are helping me build a cold email sending stack before I send a single email: dedicated domains, mailboxes, DNS, and warmup, all separate from my primary domain. Work through the steps below with me one at a time. Ask, wait for my answer, then move on. Do not do everything in one reply.

If a domain registrar, mailbox provider, or sending platform is connected as a tool, do the work yourself. Buying domains and mailboxes costs real money and cannot be undone from a tool, so before any purchase tell me the count, the type, and the total cost, and get a yes. If you can look up DNS records, check them yourself instead of trusting that a record was set. If nothing is connected, tell me exactly what to buy, set, and check, and I will bring the results back.

You advise and I decide on names, providers, and budget. Deliverability is the exception. The rules below protect domains that do not come back quickly once burned, so be firm about them: if I want to break one, tell me plainly what it costs before doing what I ask.

Two rules drive every choice. - Never send cold from the primary domain. It has one reputation, and it is the company's real one. Cold goes out on dedicated domains that can absorb the risk. If one degrades, you retire it, not the business's email. - Build it three weeks before you need it. Warmup takes 14 days minimum, 21 optimal, and it cannot be rushed. The most common reason a launch slips is infrastructure ordered the week it was needed.

Step 1. Size the stack. Ask how many cold emails a day I need, then work backwards. - Ceiling per mailbox: 25 cold sends a day. Never plan above it. - 2 to 3 mailboxes per domain. More concentrates risk on one domain.

- Mailboxes = daily sends divided by 25. Domains = mailboxes divided by three, rounded up. For 300 a day: 12 mailboxes on four domains.

- Volume comes from more mailboxes, never a higher rate per mailbox. Solving 300 a day with four mailboxes at 75 each burns all four. - Add a backup pool of warmed spare mailboxes. A few extra is enough for an in-house team; a large program or an agency running many clients should run closer to double. When one degrades you swap it in instead of stopping.


Step 2. Get the sending domains. Propose names that are clearly the same brand, so the redirect and the from-name read as legitimate: getbrand.com, trybrand.com, brandhq.com. Keep them close to the real name. Avoid spammy variants and unusual endings, which hurt deliverability on sight.

Then help me pick a path. Buying at a registrar and setting DNS myself gives the most control at the lowest cost, with more setup work. Buying pre-provisioned domains and mailboxes from a provider is faster, with less control and a monthly cost. The requirements in steps 3 to 5 are the same either way; provisioned only means someone else does step 3, and my job becomes verifying it.

If I buy mailboxes through the same platform I use for contact data, and both draw on one credit budget, do the arithmetic before suggesting it. A few mailboxes can use most of a month's data budget, and I will run out mid-campaign.

Step 3. Set DNS on every sending domain. This decides inbox versus spam, and no copy makes up for getting it wrong. Walk me through each record with the values my provider gives me. - MX routes replies to the mailbox. Without it outbound still works, so nobody notices, and every reply is lost. - SPF lists which servers may send as the domain. Exactly one SPF record per domain: a second one makes SPF fail entirely, so merge includes into one. It must include the service I actually send through and end in ~all or -all. Never +all, which authorizes the whole internet. - DKIM signs every message so receivers can prove it came from me. Paste the provider's record exactly: one wrong character or a stray line break breaks the signature silently. Propagation can take a few hours. - DMARC tells receivers what to do with mail that fails SPF or DKIM, and where reputation is built. Start at p=none with a reporting address, which reports without blocking. Tighten to quarantine and later reject only after the reports are clean. Starting at reject means one gap makes every message vanish. A missing DMARC record increasingly sends mail straight to spam. - The redirect. Point each sending domain at the main website with a 301, at the host rather than in DNS, so a click lands on the real brand. A domain that resolves to an error page reads as fake.

Do not send until SPF, DKIM, and DMARC all pass.

Step 4. Create the mailboxes. Two to three per domain, named like real people (first@ or first.last@), never sales@, info@, or team@, which look like blast accounts and deliver like them. Set a real display name, a signature, and a photo where the provider allows it.

Step 5. Start warmup, which starts the clock. - 14 days minimum, 21 optimal, before any cold send. No exceptions. - 15 to 20 warmup emails a day per mailbox, weekdays. - Warmup never turns off. It runs alongside live campaigns forever.

- Cold sends then ramp on top: 5 to 10 a day in week one, reaching the 25 ceiling over 4 to 5 weeks.

- Warmup plus cold stays under 50 a day per mailbox, always.


A mailbox the provider still shows as pending setup is not ready. Do not count it in the stack or send from it until it is active.

Step 6. Verify from the outside. "I set the record" is not proof. Check every domain with a public DNS checker, or look it up yourself if you can. Be careful with an authentication verdict stored inside a sending platform. On one platform the stored check was nearly eight weeks old, and it only covered domains with a mailbox connected to that platform: on an account whose cold mailboxes lived elsewhere, it reported the primary domain and none of the sending domains. Read when a verdict was last checked, check again after any change, and never conclude every domain is healthy from a check that may not have looked at all of them. None of these checks cover blacklists or inbox placement.

What to hand me at the end: a plain-text stack sheet. For each sending domain: the name, its mailboxes and their status, and a pass or fail for MX, SPF (one record, right include, ~all or -all), DKIM, DMARC (at least p=none with reporting), and the redirect. Then the warmup start date and the earliest safe send date 14 days later (21 if I can wait), the planned daily cold volume against the 25-per-mailbox ceiling, the size of the backup pool, and anything still failing. Until everything passes and warmup has run 14 days, say plainly that nothing goes out.

Method adapted from the sending infrastructure skill in Apollo Operator, a free, open-source headless GTM toolkit by Creatop: github.com/creatop-gtm/apollo-operator

Part of the Apollo Operator prompt pack

This is one of 19 free prompts from Apollo Operator, the open-source headless GTM toolkit Creatop builds and runs on its own campaigns. Get the full pack here: the Apollo Operator prompt pack.

LATEST

FEATURED

Learn from our work

Logo

OUR NEWSLETTER

Notes from live campaigns. No theory, no filler.

PAGES

MORE

LEGAL

© 2026 Creatop. All rights reserved.

Learn from our work

Logo

OUR NEWSLETTER

Notes from live campaigns. No theory, no filler.

PAGES

MORE

LEGAL

© 2026 Creatop. All rights reserved.

Learn from our work

Logo

OUR NEWSLETTER

Notes from live campaigns. No theory, no filler.

PAGES

MORE

LEGAL

© 2026 Creatop. All rights reserved.