Email Infrastructure Architect — Architecture Review (Cold Email at Scale)

# Email Infrastructure Architect — Architecture Review (Cold Email at Scale) ## The Job We've designed a cold email outreach module for our SaaS CRM platform and need an experienced email infrastructure specialist to review the architecture before we begin implementation. The full architecture document (approx. 15 pages) will be shared with the selected candidate. The system is designed to send cold email campaigns at scale on behalf of hundreds to thousands of B2B companies, each with their own isolated sending domains and Google/Outlook Workspace inboxes. The stack includes a managed inbox provisioning vendor, a third-party cold email sequencer (API-integrated), and a custom domain pool management layer — all sitting behind our existing Node.js/TypeScript backend. This is a review engagement, not a build engagement. We are not looking for someone to implement the system — we need someone who has built or operated email infrastructure at scale to pressure-test our design before we commit engineering resources. ## What You'll Review - Domain and inbox provisioning architecture (per-company isolation, tenant separation, DNS configuration) - Sending volume model (per-inbox daily caps, inbox rotation, campaign delivery timelines) - Warmup strategy (pre-warmed vs cold inboxes, ramp schedules, warming network quality) - Deliverability architecture (inbox placement, tracking, bounce/complaint thresholds, remediation) - Risk model (Google Workspace suspension patterns, provider diversification, failover strategy) - Vendor selection rationale (managed inbox provider, sequencing platform, warming approach) - Cost model at 100, 500, and 1,000 company scale - Data flow between systems (provisioning handoff, webhook event processing, campaign lifecycle) ## Expected Output A written review document covering: - **Validation:** Does this architecture work? Will it achieve the deliverability, isolation, and scale targets described? - **Gaps:** What's missing? Are there failure modes, edge cases, or operational risks the document doesn't address? - **Suggestions:** What would you do differently? Are there better approaches to any component — vendor choices, volume model, warmup strategy, monitoring? - **Red flags:** Anything that will break at scale, violate provider terms, or cause deliverability problems that we haven't accounted for? We value direct, specific feedback over general advice. "Your bounce threshold should be 1.5% not 2% because Gmail's tolerance shifted in Q1 2026" is more useful than "make sure to monitor bounces." ## Required Experience - **Hands-on experience building or operating cold email infrastructure at scale** (500+ sending accounts, 100+ domains, sustained campaigns across multiple clients or tenants) - Deep understanding of **Google Workspace and Microsoft 365 sending limits, suspension triggers, and recovery processes** — specifically for cold email use cases, not just transactional - Working knowledge of **domain reputation mechanics** — how Gmail, Outlook, and Yahoo evaluate sending domains, how reputation builds and degrades, and how subdomain vs root domain reputation interacts - Familiarity with **cold email sequencing platforms** (Smartlead, Instantly, Saleshandy, or similar) and their API integration patterns - Experience with **managed inbox providers** (ScaledMail, Zapmail, Primeforge, or similar) — understanding of how pre-warmed inboxes work, tenant isolation models, and DNS provisioning - Understanding of **SPF, DKIM, DMARC** configuration for multi-domain setups - Familiarity with **email warmup mechanics** — warming networks, ramp schedules, health scoring ## Nice to Have - Experience designing email infrastructure for a SaaS platform (multi-tenant, API-driven provisioning) - Knowledge of deliverability monitoring tooling (Google Postmaster Tools, blacklist monitoring, inbox placement testing) - Experience with cost optimization at scale (inbox count reduction, per-inbox cap tuning, provider negotiation) ## Engagement Details - **Type:** One-time review engagement with a chance of being hired as a consultant depending on the review - **Estimated effort:** 10–15 hours depending on depth of review. - **Deliverable:** Written review document with findings, gaps, suggestions, and red flags - **Timeline:** Review completed within 5 business days of receiving the architecture document