How to set up a cold email domain (secondary domains + redirects)

A cold email domain is a short list of DNS records and two decisions. The records are MX, SPF, DKIM, DMARC and an address record with a redirect. The decisions are whether to use a separate registered domain or a subdomain, and how many mailboxes to put on each domain — the second of which is a rotation arithmetic problem with an answer, not a matter of taste. Almost every failed setup skips the MX record, and that omission is what makes bounces invisible for weeks.

Separate domain or subdomain — DMARC decides it for you

The usual framing is about reputation isolation, which nobody outside Google, Microsoft and Yahoo can measure. There is a second consideration that is fully documented and therefore worth deciding on.

Under DMARC, a subdomain is not an independent identity. RFC 9989, published in May 2026, replaced the Public Suffix List with a DNS tree walk: a receiver evaluating mail.acme.com queries _dmarc.mail.acme.com, and if there is no record there it climbs the label tree looking for one, up to a documented maximum of eight queries. Your subdomain therefore inherits your organisational domain's policy unless you publish a record on it, and the sp tag on the parent governs subdomains explicitly.

That has two consequences.

If you use a subdomain, your main domain's DMARC policy applies to your cold outreach. That is often the desired outcome — one policy, one place to change it — but it also means a p=reject on your organisational domain is enforced against every cold message, which is fine if alignment is correct and unforgiving if it is not. RFC 9989 also introduced np, a policy specifically for non-existent subdomains, so a parent domain that never uses subdomains can publish np=reject and lose nothing.

If you use a separate registered domain, nothing is inherited. No DMARC policy, no sp, no tree walk that reaches your main domain. You publish a complete set of records from scratch, and a failure on the sending domain has no documented path back to the domain your invoices and password resets come from. That separation is the point, and it is the reason most cold programmes buy a second domain rather than carving a subdomain.

Pick on that basis rather than on folklore about reputation partitioning, which is not something anyone outside the receivers can verify.

The records to publish on day zero, in order

For a fresh sending domain, publish in this sequence. Each one is verifiable before you move on.

1. MX. Point it at the mailbox provider that will host the sending accounts — Google Workspace, Microsoft 365, or whoever else. This comes first because everything below assumes the domain can receive mail.
2. An address record for the bare domain, so the name resolves in a browser, plus the redirect described below.
3. SPF. One TXT record on the bare domain, with the lookup count checked.
4. DKIM. Whatever selector and key your provider generates, published as TXT or CNAME.
5. DMARC at p=none with a working rua. Monitoring first, enforcement later.
6. Optionally np=reject if this domain will never use subdomains, which for a dedicated sending domain is usually true.

The exact record contents, the ten-lookup SPF budget and the alignment traps are covered in the DMARC setup sequence for a cold email domain. Verify each one with dig before adding the next, and confirm the whole set resolves with the SPF and DMARC record checker once they are in.

Autocloz's free plan covers 5 users and 10 mailboxes with warmup ramping and SPF, DKIM and DMARC monitoring on every sending domain — start free if you want the records watched rather than remembered.

The MX record is the one people skip, and the one that hides your bounces

A cold email domain exists to send. It is easy to conclude it does not need to receive, and that conclusion breaks three separate things.

The protocol behaviour is worth knowing exactly. RFC 5321 section 5.1 specifies that when a domain returns no MX records, the sending server treats the domain's address record as an implicit MX with preference 0. So the mail is not abandoned — it is delivered to whatever is at your A record, which for a domain pointing at a marketing site is a web server with nothing listening on port 25. The connection fails, and the mail is lost quietly rather than loudly.

What is lost:

• Delivery status notifications. RFC 3464 requires that a DSN be sent with a null return path, MAIL FROM:<>, addressed to the envelope sender of the original message — the Return-Path, not the From and not the Reply-To. If that address is on a domain that cannot receive mail, every asynchronous bounce your campaign generates is undeliverable. The bounces still happened. Your dashboard shows delivered.
• DMARC aggregate reports. Your rua address has to be reachable or the reports go nowhere, which makes p=none monitoring pointless.
• Replies. The obvious one, and the one people do catch — but usually by noticing that a prospect replied and nobody saw it.

Set the MX record before the first send, then prove it by sending a message to a made-up address at your own sending domain from a personal account and confirming that either it arrives at the catch-all or it bounces with a real rejection. Silence is the failure state.

The redirect, and what it is actually for

Point the bare domain at your main site with a 301, or host a genuine one-page site on it. Both work. What matters is that the domain resolves to something a human recognises.

Be precise about why. No mailbox provider publishes a statement that a redirect improves inbox placement, and anyone telling you it does is inferring. The real reasons are ordinary:

• A recipient will check. Someone who gets a message from try-acme.com and types it into a browser should land somewhere that explains who you are. A parked page or a registrar holding screen answers the question badly.
• Links in the signature have to work. A signature pointing at the sending domain's root is common and breaks without a redirect.
• Consistency across your records. A domain with MX, SPF, DKIM, DMARC, a website and a redirect looks like an organisation. A domain with only sending records looks like it was created to send.

Use a 301 rather than a 302 if the redirect is permanent, and terminate TLS on it so the link does not warn. That is the whole of it.

Choosing the name, and the risks that are real

The advice to buy "lookalike" domains is repeated everywhere and is right in one sense and dangerous in another.

Defensible: a close variant of your own brand that a customer would accept — getacme.com, acme-hq.com, try-acme.io. If a prospect asks about it on a call, the answer is comfortable.

Not defensible: anything that reads as an imitation of someone else. Spamhaus documents typo spamtraps as addresses at "a misspelled domain name similar to legitimate mailbox provider domains", citing examples such as yaaho.com and homail.com. Cousin-domain patterns are a recognised abuse signal for exactly that reason, and a sending domain built on the same trick invites the same scrutiny before anyone reads the message. It is also a trademark exposure that costs more than the domain.

Two things that are genuinely unknown and should be labelled as such. Nobody outside the receivers can tell you how much weight domain age carries; no mailbox provider publishes a minimum. And the top-level domain's own reputation is discussed constantly and documented nowhere — a .com is a safe default because it is unremarkable, not because a published rule prefers it. If you see a specific number attached to either of those claims, it was invented. What is documented is what a domain reputation is built from, and none of the inputs are the registration date.

How many mailboxes per domain — the rotation arithmetic

This is the question with an actual answer, because the sender picker is arithmetic rather than judgement.

Autocloz weights each candidate mailbox as its health score divided by a penalty that grows with how much that domain has already shipped today:

weight = max(1, health_score) / (1 + domain_sends_today / 100)

The load is summed across every mailbox on the domain, so the penalty is domain-level rather than mailbox-level. Work a day through it. Three domains, three mailboxes each, every mailbox at health 100.

• Start of day. Every domain has shipped 0. Penalty is 1 everywhere, weight 100 for all nine mailboxes, selection uniform.
• Domain A has shipped 200. Its penalty is 1 ÷ (1 + 2) = 0.333, so each of its mailboxes weighs 33.3.
• Domain B has shipped 50. Penalty 1 ÷ 1.5 = 0.667, weight 66.7 each.
• Domain C has shipped 0. Weight 100 each.

Total weight is (3 × 33.3) + (3 × 66.7) + (3 × 100) = 100 + 200 + 300 = 600. The next send goes to domain A with probability 100/600 = 16.7%, domain B 33.3%, domain C 50%. The picker is pulling volume off the busiest domain without ever stopping it, and the half-life of 100 sends keeps the correction gentle.

Two consequences for how you build the fleet. Adding a domain flattens load faster than adding a mailbox, because the penalty is computed per domain — a fourth mailbox on domain A shares A's penalty, while a mailbox on a new domain starts at full weight. And health matters as much as spread: a mailbox that has decayed to 40 weighs 40 against a healthy sibling's 100 before any load penalty applies, so one struggling mailbox is de-emphasised automatically rather than needing to be paused.

There is a reputation gate above all of this. A domain whose deliverability verdict is currently fail is dropped from the candidate pool entirely, with two deliberate exceptions: a failure whose only failing record is DKIM does not rotate the domain out, because DKIM selectors cannot be enumerated and a guessed miss has produced false failures twice; and if excluding every failing domain would leave no candidates at all, the unfiltered set is kept and a warning is logged, because a campaign that deadlocks helps nobody.

Sizing note for the free plan: 10 mailboxes across three or four domains is a workable shape, and unlimited mailboxes begin at Growth. Comparisons against tools that price per sending mailbox are on the Autocloz and Instantly comparison.

The order of operations before the first campaign send

1. Buy the domain and set the MX record. Prove receiving works with a real test message.
2. Publish SPF, DKIM and DMARC at p=none. Verify each with dig, count the SPF lookups.
3. Create the mailboxes. Two or three per domain is a sensible starting shape.
4. Send one message from each mailbox to a mailbox you control on a different provider, and read Authentication-Results. You want spf=pass, dkim=pass, dmarc=pass, with header.from your sending domain.
5. Point the bare domain at your site, with a working redirect and valid TLS.
6. Ramp before you enrol anyone. A new address that opens at its full daily limit has a pattern no real mailbox has ever had; the 21-day domain ramp covers the schedule, and the warmup ramp Autocloz applies to every new mailbox does it without a spreadsheet.
7. Read the aggregate reports for a week, then decide whether to move the policy to quarantine.

Nothing in that list is optional and none of it takes long. Steps 1 and 4 are the two that get skipped, and between them they account for most of the setups that look correct and are not.

What a fresh sending domain cannot buy you, and what Autocloz does not do

A new domain resets your history with every receiver. That cuts both ways: it discards accumulated damage and it also discards accumulated trust, so you start as an unknown sender rather than a good one. If the reason the previous domain failed was list quality or message relevance, the new domain reproduces the failure on a slightly delayed schedule.

A separate domain does not make the mail anonymous either. Recipients can read a WHOIS record, the redirect names your company, and the signature does too. This is separation of blast radius, not concealment, and treating it as concealment is how programmes end up sending things they would not put their main domain behind.

And Autocloz specifically. It does not register domains, host DNS, or configure your registrar. Buying the name, setting MX, publishing SPF, DKIM and DMARC and configuring the redirect are all done at your registrar and your DNS host; Autocloz reads the resulting records and tells you what is wrong with them. It does not sell mailboxes — you connect accounts you already own at Google Workspace, Microsoft 365 or an SMTP provider. Its domain monitor reads DNS on a schedule and caches the verdict, so a record you fixed five minutes ago may still show the previous result until the next check. And it does not sell contact data or bundle a lead database, so the list you send from a new domain is one you brought and one whose quality it cannot vouch for.