Cold email infrastructure: domains, mailboxes and DNS

Cold email infrastructure is the set of domains, mailboxes, DNS records and sending limits that your outreach runs on. Build it so that a problem on one mailbox or domain stays small: keep cold mail off your primary domain, give every sending domain its own authentication records, and set a per-mailbox cap that you raise in steps. No provider publishes a “right” number of mailboxes per domain, so those numbers are your decision, not a rule.

This guide covers the parts you control. Message content and list quality matter as much, and they are covered in cold email deliverability.

The four layers

Domains: keep cold mail away from your main domain

Your main domain carries your invoices, support replies and partner email. Cold outreach has a higher chance of complaints and bounces than mail to people who asked for it, so it should not share a reputation with that traffic.

Two sources help here.

• Microsoft’s SPF guidance says that for email services you do not directly control, such as bulk email services, you should use a subdomain instead of your main email domain, so that issues with that mail do not affect the reputation of mail sent by employees in the main domain.
• Google’s sender FAQ says it counts messages from the same primary domain together when it checks the 5,000-message bulk sender threshold. Its example adds 2,500 messages from one domain and 2,500 from its subdomain to reach 5,000. A subdomain therefore does not give you a separate count, while a separate registered domain does.

Many teams register look-alike domains for outreach, for example a variation of the brand name with a different top-level domain or a short suffix. This protects the primary domain. It also has a cost: recipients should still be able to tell who you are. Use your real name and company in the From line and signature, and put a working address in Reply-To. Microsoft’s high-volume sender announcement asks for From or Reply-To addresses that are valid, reflect the true sending domain and can receive replies.

Practical rules for sending domains:

1. Register the domain with a registrar you can reach quickly, and turn on auto-renew. An expired domain stops every mailbox on it.
2. Give the domain a simple web page or a redirect to your main site. Recipients may look.
3. Treat each domain as disposable. Do not tie anything you cannot move, such as a customer contract address, to it.

Mailboxes and providers

You have three common ways to get a sending mailbox.

• Google Workspace or Microsoft 365 mailboxes. Familiar, with provider-enforced limits and a per-seat cost.
• SMTP through a transactional or bulk service. Suited to volume, but you manage identities and records yourself.
• Mailboxes from an outreach platform that provisions them for you. Less setup, and the platform can enforce its own caps on top of the provider’s.

Whichever you choose, know the provider ceiling. These are documented limits, checked on 2026-10-05:

Treat the table as an upper bound only. A mailbox that sends near its provider ceiling to cold recipients is the opposite of cautious. Google also states that a user who exceeds the sending limit cannot send new messages for up to 24 hours.

How many mailboxes per domain, and what cap per mailbox

I could not find a primary source from Google, Microsoft or Yahoo that recommends a number of mailboxes per domain or a daily cap per cold mailbox. Anyone who gives you a single “correct” figure is quoting a convention. What you can do is work backwards from the volume you want and the risk you accept.

The arithmetic:

1. Decide the daily volume for the whole programme.
2. Divide by a per-mailbox cap you choose. That gives the number of mailboxes.
3. Divide the mailboxes by the number you are willing to put on one domain. That gives the number of domains.

Example, using assumed inputs that you should replace with your own: a programme of 300 first-touch emails per day, a cap of 30 per mailbox and 3 mailboxes per domain. That is 10 mailboxes on 4 domains. If one domain is damaged, you lose a quarter of capacity, not all of it. The inputs (30 and 3) are for illustration, not a recommendation.

A lower cap and fewer mailboxes per domain make each mailbox easier to read: when bounces or complaints appear, you can see which identity caused them.

Caps by mailbox age

Google’s sender guidelines tell senders to start with a low sending volume to engaged users and increase it slowly over time. They also say to avoid sudden volume spikes if you have no history of sending large volumes, and give the example that immediately doubling previously sent volumes could result in rate limiting or reputation drops.

Cold recipients are not “engaged users”, so the advice does not map exactly. The part that applies is the shape: a new mailbox has no history, so it gets a low cap, and the cap rises in steps. A workable policy has these properties:

• A starting cap that is low enough that one bad batch does not matter.
• A step rule: raise the cap only after the previous period ran clean on bounces and replies, and never double it in one step.
• A hard ceiling that stays far under the provider limit above.
• A rule that pauses the mailbox, not just the campaign, when bounce or complaint signals cross your threshold.

DNS checklist

Each sending domain needs its own records. Examples use example.com; replace the include value with the one your provider documents.

; SPF: one record per domain, ends with an enforcement rule
example.com.                   TXT  "v=spf1 include:_spf.provider.example -all"

; DKIM: published under selector._domainkey
s1._domainkey.example.com.     TXT  "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GN..."

; DMARC: start with monitoring
_dmarc.example.com.            TXT  "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"

Notes, each from the specifications or provider guides listed in the sources:

• One SPF record. A domain must not have multiple SPF records that would cause more than one to be selected (RFC 7208). Microsoft says multiple SPF TXT records cause permerror.
• Ten lookups. SPF evaluation is limited to 10 DNS-lookup terms, and exceeding it returns permerror. include, a, mx and redirect count; ip4 and ip6 do not (RFC 7208; Microsoft’s SPF guide).
• DKIM key size. Signers must use RSA keys of at least 1024 bits (RFC 6376). Google’s admin guide prefers 2048 when your DNS host supports it.
• DMARC. The record lives at _dmarc.<domain>. p=none is the monitoring policy, and Google and Yahoo accept it as a minimum for bulk senders. Details are in SPF, DKIM and DMARC for cold email.
• MX. Mailboxes that receive replies need MX records. A mailbox that cannot receive replies fails the “valid From or Reply-To” expectation above.
• Subdomains and DMARC. A DMARC record covers subdomains that have no record of their own, but each subdomain still needs its own SPF and DKIM for DMARC to pass.

After publishing, send a test message to a mailbox you control and read the Authentication-Results header. You want spf=pass, dkim=pass and dmarc=pass, with the From domain aligned to the SPF or DKIM domain.

Checklist before the first send

• Sending domain is separate from the primary domain and set to auto-renew.
• SPF has a single record and stays under 10 lookups.
• DKIM is published and a test message shows dkim=pass.
• DMARC exists at _dmarc with a reporting address you read.
• Every mailbox has a starting cap and a ceiling, written down.
• A pause rule is defined per mailbox and per domain.
• Unsubscribed and complaining addresses are blocked from future sends.
• The From name, signature and reply path identify a real person and company.

How Dooxout handles this

Dooxout provisions domains and mailboxes for you, and the preflight check before a launch looks at the records above. Limits are enforced by the server: caps per mailbox, per domain and per channel, with the cap rising as a mailbox gets older, and an automatic freeze when thresholds are crossed. The platform does not run warm-up traffic; a new mailbox is usable at once and its low starting cap is what limits exposure. You can also connect your own mailboxes or sending services. On those, the platform warns and recommends, and the decision stays with you.

One rule cannot be changed: addresses that unsubscribed or complained are not sent to again, whichever channel you use.

More detail on the product side is at cold email infrastructure and integrations.