Multi-Domain High-Volume Email Infrastructure

Background

The requirement was straightforward on paper: hundreds of inboxes across multiple domains, high-volume outbound capability, built from scratch. The execution was anything but.

Starting a new domain and immediately sending at volume is one of the fastest ways to get blacklisted. Email providers track reputation by domain and IP — a domain with no history that suddenly sends thousands of emails looks exactly like a spam operation. Building real, scalable email infrastructure means careful domain architecture, structured warmup, and the patience to let reputation build before pushing volume.

Anil Choudhary led the architecture design, provisioning automation, and warmup implementation across the full infrastructure.

The Challenge

Scale and Segmentation Requirements

The scale of the requirement made manual configuration impractical:

• Hundreds of inboxes needed across a set of domains
• Different use cases required different sending profiles (high-volume vs. standard, different sender identities)
• No single domain should carry all volume — concentrating sending on one domain creates a single point of reputation failure
• Each domain needed full email authentication (SPF, DKIM, DMARC) configured correctly from day one

Without a systematic approach, configuring each domain manually would have taken weeks and produced inconsistent results.

Blacklisting Risk

The biggest risk with new infrastructure is blacklisting:

• Cold domains have no sending history and no established reputation
• Sending at volume too quickly from a new domain triggers spam filters at major providers
• Once a domain is blacklisted, remediation is time-consuming and not guaranteed
• A blacklisted domain in the infrastructure would affect deliverability for all email sent from associated domains

A structured warmup process was non-negotiable.

Centralized Management Gap

With many domains and hundreds of inboxes, operational management without centralization becomes unworkable:

• No single view of all domains, their status, and their sending performance
• DNS changes, DKIM rotation, and quota adjustments would need to be made individually per domain
• Monitoring deliverability and spam rates across hundreds of inboxes with no tooling would require constant manual effort

Architecture

Domain Segmentation Strategy

Domains were segmented by purpose and sending profile to isolate reputation:

No single domain was used for all sending. If any sending pool domain accumulated negative reputation, it could be rotated out without affecting the primary or transactional domains.

DNS and Authentication Configuration

Each domain received the full email authentication stack before any sending began:

# Per-domain DNS configuration template

# MX Records
@    MX  10  mail.provider.example
@    MX  20  mail2.provider.example

# SPF — scoped strictly to authorized senders
@    TXT  "v=spf1 include:smtp-relay.example.com ip4:[sending-ip] -all"

# DKIM — 2048-bit key per provider
selector1._domainkey   CNAME  selector1-domain._domainkey.provider.com
selector2._domainkey   CNAME  selector2-domain._domainkey.provider.com

# DMARC — monitoring first, then enforce
_dmarc    TXT  "v=DMARC1; p=none; rua=mailto:dmarc@management.example.com; pct=100"

# Return Path (improves reputation signalling)
bounces  CNAME  custom.bounce.provider.com

Authentication configuration was templated and applied programmatically across all domains, eliminating manual configuration variance.

Mailbox Provisioning Automation

Rather than creating inboxes manually through the email provider's web interface, provisioning was automated via API:

import requests
import json

def provision_mailbox(domain: str, username: str, display_name: str) -> dict:
    """Create mailbox via provider API"""
    payload = {
        "email": f"{username}@{domain}",
        "display_name": display_name,
        "password": generate_secure_password(),
        "smtp_relay": True,
        "sending_limit_per_day": get_domain_limit(domain)
    }
    response = requests.post(
        f"{PROVIDER_API_BASE}/mailboxes",
        headers={"Authorization": f"Bearer {API_KEY}"},
        json=payload
    )
    return response.json()

def bulk_provision(domain: str, user_list: list[dict]) -> list[dict]:
    results = []
    for user in user_list:
        result = provision_mailbox(domain, user["username"], user["name"])
        results.append({"email": result["email"], "status": result["status"]})
    return results

Mailbox configuration — daily sending limits, SMTP relay settings, forwarding rules — was applied uniformly via the same API, ensuring consistent settings across all inboxes.

Warmup System

The warmup process was the most operationally critical phase. A new domain's sending volume was increased gradually over 4–6 weeks, starting with small amounts and building toward target volume only after demonstrating consistent delivery and engagement:

Warmup Schedule (per domain)

Key rules applied throughout warmup:

• Bounce rate kept below 2% — high bounces signal list quality problems to receiving servers
• Spam complaint rate kept below 0.1% — exceeding this triggers deliverability penalties
• Hard bounces removed from lists immediately — sending to invalid addresses is heavily penalized
• Sending spread across business hours rather than bulk-sent at a single time

Throttling Implementation

Sending was throttled programmatically to stay within warmup limits:

import time
from collections import defaultdict

class DomainThrottler:
    def __init__(self):
        self.daily_counts = defaultdict(int)
        self.hourly_counts = defaultdict(int)
    
    def can_send(self, domain: str, warmup_week: int) -> bool:
        daily_limit = self.get_daily_limit(warmup_week)
        hourly_limit = daily_limit // 12  # Spread across 12 active hours
        
        if self.daily_counts[domain] >= daily_limit:
            return False
        if self.hourly_counts[domain] >= hourly_limit:
            return False
        return True
    
    def record_send(self, domain: str):
        self.daily_counts[domain] += 1
        self.hourly_counts[domain] += 1
    
    def get_daily_limit(self, week: int) -> int:
        limits = {1: 50, 2: 200, 3: 1000, 4: 5000, 5: 10000, 6: 25000}
        return limits.get(week, 25000)

Relay and API Integration

Outbound email was routed through a professional SMTP relay service rather than direct IP sending. This provided:

• Dedicated IP pools with established reputation
• Automatic bounce handling and list management
• Deliverability analytics per domain (inbox placement, open rates, bounce rates)
• IP rotation to distribute volume across multiple sending IPs

The relay service was integrated via API, allowing programmatic management of:

• Suppression lists (automatic and manual)
• Domain-level sending statistics
• Reputation monitoring alerts
• DKIM selector rotation

Centralized Management Dashboard

A management layer was built on top of the provider APIs to give a single operational view:

• All domains and their current sending status
• Real-time bounce and complaint rates per domain with threshold alerts
• Mailbox inventory with last-activity timestamps
• Warmup progress tracking per domain
• Blacklist monitoring: automated daily checks against major RBL providers for all sending IPs and domains

Alerts were configured to fire immediately if any domain's bounce rate exceeded 2% or complaint rate exceeded 0.08% — giving time to investigate and correct before reputation damage accumulated.

Results

All domains hit target sending volume within the six-week warmup window. Zero blacklisting incidents throughout. The domain segmentation strategy means that if any future issue develops with one sending pool, it can be isolated and managed without touching the business-critical communication domains. The infrastructure is built to absorb problems without cascading.