Cold email infrastructure — the complete setup reference.
Most teams discover the surface area of cold email infrastructure the week after their first domain gets blocklisted. This reference is the version that exists before that happens.
Fourteen chapters. Every authentication protocol, every monitoring stream, every operational discipline a B2B sender has to internalize in 2026 to land in primary instead of promotions or spam. No tool recommendations — the categories matter, the brand names change every eighteen months.
A correctly provisioned sending estate involves three DNS record families, two policy reporting streams, two domain reputation tiers, a 21- to 28-day warmup runway, four bulk-sender compliance requirements, and continuous monitoring across at least three mailbox-provider feedback channels. Any single misconfiguration cascades — a fifteen-minute DKIM key error during week two of warmup produces a domain that takes six weeks to rehabilitate, if rehabilitation is possible at all.
This reference is technical. It does not soften the surface area to make outsourcing look more appealing. The surface area is large because the underlying problem — convincing adversarial spam classifiers that you are not a spammer — is technically large. Read the whole thing before deciding to do it yourself.
Layer one — authentication.
The cryptographic and DNS-level proofs that mail from company.com actually originated from a sender authorized to use company.com. Without all four of these configured correctly, mail from a sending domain registered in the last 90 days is rejected outright by Gmail and Yahoo under the February 2024 bulk sender requirements, and routed to spam by Outlook regardless of content.
SPF — Sender Policy Framework
The 10-DNS-lookup limit, qualifier semantics (~all vs -all), include-chain auditing, and why SPF flattening trades operational complexity for one fewer failure mode at scale.
DKIM — DomainKeys Identified Mail
Key length tradeoffs (1024 vs 2048), selector rotation cadence, canonicalization modes, and why third-party senders that don't expose the private key force you into multi-selector architectures.
DMARC — Policy and reporting
The p=none → quarantine → reject escalation, alignment modes, aggregate vs forensic reports, and the production failure mode of operators who deploy p=reject before parsing a single RUA report.
MTA-STS and TLS-RPT
Enforced TLS for inbound mail, policy file hosting requirements, and why senders who skip these get downgrade-attacked on Microsoft 365 tenants with permissive inbound connectors.
BIMI — Brand Indicators
The logo-in-Gmail-avatar feature most senders chase before they've reached DMARC enforcement. VMC certificate economics, SVG-Tiny constraints, and the prerequisites no marketing team mentions.
ARC — Authenticated Received Chain
How legitimate messages survive mailing-list forwarders that would otherwise break SPF and DKIM. The protocol that keeps reply-tracking working when prospects forward your sequence to procurement.
Layer two — infrastructure architecture.
The physical-and-logical separation of corporate mail flow from cold-outbound mail flow. The reason a Series B company's payroll email survives the first deliverability incident on the SDR team's sending stack.
Subdomain and domain isolation
Corporate root (company.com) vs sending tier (mail.companyalt.com) reputation firewalling. Why a single bad campaign on the wrong domain torches every legitimate transactional email the company sends.
Domain age and reputation cold-start
Gmail's reputation cold-start curve, the 90-day burn-in observed across mailbox providers, WHOIS transparency tradeoffs, and the TLD-specific reputation differential measurable in seed-list testing.
Inbox warmup — engagement curves
Why volume-based warmup tools are increasingly detectable. The engagement curve providers actually score against, the daily ramp that survives Gmail's reputation classifier, and the operational floor under warmup volume during live campaigns.
Bulk sender requirements (Feb 2024)
The four enforcement criteria that took effect in February 2024 and February 2025: authenticated mail, one-click unsubscribe per RFC 8058, spam complaint rate under 0.3%, and TLS for all inbound.
Layer three — operations.
The continuous-monitoring posture required to detect a reputation drop in hours instead of weeks. Most teams skip this layer entirely, then discover the breakdown of their sending estate the week revenue numbers move.
Postmaster Tools and SNDS
Gmail Postmaster integration, Microsoft SNDS enrollment, the IP and domain reputation dashboards most senders never check. The signal that tells you a campaign burned reputation before the open rate moves.
Bounce taxonomy and SMTP codes
The distinction between 4xx transient and 5xx permanent failures, hard bounces vs soft bounces vs auto-responders, suppression list discipline, and the bounce categories that quietly inflate the 0.3% complaint threshold.
Seed list inbox-placement testing
The minimum viable seed-list composition across Gmail, Outlook, Yahoo, Apple iCloud, and a representative enterprise Exchange tenant. Primary vs promotions vs spam-folder differentiation in placement analytics.
Reply detection and threading
The In-Reply-To and References header chain, Message-ID best practices, and why a meaningful fraction of legitimate replies are misclassified as bounces by sequencing platforms that don't parse threading correctly.
The cost of getting it wrong.
A burned sending domain is not a rate-limited domain. It is a domain whose reputation has been classified — across the major mailbox providers' independent reputation systems — as a spam-origination identity. Rehabilitation, when possible at all, requires:
- Cessation of all sending from the domain for a minimum of 30 days, often 60
- Documented complaint-handling submitted to Spamhaus, SURBL, and Barracuda Reputation Block List
- Forensic analysis of the campaigns that triggered the classification, with mitigations
- A new warmup runway of 21–28 days under reduced volume to rebuild reputation signal
- In several observed cases — abandonment of the domain entirely and migration to a new sending identity
The forward operational cost of a domain burn — measured across SDR pipeline downtime, deliverability remediation, replacement infrastructure provisioning, and the reputation hit to any transactional or corporate mail that shared the domain — typically clears five figures even for early-stage teams. The setup-cost asymmetry is roughly 40:1 in favor of provisioning correctly the first time.
How to use this reference.
Read in order if standing up a sending estate from zero. The chapters are sequenced to match the order in which decisions cascade — domain selection (chapter 8) constrains DNS architecture (chapter 7), which constrains the authentication record set (chapters 1–4), which constrains warmup methodology (chapter 9), which constrains the monitoring stack (chapters 11–14).
Read by chapter if debugging an existing estate. The most common failure modes observed in production senders, in descending frequency: (a) DMARC published at p=reject without a complete SPF/DKIM alignment audit (chapter 3), (b) sending from a subdomain that shares reputation with the corporate root (chapter 7), (c) warmup volume reduced to zero after launch (chapter 9), (d) a sending platform that does not expose private DKIM keys, forcing third-party signing under a CNAME that fragments alignment (chapter 2).
The total provisioning effort for a 24-inbox sending estate is approximately 60 to 80 engineering hours spread across three calendar weeks, plus continuous operational overhead thereafter.
If that fits inside one engineer's quarter — read on; this reference is everything you need. If it does not, or if a domain burn during the learning curve is not an acceptable failure mode, Allston Labs runs the entire stack end-to-end. The infrastructure is registered under your entity, the monitoring lives in your Slack, and the operator on call is an engineer, not a vendor.