.svg)
Overview
Your outbound email stack is not just the tool you use to send sequences. It is a layered infrastructure that spans DNS configuration, mail server providers, IP allocation, domain architecture, sending platforms, and monitoring systems. When any layer fails, the entire stack underperforms, and the symptoms often appear far from the root cause. A drop in reply rates might be a domain reputation issue. A spike in bounces might be an IP pool problem. A sudden increase in spam placement might be a DNS misconfiguration that has been silently degrading your authentication for weeks.
For GTM Engineers building outbound programs that need to work reliably at scale, sending infrastructure is the foundation. This guide covers the full architecture of a production-grade email sending stack: mail server provider selection, IP pool management, subdomain strategy, platform evaluation criteria, and the integration patterns that connect your sending infrastructure to the rest of your GTM stack. Understanding these layers is what separates teams that fight constant deliverability fires from teams that scale outbound predictably.
Email Stack Architecture
A production outbound email stack has five layers, each with distinct responsibilities. Problems at any layer cascade upward, so understanding the full architecture is essential for effective troubleshooting and optimization.
| Layer | Components | Responsibility |
|---|---|---|
| DNS Layer | SPF, DKIM, DMARC, MX, custom tracking domains | Authentication and routing |
| Mail Server Layer | Google Workspace, Microsoft 365 | Mailbox hosting and baseline reputation |
| IP Layer | Shared IPs, dedicated IPs, IP pools | Sending reputation at the network level |
| Platform Layer | Cold email tools, sequencers, CRM email | Campaign orchestration and execution |
| Monitoring Layer | Postmaster Tools, blocklist monitoring, inbox testing | Visibility and early warning |
The DNS Layer
Every sending domain needs properly configured SPF, DKIM, and DMARC records. This is table stakes. Beyond authentication, the DNS layer also includes MX records (so you can receive replies and bounces), custom tracking domains (so your link tracking does not use shared reputation), and potentially BIMI records (for brand indicator display in supported inboxes).
The DNS layer is the foundation. Every other layer depends on it. A misconfigured SPF record breaks authentication, which undermines your DMARC policy, which degrades reputation, which causes inbox providers to filter your email regardless of how good your content or targeting is.
The Mail Server Layer
Your mailboxes live on a mail server provider, typically Google Workspace or Microsoft 365 for B2B outbound. The provider you choose sets your baseline reputation: Google and Microsoft mailboxes start with higher inherent trust than budget providers because inbox providers know these platforms enforce terms of service and have anti-abuse measures in place.
For cold outbound, the provider choice is straightforward: use Google Workspace or Microsoft 365. Period. Budget providers, self-hosted mail servers, and bulk email platforms do not have the baseline trust needed for cold prospecting. The $6-12/month per mailbox cost on Google or Microsoft is trivial compared to the deliverability penalty of using a cheaper provider.
The IP Layer
Every email you send originates from an IP address. The reputation of that IP directly affects deliverability. You will be on either shared IPs (common on cold email platforms) or dedicated IPs (available on enterprise plans or through direct ESP relationships).
IP Pools: Shared vs. Dedicated
The IP layer is one of the most misunderstood aspects of sending infrastructure. Your IP reputation is separate from your domain reputation, and managing it requires different strategies depending on whether you control your own IPs or share them with other senders.
Shared IPs
Most cold email platforms (Instantly, Smartlead, Lemlist) send through shared IP pools. Your email goes out alongside email from hundreds or thousands of other senders on the same platform. The advantage is simplicity: you do not need to warm up IPs or manage IP reputation directly. The disadvantage is that other senders' behavior affects your deliverability. A bad actor on your shared IP pool can degrade the IP reputation that your email rides on.
In practice, reputable cold email platforms manage their IP pools actively. They segment senders by reputation, rotate IPs, and remove abusive senders quickly. The impact of shared IPs on your deliverability is usually minimal compared to domain-level factors. Inbox providers have shifted toward weighing domain reputation more heavily than IP reputation precisely because shared IPs make IP-level signals less reliable.
Dedicated IPs
A dedicated IP is assigned exclusively to your sending. You control the reputation entirely: no other sender can affect it, but you are also solely responsible for building and maintaining it. Dedicated IPs require warming (similar to domain warming), consistent volume to maintain reputation, and monitoring for blocklist appearances.
Dedicated IPs make sense for teams sending 10,000+ emails per day with predictable, consistent volume. For smaller teams or teams with variable sending patterns, dedicated IPs can actually hurt deliverability because low-volume days cause the IP reputation to decay.
| Factor | Shared IPs | Dedicated IPs |
|---|---|---|
| Setup complexity | None — platform manages | Requires warming and monitoring |
| Reputation control | Shared with other senders | Full control |
| Volume requirement | None | 5,000-10,000+ emails/day for stability |
| Cost | Included in platform pricing | $20-100/month per IP |
| Best for | Teams under 5,000 emails/day | High-volume teams with consistent patterns |
| Risk | Others' behavior affects you | Your low-volume days weaken reputation |
Some teams use dedicated IPs for their highest-value sending (enterprise prospects, warmed accounts) and shared IPs for lower-priority or experimental campaigns. This balances reputation control where it matters most with the simplicity of shared infrastructure for everything else. If your cold email platform supports IP assignment by campaign or segment, this is worth exploring.
Subdomain Strategy
Subdomains serve as organizational and reputation boundaries within your domain infrastructure. They let you isolate different types of sending so that a problem in one area does not contaminate others.
When to Use Subdomains vs. Separate Domains
Both approaches isolate sending reputation, but they differ in how inbox providers perceive them:
- Separate domains (e.g.,
try-acme.com,getacme.io) — Fully independent reputation. No link to your primary domain in the eyes of inbox providers. Best for cold outbound because a reputation crisis on a sending domain cannot trace back to your primary domain's reputation. - Subdomains (e.g.,
outreach.acme.com,mail.acme.com) — Partially independent reputation. Inbox providers recognize the relationship to the parent domain and may apply some cross-contamination of reputation signals. Better for transactional and marketing email where brand recognition in the sender address matters.
For cold outbound specifically, separate domains are the standard recommendation because they provide complete reputation isolation. Use subdomains for internal email flows (marketing, transactional, support) where the parent domain association is a feature, not a risk.
Domain Naming Conventions
Your sending domains should be recognizable as your brand without being identical to your primary domain:
try-acme.com,getacme.com,acmeteam.com— Clear brand associationacme-outreach.com,meetacme.com,helloacme.com— Professional and plausible- Avoid:
acme123.com,acme-mail-server.com, random strings — These look spammy to both prospects and inbox providers
Sending Platform Selection
The platform layer is where most teams focus first, but it is actually the least differentiated part of the stack. What matters more is how the platform integrates with the layers below it (DNS, IPs) and above it (monitoring, CRM, enrichment).
Evaluation Criteria for Cold Email Platforms
When evaluating cold email platforms, these are the infrastructure-level criteria that matter more than UI polish or feature lists:
- Custom DKIM and SPF support — The platform must allow you to configure your own DKIM signing and SPF authorization. Platforms that only sign with their own domain break your DMARC alignment.
- Custom tracking domains — Link tracking should go through your domain, not a shared platform domain.
- Mailbox rotation capabilities — The platform should distribute volume across mailboxes intelligently, not just round-robin.
- Built-in warmup — Native warmup functionality reduces the need for separate warmup tools and keeps everything in one place.
- Deliverability analytics — Per-domain and per-mailbox metrics for delivery rate, open rate, bounce rate, and spam complaints.
- API access — Your cold email platform needs to integrate with your enrichment pipeline, CRM, and monitoring stack. An API is essential for building reliable automation.
Platform Categories
| Category | Examples | Best For | Limitation |
|---|---|---|---|
| Dedicated cold email | Instantly, Smartlead, Lemlist | Cold outbound at scale | Limited CRM integration depth |
| Sales engagement | Outreach, Salesloft, Apollo | Multi-channel sequences | Less deliverability-focused infrastructure |
| CRM-native email | HubSpot, Salesforce | Marketing and sales coordination | Not designed for cold outbound volume |
| Transactional ESPs | SendGrid, Postmark, Mailgun | API-driven sending at scale | Requires custom sequence logic |
Many teams use multiple platforms: a dedicated cold email tool for initial outreach, a sales engagement platform for multi-channel follow-up, and their CRM for internal notifications. This is fine as long as each platform is properly configured with your authentication records and tracking domains.
Integration Patterns
Your sending infrastructure does not exist in isolation. It connects to your enrichment pipeline, CRM, analytics stack, and monitoring tools. The integration patterns between these systems determine how maintainable and reliable your overall outbound operation is.
Enrichment to Sending Pipeline
Contacts flow from your enrichment system (Clay, ZoomInfo, Apollo) through verification, scoring, and into your sending platform. This pipeline needs gates that prevent bad data from reaching the sending layer. Email verification must happen before the contact enters any sequence. Bounce-prone contacts (catch-all domains, role-based addresses, unverified emails) should be routed to lower-priority queues or excluded entirely.
Sending to CRM Sync
Engagement data from your sending platform needs to flow back to your CRM: opens, replies, bounces, and unsubscribes. This sync enables your sales team to see the full prospect timeline and prevents issues like re-enrolling a prospect who already replied or who bounced on a previous campaign. Bi-directional sync is ideal: CRM updates (like a deal progressing or a contact requesting removal) should also flow back to the sending platform to pause or end active sequences.
Monitoring Integration
Your monitoring stack should aggregate signals from all layers: DNS authentication results from DMARC reports, domain reputation from Postmaster Tools, deliverability metrics from your sending platform, and blocklist status from monitoring services. Building a unified view across these sources is what enables proactive infrastructure management rather than reactive firefighting.
FAQ
Both work well. Google Workspace is slightly more popular for cold outbound because it integrates more easily with most cold email platforms and Google Postmaster Tools provides better reputation visibility. Microsoft 365 is preferred when your target audience is predominantly enterprise Outlook users, since email from M365 to M365 tends to get favorable treatment. Some teams split across both providers for diversification.
Start with 3-5 domains for a team of 5 SDRs, with 2-3 mailboxes per domain. Scale linearly as your team and volume grow. Each domain should have its own SPF, DKIM, and DMARC configuration. Plan for domain lifecycle management: domains degrade over 6-12 months of cold outbound use and may need rotation or replacement.
You can, but you probably should not. CRMs are not designed for cold outbound volume. They lack built-in warmup, sophisticated mailbox rotation, and the deliverability features that dedicated cold email platforms offer. More importantly, sending cold email through your CRM puts your CRM domain's reputation at risk. Keep cold outbound on dedicated domains and platforms, and use your CRM for warm follow-up and pipeline management.
When you track opens and clicks, your email platform rewrites links to go through a tracking server. By default, this tracking server uses the platform's shared domain, which is associated with thousands of other senders. A custom tracking domain routes tracking through your own domain, isolating your tracking reputation. Set it up by adding a CNAME record pointing your tracking subdomain (e.g., track.try-acme.com) to the platform's tracking server.
What Changes at Scale
A small outbound team can manage their sending infrastructure manually: 3 domains, 9 mailboxes, one cold email platform, and a weekly check of Postmaster Tools. At scale, with 20 domains, 60 mailboxes, 3 sending platforms, and campaigns spanning multiple segments and geographies, the infrastructure becomes a system that requires systematic management. DNS records need auditing across all domains. Mailboxes need health monitoring and lifecycle management. IPs need reputation tracking. And all of these need to stay coordinated as the stack evolves.
The core problem at scale is state management. Which domains are warm and which are warming? Which mailboxes need resting? Which platforms have current DNS configurations? Where are the capacity bottlenecks? This state lives in spreadsheets, tribal knowledge, and half-dozen different tools, none of which talk to each other.
This is where Octave provides the AI-powered execution layer that makes sending infrastructure manageable at scale. Octave is an AI platform that automates and optimizes your outbound playbook, connecting to your existing GTM stack. Its Sequence Agent generates personalized email sequences per lead, auto-selecting the best playbook, while its Clay integration (API key + Agent ID) enables at-scale orchestration across your entire domain and mailbox portfolio. Instead of maintaining a spreadsheet of domain warmup status and manually cross-referencing it with Postmaster Tools data, teams use Octave to coordinate outbound execution across channels, ensuring sending volume is distributed across healthy infrastructure.
Conclusion
Sending infrastructure is the invisible backbone of your outbound program. It spans DNS authentication, mail server selection, IP reputation, platform configuration, and monitoring systems. Each layer depends on the ones below it, and problems cascade upward in ways that are often difficult to diagnose without understanding the full architecture.
Build your stack methodically: DNS and authentication first, then mail server provisioning, then platform selection and configuration, then monitoring. Document your infrastructure choices so that onboarding new team members or troubleshooting issues does not require tribal knowledge. And invest in the monitoring layer that gives you visibility across all the components, because the problems you catch early are the ones that never become crises.
For GTM Engineers, sending infrastructure is where technical depth directly translates to business impact. A well-architected sending stack delivers email reliably, scales predictably, and recovers quickly from the inevitable hiccups. A poorly architected one is a constant source of firefighting that drains time from higher-value work like personalization optimization and pipeline strategy.