Cold email domain strategy: how many domains and why

Every cold email campaign carries risk. Lists contain bad addresses, some recipients mark mail as spam regardless of how relevant it is, and filters occasionally decide against you for reasons you will never see. The question is not whether that risk exists but which domain absorbs it.

Never send cold mail from your primary domain

Your primary domain carries your invoices, contracts, support replies, password resets and every conversation with an existing customer. If its reputation is damaged, those stop arriving. Not visibly - they simply start landing in Junk, and you find out when a customer says they never received something.

Recovering a burned domain takes months and is not guaranteed. The correct structure isolates that risk onto domains that are cheap to replace.

yourcompany.com          <- primary. Contracts, invoices, support. Never cold mail.
tryyourcompany.com       <- cold email. Isolated reputation.
getyourcompany.com       <- cold email. Isolated reputation.
yourcompanyhq.com        <- cold email. Isolated reputation.

If a sending domain degrades, you retire it and stand up another. The cost is a domain registration and a warmup period, not your ability to invoice.

How many domains

This follows from volume. The usual guidance is a handful of mailboxes per domain, on the reasoning that concentrating too many on one domain concentrates the risk. That is sound when the mailboxes are sending aggressively.

It matters less when each mailbox sends gently. A hundred mailboxes at thirty sends is 3,000 a day across the domain, spread across far more human-looking senders than thirty mailboxes each pushed to a hundred. The domain-level volume receivers weigh is the same; the per-mailbox behaviour is not.

Our own default is 100 inboxes on one domain, which lets you choose the per-inbox rate rather than being forced high by having too few mailboxes. Teams wanting more separation run several such domains and rotate. What cold email inboxes are and how to buy them sets out how providers package this and what it costs per inbox.

Checking a domain before you buy it

A domain arrives with whatever reputation its previous owner earned. Expired domains are resold constantly, and a name that once sent bulk mail carries that history into your campaign - blocklist entries and spam-trap associations outlive the registration.

1. Search the domain on archive.org. A site that was a real business is fine; a parked page full of ads, or a run of unrelated languages, is a domain that has been through the resale market.
2. Check it against the major blocklists before purchase, not after. A listing on Spamhaus or SpamCop is a reason to pick a different name rather than something to appeal.
3. Look up the existing DNS. A domain still carrying SPF or DKIM records from a previous sender has been used for mail, and you are inheriting whatever that sender did.
4. Search the name in quotes. Complaint threads and scam reports are worth knowing about before the domain is fronting your outbound.

Our own free DNS records checker does the record side of this in one pass, and the blacklist checker covers the listings. If you want to see where a domain currently routes mail before you commit to it, the DNS checker returns its MX, TXT, A and NS records sorted by priority. All three are free and none needs an account.

How long a domain needs before it sends

Age matters, but not as much as the folklore suggests. What receivers weigh is sending history, and a domain registered six months ago with no history is not meaningfully more trusted than one registered last week. What they do treat as suspicious is a domain that registers and immediately sends at volume.

A workable sequence is to register, point the domain somewhere real, configure authentication, and let it sit for a week or two while the records propagate and settle. Then warm up. The waiting is not magic - it avoids the pattern of register-and-blast that filters are specifically tuned to catch.

Choosing sending domains

• Stay recognisably close to your brand. try-, get-, -hq and -app prefixes read as legitimate; unrelated words read as throwaway.
• Prefer .com. Alternatives are cheaper and carry more filter suspicion, which is a poor trade on your sending infrastructure.
• Check the history before buying. A previously abused domain arrives with reputation you did not create.
• Avoid hyphens and numbers, which correlate with disposable domains.
• Register for more than a year. Single-year registrations skew toward throwaway use.

Checking history matters more than people expect. A domain that previously hosted a phishing operation or a spam campaign may sit on blocklists for years. Search it, check archive services, and run it through a blocklist checker before committing.

Redirect your sending domains

A sending domain should resolve to something in a browser. A prospect who receives your mail and types the domain into a browser expects a site; a blank page or a registrar parking notice is a strong negative signal to a human, and the absence of a website is a weak negative signal to some filters.

A 301 redirect to your primary site is sufficient. It costs nothing and it removes an easy objection.

Each domain needs its own authentication

Agencies running this per client should settle domain ownership as policy rather than per deal, since a departing client takes the sending reputation with them. SPF, DKIM and DMARC are per-domain. Records on your primary do nothing for a sending domain. Every domain you send from needs its own SPF record, its own DKIM keys with signing actually enabled, and its own DMARC policy - the full setup is covered here, and the DNS records checker will check up to 25 domains at once.

This is the step that scales badly by hand, and it is where most self-built outbound infrastructure develops silent faults. Configuring three domains is tedious but manageable. Configuring twenty, correctly, and verifying each one, is a project.

It is also what we do: bring your own domain or have us register one for $12, and the inboxes arrive with authentication configured and verified rather than as a task waiting for you.

A worked structure

A team wanting 600 cold emails a day, sustainably:

1. Two sending domains, both distinct from the primary, both redirecting to it.
2. 100 Microsoft 365 inboxes on each, 200 total.
3. Three sends per inbox per day, 600 a day across both domains.
4. SPF, DKIM and DMARC configured and verified on both before any sending.
5. Warm both over two to four weeks before loading real prospects.
6. Monitor per-domain placement so one degrading domain can be rotated out without touching the other.

The redundancy is the point. One domain having a bad month does not stop your outbound, and nothing that happens to either touches the domain your contracts go out on.