Skip to content
BlogInfrastructure

Building Outbound Infrastructure That Actually Scales

An architecture-level look at isolation, redundancy, monitoring and rotation: the four principles that separate a fleet that scales from one that eventually collapses.

Diego FontainePrincipal Infrastructure Engineer
9 min read
On this page
  1. Isolation: contain the blast radius by design
  2. Redundancy: no single domain is load-bearing
  3. Monitoring: treat reputation like an SLO
  4. Rotation: retiring and replacing senders on a schedule
  5. Putting it together
  6. Architecture checklist

Most outbound infrastructure doesn't fail because of one bad decision. It fails because it was built as a pile of individually-reasonable choices with no architecture connecting them. Four principles separate a sending fleet that scales from one that eventually collapses under its own volume: isolation, redundancy, monitoring, and rotation.

Isolation: contain the blast radius by design

Every domain, and ideally every mailbox, should belong to a clearly bounded unit (a client, a campaign, or a product line) with no shared reputation across boundaries that don't need to share it. When isolation is designed in from the start, a reputation problem on one domain is a contained incident. When it isn't, a single flagged domain becomes an investigation that touches everything, because nobody can say with confidence what else might be affected.

Redundancy: no single domain is load-bearing

A client or campaign that depends entirely on one domain has a single point of failure baked into its outbound motion. The fix is straightforward but often skipped under time pressure: provision more than one domain per meaningful unit of sending from the start, and route around a paused or under-review domain automatically rather than manually re-pointing a sequencer mid-campaign.

Monitoring: treat reputation like an SLO

Reputation degrades quietly before it degrades visibly. Bounce rate creeps up two days before a blocklist listing shows up, and placement drops on one provider before it drops on others. Treating deliverability metrics with the same rigor as an uptime SLO (explicit thresholds, automated alerts, and a defined response) catches problems while they're still cheap to fix.

Example monitoring thresholds

domain_health:
  bounce_rate:
    warn: 0.02
    page: 0.05
  spam_complaint_rate:
    warn: 0.0005
    page: 0.001
  blocklist_check_interval: 6h
  placement_test_interval: 48h

Rotation: retiring and replacing senders on a schedule

Domains and mailboxes have a useful lifespan even when nothing goes wrong: engagement naturally decays as recipients become familiar with a sender identity. Scheduled rotation, where new domains are warming in the background well before older ones are retired, turns this into a non-event. Fleets that only replace a domain after it's already flagged are always operating at a deficit, replacing capacity under pressure instead of ahead of need.

Putting it together

A reference architecture has four layers: a domain pool, provisioned and DNS-configured ahead of need; a mailbox pool, sized against the isolation ratio described in the fleet-sizing math; a sending layer, which is whatever sequencer or outbound tool routes actual messages; and a monitoring layer, which watches every domain and mailbox continuously and feeds signals back into the sending layer to pause or reroute automatically rather than waiting for a human to notice.

LayerDomain pool

Responsibility
DNS, authentication, aging, reserve capacity
Failure mode it prevents
Running out of clean domains under pressure

LayerMailbox pool

Responsibility
Provisioning, warmup state tracking
Failure mode it prevents
Sending from under-warmed mailboxes

LayerSending layer

Responsibility
Routing, volume pacing
Failure mode it prevents
Uneven load concentrating risk on a few senders

LayerMonitoring layer

Responsibility
Health checks, alerting, automated pause/reroute
Failure mode it prevents
Slow human response to a fast-moving reputation issue

The core principle

Design for the domain you'll have to retire, not just the domain you're sending from today. Every piece of infrastructure that assumes a sender will last forever eventually gets rebuilt under pressure instead of on schedule.

Architecture checklist

  • No client or campaign depends on a single domain
  • Domain and mailbox pools carry 15 to 20% reserve capacity
  • Monitoring thresholds are explicit numbers, not judgment calls
  • Rotation is scheduled ahead of engagement decay, not triggered by it
  • A flagged domain can be paused and rerouted without manual sequencer changes
#infrastructure#architecture#scaling#monitoring

Written by

Diego Fontaine

Principal Infrastructure Engineer

Writes about email infrastructure and deliverability for the Infrabox blog, drawing on patterns seen across thousands of sending domains on the platform.

Try Infrabox

Put this into practice on your own fleet

Infrabox provisions domains, mailboxes and DNS in one pass, then warms and monitors every sender automatically, so the checklist runs itself.