Operator infrastructure guide · Cold email AI
Inside Our Cold Email Infrastructure Setup: Domains, Mailboxes and a Slow Ramp
Build cold email infrastructure with separate domains, authenticated mailboxes, verification, gradual cold-send limits, monitoring and stop rules.
Editorial disclosure
AI may assist research organization and drafting. A human editor reviews every published page, checks material claims against the cited sources and owns the final decision. No company paid for placement in this article.
AI use policyAgent-ready brief
AI takeaways
Keep the key points here, or take a source-aware text brief into Claude, ChatGPT or another AI workspace.- 01Never use the primary business domain for bulk cold outreach.
- 02SPF, DKIM and DMARC authenticate identity but do not guarantee inbox placement.
- 03Warm-up traffic and the production cold-send ramp are different operating states.
- 04Monitor mailbox, domain and campaign layers separately and pause on red-zone or sharp comparative decline.
- 05Historical mailbox and send limits are bounded operator experience, not universal safety thresholds.
Includes summary, takeaways, sources and a use note.
A cold email infrastructure setup needs separate sending domains or subdomains, real mailboxes, provider-configured SPF and DKIM, a DMARC policy and reporting plan, address verification, global suppression, a sequencer, gradual cold-send limits, and monitoring. It also needs a person who can pause a mailbox before a bad signal becomes a domain-wide problem.
The infrastructure does not create message-market fit. It only makes execution possible. A perfect SPF record cannot repair a weak offer. A warm mailbox cannot make an irrelevant list relevant. An AI sender cannot decide that a sudden drop is harmless because the dashboard still shows green somewhere else.
Operator baseline: never use the primary business domain for bulk cold outreach; keep sending identities separate; treat four to six mailboxes per sending identity as one historical pattern, not a universal rule; configure and warm before production; start cold sends around five per mailbox per day, move toward 15 after roughly three weeks, and approach 30 only while healthy; pause on a red-zone state or sharp mailbox-level fall; and keep spare warmed inventory.
Across more than seven years of outreach, the broader operation used roughly 100 sending domains or subdomains over time, often with four to six mailboxes each. That historical scale is not a recommendation to buy 100 domains. It is evidence that sender operations are a continuing system, not a one-time DNS checklist.
Commercial disclosure: Luck My Sales received no affiliate payment, sponsorship, free access, consulting benefit, or other consideration from the domain, mailbox, verification, or sending products discussed. The first-person setup is Anastasiia's operating experience. Provider requirements come from current primary documentation. This is not legal advice or a promise of inbox placement.
Cold email infrastructure is a monitored operating system, not a DNS checklist or an inbox-placement guarantee.
01 / architecture in one
The architecture in one view
primary business domain → protected from cold campaignsseparate sending domain/subdomain → DNS authentication → 4–6 mailboxes → sequencer → verified approved list → gradual cold sends → replies/suppression → selective CRM admissionKeep the objects distinct.
| Object | What it is | What it is not |
|---|---|---|
| Registered/root domain | A domain registered and controlled by the business | A mailbox |
| Subdomain | A DNS namespace below a root domain | A separate legal identity or reputation guarantee |
| Mailbox | A sender address hosted by a mail provider | A whole domain |
| Sender identity | Display name, From address, signatures, and accountable person | A disposable disguise |
| Sequencer | Software that schedules messages and processes events | A source of consent or strategy |
| Verification tool | A service that estimates address status | A guarantee that a recipient wants the email |
| Suppression record | Minimum state preventing future contact | A sales lead |
The difference between a root domain and subdomain matters operationally. In our history, both types appeared in the broader sender inventory. Do not describe every identity as a “subdomain” if the team actually registered separate domains. Document exactly what is being protected and how provider reputation may connect the identities.
02 / protect the primary
Step 1: protect the primary business domain
The primary domain supports employee communication, customers, password resets, billing, legal notices, recruiting, and other essential mail. Bulk cold outreach exposes that communication to campaign mistakes, poor lists, complaints, and unstable sending patterns.
We kept cold outreach off the primary domain. This is a business-continuity boundary, not a technique for escaping responsibility. The sending identity should still be accurate, recognizable, and connected to the real business. Deceptive lookalikes, false display names, or hidden identity create more risk, not less.
Google's email sender guidelines require accurate sender information and prohibit misleading headers and display names. Google also says messages should connect senders and recipients meaningfully. Separate infrastructure does not make deception acceptable.
Before buying domains, write down:
- the protected primary domain and critical mail types;
- each sending domain or subdomain and its owner;
- registration and renewal access;
- mailbox provider and admin owner;
- DNS owner;
- sequencer connection;
- sender person and signature;
- permitted campaign and geography;
- status: setup, warm-up, pilot, production, paused, or retired.
If this inventory lives only in one person's browser, the operation is not ready to scale.
03 / choose a domain
Step 2: choose a domain and mailbox model
There is no universal “four domains, five mailboxes” formula. Capacity depends on audience, provider, sender history, list quality, message behavior, and the team's tolerance for operational overhead.
Our common pattern was four to six mailboxes per sending domain or subdomain. Providers varied, including Zoho and mailbox services connected to hosting providers. We did not assume one provider was automatically better. We checked whether it supported proper authentication, admin access, recovery, logs, and the sending use case.
For a small pilot, begin with the capacity needed for the validated list, not the capacity advertised by the sending tool. If the ICP produces 400 approved contacts and the team wants a short, controlled test, buying dozens of mailboxes adds cost and more states to monitor without improving the offer.
Use a capacity worksheet:
approved contacts × planned touches = planned production messagesThen divide by:
mailboxes × approved cold-send limit × sending daysExample: 400 approved contacts with three planned messages create up to 1,200 production messages. Four mailboxes at 15 cold sends per day provide 60 messages per sending day. At that rate, full theoretical execution takes 20 sending days, before replies, pauses, bounces, exclusions, and schedule gaps reduce the actual volume.
That is not a recommendation to send all 1,200 messages. Any reply stops the rest for that person. The equation is a capacity ceiling, not a campaign target.
04 / configure SPF DKIM
Step 3: configure SPF, DKIM and DMARC with the provider
Authentication is a provider and DNS requirement, not a checkbox invented by outreach software.
SPF: who may send for the domain
SPF lets a domain publish which hosts are authorized to send mail for it. In practice, the SPF record must include every legitimate sending service used for that domain. Multiple disconnected SPF records or missing providers can break evaluation.
Do not copy a generic record from an article. Use the exact record supplied by the mailbox or email service provider, then verify the resulting DNS state.
DKIM: cryptographic domain signing
DKIM adds a domain signature that receivers can verify. The mailbox provider normally generates the selector and public-key record. The team publishes the required DNS record and enables signing.
Google currently requires a DKIM key of at least 1,024 bits for mail to personal Gmail accounts and recommends 2,048 bits when supported. Follow the provider's current instructions rather than guessing selectors or rotating keys manually without a plan.
DMARC: alignment, policy and reporting
DMARC lets a domain owner state how receivers should treat messages that fail aligned SPF or DKIM and provides a reporting mechanism. Alignment means the authenticated domain corresponds appropriately with the visible From domain.
Start from visibility and a controlled policy plan. An aggressive policy deployed before legitimate senders are known can reject real business mail. A permanent monitoring-only posture can leave spoofing protection incomplete. The correct rollout depends on the domain's legitimate senders and risk.
Current provider baseline
Google's current guidance says all senders to personal Gmail accounts must use SPF or DKIM, valid DNS and TLS, proper message formatting, and low spam rates. Senders over 5,000 messages per day to Gmail accounts must use SPF, DKIM, DMARC, alignment, and additional unsubscribe controls. Yahoo and Microsoft publish their own requirements. Verify each provider before launch because thresholds and enforcement change.
Authentication supports identity and delivery. It does not prove consent, relevance, or legal basis. Provider policies may advise opt-in even where a sales team believes local law permits a particular business contact. Legal review remains a separate gate.
05 / connect and verify
Step 4: connect and verify every mailbox
The sequencer should not be the only place where mailbox credentials, DNS status, and ownership are understood. Keep an external sender inventory with:
- mailbox address and real sender;
- domain/subdomain;
- provider and admin account;
- SPF, DKIM, and DMARC check date;
- sequencer and campaign assignment;
- production daily limit;
- warm-up status if used;
- last health review;
- bounce, deferral, complaint, or warning state;
- pause reason and recovery decision.
Send test messages to controlled accounts at several providers. Inspect headers. Confirm the visible From identity, reply path, authentication results, signature, and unsubscribe behavior. Check that a reply reaches the correct inbox and can stop every relevant sequence.
The preflight should include test records for:
- valid ordinary prospect;
- missing first name or company field;
- existing customer;
- duplicate contact in another campaign;
- invalid address;
- unsubscribe/suppressed record;
- OOO reply;
- positive and negative reply;
- mailbox pause while a message is queued.
Infrastructure QA is not complete when a test email arrives. It is complete when the full event state behaves correctly.
06 / verify data and
Step 5: verify data and maintain suppression
We used ZeroBounce for bulk verification and Clay as part of the data and enrichment layer. Lemlist handled duplicate visibility inside its workflow. Those tools performed different jobs.
Verification should happen near the send date because addresses and roles change. Treat statuses such as valid, invalid, catch-all, unknown, disposable, or risky according to the provider's documented definitions and the organization's policy. A “valid” result means the verification service has a reason to accept the address as contactable. It does not mean the person is in the ICP, wants the message, or will not complain.
Suppression must be broader than one campaign. Maintain at least:
- explicit unsubscribe;
- hard bounce according to provider definition;
- complaint or abuse signal;
- current customer exclusion where appropriate;
- employee, partner, and competitor exclusions;
- do-not-contact account or person;
- duplicate identity across email variants;
- active opportunity or named-account owner.
An unsubscribe record is not CRM pipeline, but it must be retained in the minimum form needed to prevent future contact. Deleting the only suppression evidence can cause the same address to re-enter from the next data export.
07 / separate warm-up from
Step 6: separate warm-up from production ramp
Warm-up products usually exchange or simulate messages to create sending history. Vendors often describe them as a deliverability solution. Treat that as a vendor practice, not independent proof of inbox placement.
Our mailboxes were prepared for at least 14 days before production in the specific setup discussed earlier. Production cold sends then followed a separate ramp:
| Stage | Cold sends per mailbox per day | Operator action |
|---|---|---|
| Initial production | About 5 | Review every sender, record and message |
| Controlled ramp | Move gradually toward 15 over roughly 3 weeks | Check authentication, bounces, deferrals, replies and mailbox health |
| Healthy upper operating limit | Up to 30 in the observed practice | Only while sender and campaign indicators remain stable |
| Warning state | Reduce or pause | Diagnose mailbox, domain, list, message and provider response |
| Red zone or sharp decline | Stop or replace | Preserve evidence; do not force volume through the identity |
These are our historical cold-send limits. They exclude warm-up traffic. They are not Gmail, Yahoo, Microsoft, Lemlist, or Instantly guarantees.
Google recommends gradual increases, consistent rather than bursty sending, monitoring provider responses, and reducing volume when bounces or deferrals rise. It also says low open rate is not a reliable deliverability diagnosis and that Google cannot verify third-party open rates.
Therefore, do not use “open rate is down” as the only reason to replace a mailbox. Start with harder evidence: authentication failures, SMTP responses, bounces, deferrals, complaint or spam indicators, provider reputation tools, sequencer health warnings, and consistent changes across comparable sends.
08 / monitor at mailbox
Step 7: monitor at mailbox, domain and campaign level
Aggregate reporting can hide a damaged sender. If one mailbox performs poorly while nine others look normal, the campaign average may not trigger alarm.
Monitor three layers.
Mailbox layer
- authentication result;
- delivery errors, bounces, and deferrals;
- mailbox or sequencer health status;
- send volume and sudden changes;
- replies by type;
- provider-specific warnings;
- whether the mailbox is used in multiple campaigns.
Domain or subdomain layer
- DMARC reports and unauthorized sources;
- provider reputation where available;
- spam or complaint signals;
- repeated errors across mailboxes;
- DNS changes and expiration;
- links or tracking domains associated with the sender.
Campaign layer
- approved records and messages sent;
- delivered messages with denominator;
- bounces and deferrals;
- meaningful and positive replies;
- unsubscribe and negative responses;
- held meetings and accepted opportunities;
- list version, message version, and sender allocation.
One metric is a symptom. Diagnose the layer. If every mailbox drops after a new list, investigate the list. If one mailbox drops across campaigns, investigate that mailbox. If replies remain low while delivery is stable, inspect ICP, offer, evidence, and copy before buying more domains.
09 / create pause recovery
Step 8: create pause, recovery and replacement rules
We paused when the sending platform showed a red-zone status or when mailbox-level results fell sharply. The next decision was recovery versus replacement.
Use a written incident record:
- What changed: DNS, provider, mailbox, list, message, volume, tracking, or tool?
- Which sender identities are affected?
- What do SMTP and provider responses say?
- Are SPF, DKIM, DMARC, and DNS still correct?
- Did bounces, complaints, or deferrals change?
- Is the issue isolated to one mailbox, domain, provider, or campaign?
- Which messages are queued, and can they be stopped?
- What evidence supports recovery, continued pause, or retirement?
Do not keep forcing sends through a damaged identity to “collect more data.” The experiment can create additional damage while changing the conditions you are trying to diagnose.
Our operational preference was to maintain spare warmed domains or mailboxes. In many cases, building a new compliant sender path was more predictable than spending weeks trying to recover an identity with uncertain history. This is a continuity decision, not a recommendation to evade provider enforcement. Retired identities remain documented and suppressed from accidental reuse.
10 / Capacity plans for
Capacity plans for three stages
Stage 1: founder validation
Keep the system small. One or two sending identities may be enough for a short approved list. The founder still owns the reply. The main objective is to learn whether the market and message work. Infrastructure should protect the business and expose errors. It should not create pressure to fill unused capacity.
At this stage, document every domain, mailbox, list, message version, and reply. Review all production records. If the founder cannot read the replies, the campaign is already too large.
Stage 2: first repeatable outbound motion
Add sender capacity only after one segment, offer, and channel produce repeatable conversations. Separate data, research, and sending ownership. Keep one global suppression source. Assign a person to mailbox health and another clear person to replies, even if both roles belong to one employee.
Use the capacity worksheet each week. Planned sends should fall when replies stop future touches. Do not keep the scheduler full merely because domains and mailboxes were paid for.
Stage 3: ongoing multi-campaign operation
At larger scale, the hard problem is inventory and state. The team needs renewal control, provider admin, DNS change history, sender assignment, domain reputation views, list lineage, client or business-unit separation, and incident records. Spare inventory becomes useful only when it is also authenticated, monitored, owned, and protected from accidental reuse.
This was the context in which our historical operation reached roughly 100 domains or subdomains over time. The count came from ongoing campaigns and replacement cycles. It was not a launch checklist.
11 / weekly sender audit
A weekly sender audit
Run a short audit at the same time each week.
- Confirm that no primary-domain mailbox entered a cold campaign.
- Check domain registration and mailbox admin access.
- Review SPF, DKIM, DMARC, and provider alerts after any change.
- Compare each mailbox with its own recent baseline.
- Read bounce and deferral reasons, not only the rate.
- Inspect unsubscribe and suppression propagation.
- Check queued messages after replies or pauses.
- Review sender allocation across campaigns.
- Retire stale copy, links, prices, and proof.
- Record the decision: continue, reduce, pause, diagnose, or retire.
The audit is intentionally simple. A stable system should be easy to explain. If several tools disagree about health, the operator must know which event is primary and which is an estimate.
12 / ten infrastructure mistakes
The ten infrastructure mistakes that cause the most avoidable damage
1. Sending cold campaigns from the primary domain
It places essential business mail next to experimental outreach risk.
2. Copying DNS records without understanding the provider
SPF, DKIM, and DMARC must match the actual services and visible From identity.
3. Treating a green dashboard as end-to-end proof
Inspect headers, provider responses, replies, suppression, and queued states.
4. Adding too many mailboxes per domain too early
Capacity without stable qualification and messaging only increases monitoring and risk.
5. Using a marketing or customer CRM sender for cold bulk mail by default
It can mix subscribed, transactional, customer, and cold traffic and pollute operational state.
6. Forcing too many cold sends through one mailbox
Provider behavior and sender history matter. Use a cautious ramp and stop signals.
7. Sending newsletters to people who never subscribed
A cold one-to-one business approach and a recurring marketing subscription are not the same workflow.
8. Assuming warm-up guarantees inbox placement
Warm-up does not remove authentication, complaint, reputation, list, or content risk.
9. Renting infrastructure without ownership visibility
The team still needs admin, DNS, renewal, export, recovery, and suppression control.
10. Choosing tools before defining the operating contract
A sender with impressive automation can still have unclear global stops, queued messages, or CRM writes.
13 / simple incident example
A simple incident example
Assume one mailbox enters a red zone while other mailboxes on the same domain remain stable. Stop that mailbox. Do not move its queued messages to every other sender at once. Save the time, campaign, list, copy, volume, provider response, and health view.
Check authentication first. Then read bounces and deferrals. Compare the mailbox with its own earlier sends. Check whether it joined a new campaign or list. Check whether a link, tracking domain, signature, or message changed. If the evidence is sender-specific and recovery remains unclear, retire the mailbox. If several mailboxes changed together, investigate the shared domain, provider, list, or campaign before replacing anything.
Now assume replies fall but delivery events and sender health remain stable. Do not replace the mailbox. Read the replies. Check ICP, offer, evidence, copy, and seasonality. The symptom belongs to the campaign layer until harder sender evidence says otherwise.
This two-case distinction prevents expensive rotation. It also prevents the opposite mistake: forcing volume through a sender because aggregate delivery still looks acceptable.
Keep the incident note after the sender retires. A future operator needs to know why the identity stopped, which campaigns used it, and whether the same list or copy caused trouble elsewhere. Mark the domain, subdomain, mailbox, and tracking asset separately. Do not write only “deliverability issue.”
Review the fix after a quiet period. Confirm that the change solved the observed error. Do not call a recovery successful because one test message reached an inbox. Use several controlled messages and the provider's own responses. Then resume at low volume. Keep the old limit out of the schedule until the new evidence is stable.
14 / Preflight checklist
Preflight checklist
Identity and ownership
- The primary business domain is not used for bulk cold campaigns.
- Every sending domain/subdomain has a real owner, renewal access, and accurate identity.
- Every mailbox maps to a real sender and reply owner.
Authentication and provider state
- SPF is published for the actual sender services.
- DKIM signing is enabled and verified.
- DMARC alignment and reporting are understood.
- Forward/reverse DNS and TLS responsibilities are confirmed with the provider where applicable.
- Provider-specific requirements were checked on the launch date.
Data and campaign
- The ICP, exclusions, evidence, and list version are approved.
- Addresses are verified near send time.
- Global suppression and duplicate rules are tested.
- Missing variables cannot create broken copy.
- Every reply stops the sequence and assigns a human.
Ramp and monitoring
- Cold-send limits are separate from warm-up traffic.
- The first batch is fully reviewed.
- Mailbox, domain, and campaign monitoring is active.
- Pause, recovery, and replacement criteria are written.
- Spare inventory is documented rather than improvised during an incident.
15 / Frequently asked questions
Frequently asked questions
How many domains do I need for cold email?
Start from the approved contact pool, message plan, send days, and cautious mailbox limit. A small validation campaign may need very little infrastructure. Buying many domains before the motion works adds cost and operational risk.
How many mailboxes should be on one domain?
Our common historical pattern was four to six, but it is not a universal standard. Provider, identity, sending history, monitoring capacity, and business risk matter. Start smaller and expand only after stable evidence.
How long should a mailbox warm up?
Our specific setup used at least 14 days before production, but warm-up is not a guarantee. Follow current provider guidance, configure authentication, start cold production slowly, and monitor real provider responses.
Is 30 cold emails per mailbox per day safe?
No fixed number is universally safe. Thirty was an upper operating limit in our healthy historical practice, not a provider promise. A lower limit can still fail with a bad list or high complaints; a provider can change enforcement at any time.
Should I use a subdomain or separate root domain?
Both appear in real operations and have different ownership and reputation implications. Protect the primary business mail, keep identity accurate, and document the exact object. Do not assume a subdomain creates complete isolation.
When should I replace a mailbox?
Replace or retire after a documented diagnosis shows persistent sender-specific trouble, a red-zone state, or a sharp comparable decline and recovery is uncertain. Do not rotate identities merely to avoid enforcement; fix the list, message, and operating cause too.
16 / Final recommendation
Final recommendation
Build the smallest infrastructure that can run a real, approved campaign. Protect the primary domain. Configure authentication with the provider. Verify addresses. Test suppression and replies. Ramp cold sends slowly. Monitor mailbox, domain, and campaign state separately. Pause when the evidence changes.
Our numbers—roughly four to six mailboxes per sender domain, five cold sends per day at the start, about 15 after three weeks, and up to 30 only while healthy—are bounded operator experience. They are useful as a conservative example, not a universal recipe.
The infrastructure is successful when it protects essential communication, produces inspectable event data, stops cleanly, and hands real conversations to a person. It is not successful because it sent the planned volume.
Continue with the AI Cold Email Tools comparison, the AI Email Sales Outreach workflow, the Cold Email vs LinkedIn guide, the AI Sales Outreach pillar, and the Luck My Sales AI policy.
Research note
Methodology
- 01First-person evidence comes from Anastasiia's seven-plus years operating cold-email sender systems.
- 02The historical scale and ramp numbers describe bounded practice, not guaranteed provider limits or outcomes.
- 03Authentication definitions and current provider expectations are tied to primary standards and Google documentation.
Source ledger
Sources & editorial notes
- 01Email sender guidelines
Google · Official product, platform, provider or standards source used for the bounded claim cited in this guide.
- 02RFC 7208: Sender Policy Framework
IETF · Official product, platform, provider or standards source used for the bounded claim cited in this guide.
- 03RFC 6376: DomainKeys Identified Mail
IETF · Official product, platform, provider or standards source used for the bounded claim cited in this guide.
- 04RFC 7489: DMARC
IETF · Official product, platform, provider or standards source used for the bounded claim cited in this guide.