Multi-Tenant ESP Architecture — IP Pools and Tenant Isolation

How platforms that send on behalf of many customers structure IP allocation, reputation isolation, and per-tenant enforcement. The patterns below are extracted from what AWS SES and Twilio SendGrid publicly document about their own architecture — treated here as design evidence for anyone running a multi-tenant sending platform, not as product tutorials. For the sender-side view of the same questions (how many IPs, which streams to separate), see Basic IP Allocation and Advanced IP Segmentation.

The three isolation layers

Mature platforms separate three concerns that are often conflated:

Layer	Isolates	Mechanism (vendor examples)
IP pool	IP reputation between mail streams (transactional vs marketing) or customer tiers	SES dedicated IP pools; SendGrid IP pools
Tenant / subuser	Customer-level reputation metrics, enforcement, and resources	SES tenants; SendGrid subusers
Suppression scope	Do-not-send data between customers	SES account/tenant/configuration-set suppression — see Suppression-List Architecture

A tenant is a logical container (metrics, policy, resource permissions); a pool is a physical routing decision (which IPs carry the mail). A tenant can send through shared IPs, a dedicated pool, or both.

IP pools: the routing primitive

Standard (self-managed) pools

Both SES and SendGrid model a pool as a named group of dedicated IPs, selected at send time:

• Canonical use case (both vendors): one pool for marketing, one for transactional, so a complaint-heavy campaign cannot degrade transactional delivery — the pool is the reputation boundary.
• Selection mechanism: SES binds a pool to a configuration set; the send names the configuration set (directly or via a default configuration set attached to the sending identity). SendGrid selects per message with an ip_pool_name parameter on the send call.
• Exclusive membership: in SES, an IP belongs to exactly one pool — assigning it to a new pool removes it from the previous one. Likewise a configuration set points at exactly one pool.
• Fallback behavior: in SendGrid, a send that names no pool "will use any IP available, including pooled addresses" — i.e. unpooled sends do not respect pool boundaries. Design implication: pool isolation is only as strong as the discipline of always specifying the pool.
• Deliberate shared-pool escape hatch: SES lets a configuration set route to the shared pool (IPs shared by all SES customers) — documented for "email that doesn't align with your usual sending behaviors," i.e. atypical sends you don't want touching your dedicated reputation. This is the same reasoning as routing risky one-off sends away from prime IPs (see Mandated & Regulatory Email).

Documented limits: SES — max 50 dedicated IP pools per account per region (managed + standard combined); pool names unique across both pool types. SendGrid — up to 100 IP pools per user; pool name max 64 characters; dedicated IPs must have reverse DNS configured and be activated before pool assignment; IP pools require higher-tier plans (Pro/Premier Email API or Advanced Marketing Campaigns).

Managed (auto-warmed) pools — the SES "dedicated IPs (managed)" pattern

SES's managed pools document what an automated pool-management layer looks like. The architecture points, all directly stated by AWS:

• Automatic IP count scaling. The platform decides how many dedicated IPs the pool needs from observed sending patterns and scales the count up and down. Scaling is per-ISP aware: if a receiving ISP enforces a low per-IP daily quota, the pool scales out to spread that ISP's traffic across more IPs.
• Per-ISP warm-up state. Warm-up level is tracked per IP per receiving ISP, not globally. An IP that has sent only to Gmail is warm for Gmail and cold for Hotmail; ramping up Hotmail traffic restarts a gradual ramp for Hotmail only. (Compare the manual per-provider schedules in IP Warm-Up.)
• Adaptive warm-up, including decay. Warm-up percentage drops when volume to an ISP drops — warmth is treated as perishable, not a one-time achievement.
• Shared-pool overflow during warm-up. In early warm-up, volume exceeding the current warmed capacity spills over to the platform's shared IP pool rather than being sent cold (protecting the new IPs' reputation). In later warm-up stages, excess is instead queued, slowed, and retried later through the dedicated IPs. Even fully warmed pools are not guaranteed 100% dedicated routing: a sudden volume spike triggers allocation of an additional IP, whose warm-up again uses the shared pool.
• Demotion on low volume. If a sender with one dedicated IP falls below the minimum volume needed to maintain IP reputation, the platform removes the dedicated IP and routes everything through the shared pool. AWS's stated threshold for allocating the first dedicated IP: sending volume reaching "hundreds of emails over a period of a few days"; below "a few hundred per day" AWS steers senders to shared IPs outright. This is the lowest of the published dedicated-IP minimums; for how it compares to other vendors' house-rules and to the general per-IP statistical floor, see the canonical dedicated-IP volume floors table.
• One-way promotion. A standard pool can be converted to managed, but a managed pool cannot be converted back to standard. On conversion, redundant IPs (more than the volume justifies) are removed — AWS explicitly warns not to convert IPs that appear on external allow-lists, because they may be relinquished. Configuration sets and tags carry over.
• Billing model shift: standard dedicated IPs are billed per IP; managed pools are billed on volume sent through the pool. Deleting the last managed pool relinquishes all its IPs and stops charges immediately.
• Constraint: with managed dedicated IPs, an SES account is limited to 10,000 sending identities per region.
• Shared responsibility caveat (AWS's own framing): "managed" covers scaling and warm-up mechanics only. The customer remains responsible for reputation outcomes — bounce rates, complaint rates, and most blocklist (RBL) delisting requests.

Pool lifecycle summary (the promotion/demotion ladder these designs imply): shared pool → first dedicated IP (volume threshold reached) → pool scales out per ISP demand → pool scales in / IP relinquished when volume drops → back to shared pool. Overflow to shared IPs is the shock absorber at every transition.

Tenant isolation and per-tenant reputation (SES tenant model)

SES tenants are the most explicit public documentation of customer-level isolation inside one sending platform. The stated motivation is exactly the ESP problem: previously "one customer's poor email practices could pause an entire SES account, affecting all other customers."

Structure

• A tenant is a logical container grouping verified identities (domains/addresses), configuration sets, and templates. Target users: ISVs sending for many customers, enterprises with business units, service providers isolating by client or application, and per-tenant regulatory regimes.
• Resource assignment is either dedicated (one tenant) or shared (multiple tenants). Every send in tenant context is validated: the identity, configuration set, and template must all be associated with the named tenant or the send fails. Resources associated with a tenant cannot be deleted until disassociated.
• Send attribution: the tenant is named per send — an API parameter (TenantName) or, over SMTP, a message header (X-SES-TENANT: <name>). A configuration set associated with the tenant is required on every tenant send (directly or as the identity's default).
• Flat and regional: tenants cannot nest, cannot span AWS accounts, and are per-region (multi-region senders configure and monitor tenants in each region separately).
• Scale limits: 10,000 tenants per account by default; increases auto-approved up to 300,000 for qualifying accounts. Priced per tenant per month based on email volume.

Per-tenant reputation tracking

Per tenant, the platform continuously tracks: bounce rate, complaint rate (including mailbox-provider FBL complaints), third-party feedback signals from mailbox providers, and appearances of sending IPs on reputation blocklists. Threshold breaches create reputation findings at two severities:

• Low severity — minor issues that could affect deliverability if unaddressed.
• High severity — serious issues likely already affecting deliverability; may trigger enforcement.

Findings carry type (BOUNCE, complaint, third-party feedback, blocklist), impact, description with the triggering rate and sample, and remediation links. Example from AWS's own docs of finding granularity: "The bounce rate exceeded 15.0% based on a representative volume of 664 emails" over a ~2-hour window — i.e. findings fire on rolling representative samples, not calendar-month aggregates. Metrics are computed over rolling windows of roughly 24 hours to 7 days depending on metric type, and some findings require a minimum representative volume before they can trigger.

Per-tenant metrics (Sends, Bounces, Complaints) are published to the monitoring system dimensioned by tenant, and tenant status changes / findings are emitted as events (EventBridge detail-types: Sending Status Enabled/Disabled, Advisor Recommendation Status Open/Closed) so the platform operator can automate alerting and response.

Automated enforcement: reputation policies

Each tenant gets a reputation policy deciding when the platform auto-pauses it:

Policy	Behavior	AWS guidance
Standard (default)	Pause tenant sending on high-severity findings	Recommended balance for most tenants
Strict	Pause on any finding, including low-severity	For high-risk tenants or repeat offenders
None	Never auto-pause; findings still recorded	Only for monitored onboarding; carries Trust & Safety risk

Tenant sending status values: Enabled, Paused (manual or policy), Enforced (platform Trust & Safety paused it for serious reputation issues), Reinstated (reactivated after a pause). Key semantics:

• A paused tenant's sends fail until an operator reviews and manually re-enables — resumption is deliberately human-gated.
• Reinstated grace period: after re-enabling, active findings are temporarily ignored so the tenant can recover; the tenant stays in Reinstated until all findings resolve. (Prevents an immediate re-pause loop.)
• Scoped upstream enforcement: when AWS Trust & Safety detects abuse, it can pause only the offending tenant instead of the whole account — tenant structure converts account-level enforcement into surgical enforcement, with a support case opened for remediation.
• Aggregate liability remains: AWS states explicitly that tenants' combined activity still affects the overall account reputation — isolation limits blast radius but does not launder bad traffic. The account owner is responsible for monitoring all tenants.

AWS's stated operating practices for tenant fleets

• Start tenants on Standard policy; apply Strict to high-risk or previously-offending tenants.
• Onboard new tenants under None with event monitoring to observe patterns before enabling auto-enforcement.
• Alert on findings (via events) so operators act before automated pausing.
• Review tenant metrics routinely even without findings, to catch emerging patterns.
• Educate tenants on sending best practices; shape tenant granularity to the business (per customer, per business unit, per application type, per regulatory regime).

Design lessons for an ESP

Reading the vendor architecture as a blueprint:

1. Separate logical tenancy from physical IP routing. Reputation metrics, suppression scope, and enforcement attach to the tenant; IPs attach to pools; a routing object (configuration set / ip_pool_name) binds them per send.
2. Per-tenant metrics with automated pause policies are the mechanism that keeps one bad customer from burning shared infrastructure — with severity tiers, human-gated resumption, and a grace period after reinstatement. This is the platform-side complement of the sender-side thresholds in Metrics & Benchmarks.
3. The shared pool is load-bearing, not just an entry-level product: it absorbs warm-up overflow, sudden spikes, low-volume demotions, and deliberately-routed atypical sends. A multi-tenant platform without a healthy shared pool has no shock absorber — which is why shared-pool policing (vetting, enforcement) matters so much.
4. Warm-up state belongs per IP × per receiving ISP, and it decays. Automating pool scaling requires modeling each ISP's acceptance capacity separately (see IP Warm-Up).
5. Isolation has a floor: the platform's account (the ESP itself, from its upstream/peers' point of view) is still judged on aggregate traffic. Tenant isolation is blast-radius control, not absolution.

Suppression scoping — the third isolation layer — is covered in Suppression-List Architecture.