---
title: Amazon SES Tenant Management: The Ultimate Enterprise Guide
description: SES tenants (GA Aug 2025) add $0.005/tenant/mo reputation isolation—when ISV platforms need them vs configuration sets alone, with IAM, pricing, and IaC.
url: https://www.factualminds.com/blog/amazon-ses-tenant-management-enterprise-guide/
datePublished: 2026-07-07T00:00:00.000Z
dateModified: 2026-07-07T00:00:00.000Z
author: palaniappan-p
category: Email Deliverability
tags: amazon-ses, email-deliverability, aws-ses, multi-tenant, engineering-guide
---

# Amazon SES Tenant Management: The Ultimate Enterprise Guide

> SES tenants (GA Aug 2025) add $0.005/tenant/mo reputation isolation—when ISV platforms need them vs configuration sets alone, with IAM, pricing, and IaC.

On **August 1, 2025**, AWS [shipped tenant management in Amazon SES](https://aws.amazon.com/about-aws/whats-new/2025/08/amazon-ses-tenant-isolation-automated-reputation-policies/)—logical containers inside a single SES account where reputation metrics, automated pause policies, and (optionally) suppression lists apply **per tenant** instead of only at account level. Tenant-level suppression lists followed in **2026**, letting platforms isolate bounce and complaint suppressions per downstream customer.

If you run email for multiple retailers, business units, or SaaS customers from one SES account, that date matters more than any feature bullet list. Before tenants, one customer's complaint spike could pause **your entire account**. After tenants, AWS can pause **one tenant** while others keep sending—provided your architecture actually uses the feature.

This guide is for CTOs, platform engineers, and email infrastructure leads deciding whether to adopt tenants, how they compare to configuration sets and multi-account designs, and how to implement them without breaking production sends.

## Executive Summary

**Amazon SES tenants** are regional logical containers that group identities, configuration sets, and templates, with independent reputation metrics and automated enforcement policies. They are **not** separate AWS accounts, **not** a deliverability magic switch, and **not** a replacement for configuration sets.

| Question           | Short answer                                                                                                                                                                                                       |
| ------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| Who needs tenants? | ISVs, MSPs, multi-brand enterprises, and any platform sending on behalf of many downstream entities in **one** SES account                                                                                         |
| Who can skip?      | Single-brand senders, low-volume apps, teams already using strict per-customer AWS account isolation                                                                                                               |
| Extra AWS cost?    | **$0.005/tenant/month** + **$0.005/1,000 tenant-tagged emails** (AWS fact, [SES pricing](https://aws.amazon.com/ses/pricing/))                                                                                     |
| Minimum to send?   | Verified identity + configuration set **associated** to the tenant; `TenantName` on API or `X-SES-TENANT` on SMTP                                                                                                  |
| Our recommendation | Use **configuration sets + tenants** together on ISV platforms with **50+** downstream senders; enable **tenant-level suppression** wherever one customer's complaints must not block another's transactional mail |

## Introduction

Enterprise email operations face a tension that configuration sets alone never fully resolved: **operational separation** versus **reputation blast radius**.

Configuration sets excel at separating **streams**—marketing vs transactional, dedicated IP pools, event destinations, tracking domains. They do **not** give AWS a first-class object to pause when **one downstream customer** misbehaves while leaving others untouched.

### Enterprise email challenges

- **Shared reputation risk:** Account-level bounce and complaint enforcement protects recipients but punishes compliant senders on the same account.
- **Governance at scale:** Hundreds of customers in one ISV platform need IAM boundaries, not just application-level `customer_id` columns.
- **Suppression bleed:** Before tenant-level suppression, a complaint against Customer A could suppress that address for **every** tenant in the account.
- **Operational visibility:** Per-customer metrics buried in custom dashboards are slower than native tenant metrics in CloudWatch and EventBridge.

### Why AWS introduced tenant management

AWS messaging teams documented the gap explicitly: configuration sets isolate **configuration**, but reputation enforcement historically occurred at **account** level. Tenants add **reputation isolation**—metrics, findings, pause policies, and Trust & Safety targeting—without forcing every ISV to provision a separate AWS account per customer.

## What Is Amazon SES Tenant Management?

### Definition and AWS terminology

A **tenant** is a named logical container (`TenantName`, up to 64 alphanumeric characters with hyphens and underscores) inside one SES account in one Region. Each tenant receives:

- Its own **reputation metrics** (sends, bounces, complaints in CloudWatch)
- **Reputation findings** (low and high severity)
- **Sending status** (Enabled, Paused, Enforced, Reinstated)
- Optional **tenant-level suppression list** (`SuppressionScope: TENANT`)

**Associable resources (AWS fact):** verified identities, configuration sets, and email templates—either dedicated per tenant or shared across tenants.

**Not supported:** nested tenants, cross-account tenants, or cross-Region tenant objects.

### Tenant lifecycle and sending status states

Typical lifecycle:

1. **CreateTenant** — optionally set suppression attributes
2. **CreateTenantResourceAssociation** — link identity and configuration set (minimum for sending)
3. **Send** with `TenantName` / `X-SES-TENANT`
4. Monitor findings → automatic or manual **pause**
5. Remediate → **reinstate** (grace period ignores active findings temporarily)
6. **DeleteTenantResourceAssociation** → **DeleteTenant** on offboard

### Supported features and current limitations

| Capability                        | Status                                                   |
| --------------------------------- | -------------------------------------------------------- |
| SES V2 API + console              | GA all commercial SES Regions (Aug 2025)                 |
| Default quota                     | 10,000 tenants/account; up to 300,000 via Service Quotas |
| CloudFormation `AWS::SES::Tenant` | Supported                                                |
| Reputation policies               | Standard, Strict, None                                   |
| EventBridge notifications         | Status changes + reputation findings                     |
| Regional scope                    | Per-Region; no automatic replication                     |
| Contact lists                     | Account-level; not tenant-associable                     |

See architecture diagram: [`docs/ses-tenant-management-core-architecture.drawio`](https://github.com/factualminds/factualminds-astro/blob/main/docs/ses-tenant-management-core-architecture.drawio) (repo path).

## Why AWS Introduced Tenants

| Stakeholder             | Problem tenants address                                                         |
| ----------------------- | ------------------------------------------------------------------------------- |
| **SaaS / ISV**          | Send for hundreds of customers; isolate rogue sender without account-wide pause |
| **Enterprise multi-BU** | Marketing vs corporate vs subsidiary brands under one AWS bill                  |
| **Multi-brand retail**  | Separate reputation per brand domain in one account                             |
| **MSP**                 | Managed email with per-client enforcement and reporting                         |
| **Shared AWS account**  | Reduce pressure to spin up N accounts purely for SES isolation                  |

Tenants do **not** remove your obligation to monitor all downstream senders. AWS documentation states that combined tenant activity still affects overall account standing.

## How Tenant Management Works

### Resource association model

Resources attach via `CreateTenantResourceAssociation`. On each send, SES validates that the **identity**, **configuration set**, and **template** (if used) are associated with the specified tenant. Mismatches **fail the send**.

Dedicated assignment: one identity per customer. Shared assignment: common IP pool config set across tenants—higher operational risk, lower cost.

### Sending flow and validation

**API (AWS CLI v2.28.0+, SESv2):**

```bash
# Assumes: AWS CLI 2.28.0+, identity and config set pre-associated to tenant
aws sesv2 send-email \
  --tenant-name "retailer-01" \
  --from-email-address "noreply@retailer.example.com" \
  --destination "ToAddresses=shopper@example.org" \
  --configuration-set-name "retailer-01-cs" \
  --content 'Simple={Subject={Data=Order shipped,Charset=utf-8},Body={Text={Data=Your order is on the way.,Charset=utf-8}}}' \
  --region us-east-1
```

**SMTP:** include header `X-SES-TENANT: retailer-01` plus `X-SES-CONFIGURATION-SET`.

Sequence: app → tenant validation → config set (IP pool, events) → delivery → tenant-scoped metrics.

### Reputation findings and enforcement

| Policy                 | Behavior (per AWS implementation guide)                |
| ---------------------- | ------------------------------------------------------ |
| **Standard** (default) | Pause on **high** severity: bounce >15%, complaint >1% |
| **Strict**             | Pause on **any** finding: bounce >10%, complaint >0.5% |
| **None**               | Record findings only; no auto-pause                    |

Findings types include bounces, complaints, third-party feedback, and blocklist appearances. Paused tenants reject sends until remediated and re-enabled.

### IAM, EventBridge, and CloudWatch integration

- **IAM:** `ses:TenantName` condition keys scope send and suppression APIs to specific tenants. Separate **tenant admin** roles (create/associate/pause) from **sender** roles (send-only for one tenant). See policy templates in `examples/ses-tenant-management/iam/`.
- **CloudWatch:** `AWS/SES` namespace, dimensions `TenantId` and `TenantName`—metrics include Sends, Bounces, Complaints per tenant. Basic tenant metrics included without extra SES charge.
- **EventBridge:** Default bus receives `Sending Status Enabled/Disabled` and `Advisor Recommendation Status Open/Closed`. Pattern in `examples/ses-tenant-management/eventbridge/tenant-reputation-rule.json`.

#### Sequence: tenant send validation

1. Application calls `SendEmail` with `TenantName`, `ConfigurationSetName`, and `FromEmailAddress`
2. SES resolves tenant record and checks sending status (Enabled vs Paused)
3. SES verifies identity ARN is associated with tenant
4. SES verifies configuration set ARN is associated with tenant
5. If template specified, SES verifies template association
6. SES applies suppression check against tenant or account list per `SuppressionScope`
7. Email enters sending pipeline (config set → IP pool → delivery)
8. Metrics increment under tenant dimensions; events route to config set destinations
9. If reputation thresholds breached later, findings appear → optional auto-pause → EventBridge notification

For SMTP, step 1 uses `X-SES-TENANT` and `X-SES-CONFIGURATION-SET` headers instead of API parameters—the validation path is identical.

#### Trust & Safety interaction

When AWS Trust & Safety would historically pause an entire account, tenant isolation allows **targeted** tenant pause while compliant tenants continue. Account owners still receive Support cases for high-severity issues and remain responsible for all tenants' practices.

## SES Resource Association Matrix

| SES resource              | Tenant-associable     | Regional | Sharable across tenants | Notes                                    |
| ------------------------- | --------------------- | -------- | ----------------------- | ---------------------------------------- |
| Email/domain identities   | Yes                   | Yes      | Optional                | Delete blocked while associated          |
| Configuration sets        | Yes                   | Yes      | Optional                | **Required** on tenant sends             |
| Templates                 | Yes                   | Yes      | Optional                | Validated at send time                   |
| Dedicated IP pools        | Via config set        | Yes      | Optional                | Not directly linked to tenant            |
| Event destinations        | Via config set        | Yes      | Per config set          | SNS, Firehose, CloudWatch                |
| VDM                       | Account feature       | Yes      | Account-wide            | Doubles message charges when enabled     |
| Suppression lists         | Scope per tenant      | Yes      | Default: account shared | Set `SuppressionScope: TENANT` at create |
| Contact lists             | No                    | Yes      | Account                 | Manage at account level                  |
| MAIL FROM / DKIM          | On identity           | Yes      | Per identity            | Inherited via identity                   |
| Sending authorization     | Identity-level        | Yes      | —                       | Orthogonal to tenant RBAC                |
| IAM                       | —                     | —        | —                       | `ses:TenantName` conditions              |
| CloudWatch tenant metrics | Per tenant            | Yes      | —                       | Sends, Bounces, Complaints               |
| SNS                       | Via config set events | Yes      | —                       | Not a native tenant resource             |
| EventBridge               | Tenant events         | Yes      | Default bus             | Automate pause response                  |

## Tenant Management vs Configuration Sets

| Dimension           | Configuration sets                   | Tenants                                    |
| ------------------- | ------------------------------------ | ------------------------------------------ |
| **Primary purpose** | Stream config: IPs, tracking, events | Reputation isolation + enforcement         |
| **Isolation**       | Logical send pipeline                | Reputation metrics + pause boundary        |
| **Reporting**       | Per config set events                | Per tenant metrics + findings              |
| **IAM**             | Resource ARNs on identity/config set | + `ses:TenantName`                         |
| **Ops complexity**  | Moderate                             | Higher (lifecycle, policies, associations) |
| **Best together?**  | Yes for ISV platforms                | Tenants without config sets are incomplete |

**FactualMinds recommendation:** Configuration sets separate **how** email is sent (IP pool, event routing). Tenants separate **who** is accountable when reputation breaks. Use both.

## Tenant Management vs Multiple AWS Accounts

| Dimension              | SES tenants (single account) | Separate AWS accounts                       |
| ---------------------- | ---------------------------- | ------------------------------------------- |
| **Security isolation** | Logical                      | Stronger (account boundary)                 |
| **Cost**               | Lower base; tenant fees      | Higher (account overhead, duplicated infra) |
| **Governance**         | Central ops; tenant RBAC     | Landing zone / SCP complexity               |
| **Compliance**         | Shared audit boundary        | Easier regulatory separation                |
| **Scalability**        | Up to 300k tenants           | Account limits apply                        |
| **Automation**         | SES APIs, CloudFormation     | Control Tower, StackSets                    |
| **Enterprise fit**     | ISV scale in one bill        | Banking/gov per-tenant accounts             |

See [`aws-multi-account-strategy-landing-zone-best-practices`](/blog/aws-multi-account-strategy-landing-zone-best-practices/) for account-perimeter patterns.

## Tenant Management vs Application-Level Multi-Tenancy

Your application database and RBAC still own **customer data**, billing, and UI. Tenants own **SES-side enforcement**.

| Layer              | Owns                                              |
| ------------------ | ------------------------------------------------- |
| App DB + RBAC      | Customer records, permissions, content            |
| Configuration sets | IP pools, event pipelines, tracking               |
| Tenants            | SES reputation boundary, pause, suppression scope |
| AWS accounts       | Hard multi-tenant isolation                       |

**Hybrid (typical ISV):** `customer_id` in app → maps to `TenantName` → IAM role per tenant or shared role with `ses:TenantName` condition.

## When to Use Tenant Management

| Profile                           | Recommendation                                       |
| --------------------------------- | ---------------------------------------------------- |
| Startup, single product           | Skip tenants                                         |
| SMB, one brand                    | Config sets only                                     |
| Growing SaaS (under 50 customers) | Config sets; plan tenants                            |
| Enterprise SaaS / ISV             | **Tenants + config sets**                            |
| Multi-brand retail                | Tenants per brand                                    |
| Banking / healthcare / gov        | Tenants **or** account isolation based on compliance |
| MSP / marketing platform          | Tenants per client                                   |
| Transactional-only platform       | Tenants if multiple downstream senders               |

> **From a real engagement (architecture shape)** — A marketing-automation platform at [TargetBay scale](/case-study/aws-ses/) (200M+ emails/month, multi-retailer roster) is the canonical tenant candidate: configuration sets separate transactional vs promotional streams; **one tenant per retailer** contains complaint spikes; tenant-level suppression prevents one retailer's holiday bounce storm from suppressing addresses for the rest of the roster. This is an architecture recommendation—not a claim that tenant migration already occurred.

## When to Avoid Tenant Management

- **Single brand, single application** — overhead exceeds benefit
- **Strict account-per-customer already in place** — tenants add little
- **Low volume (under 100k/mo total)** — manual monitoring suffices
- **Custom portal is the only governance layer** — without SES API integration, tenants become shelfware
- **Teams unwilling to migrate to SESv2** — tenant APIs do not exist in v1

## Pricing and Total Cost of Ownership

### AWS tenant charges (fact)

From [SES pricing](https://aws.amazon.com/ses/pricing/):

- **$0.005 per tenant per month**
- **$0.005 per 1,000 emails** sent through tenants
- Plus standard outbound email ($0.10/1,000), attachments, dedicated IPs, VDM surcharges as applicable

CloudWatch basic tenant metrics incur **no additional SES charge** (AWS fact). Custom dashboards, alarms, and detailed monitoring bill at standard CloudWatch rates.

### TCO beyond AWS line items

| Cost driver           | Startup       | Mid-market ISV        | Enterprise            |
| --------------------- | ------------- | --------------------- | --------------------- |
| SDK/API migration     | 1–2 eng-weeks | 2–4 eng-weeks         | 4–8 eng-weeks         |
| IAM policy refactor   | Low           | Medium                | High (central IdP)    |
| Onboarding automation | Manual OK     | Lambda required       | Full pipeline + audit |
| Ops runbooks          | Ad hoc        | EventBridge + on-call | 24/7 pause response   |
| Training              | 4 hours       | 1 day                 | Multi-team workshops  |

For a 200-customer ISV, AWS tenant fees at 1M emails/customer/month are roughly **$1/month per customer** in tenant surcharges alone ($1.00 customer fee = $0.005 base + ~$0.005 email share at 1M emails across 200 tenants)—**engineering and ops labor dominate** the first-year TCO.

### TCO examples (AWS math only)

Assume 1M tenant-tagged emails/month per scenario (excluding base send fees):

| Tenants | Monthly tenant fee | Tenant email fee | Tenant subtotal |
| ------- | ------------------ | ---------------- | --------------- |
| 10      | $0.05              | $5.00            | **$5.05**       |
| 100     | $0.50              | $5.00            | **$5.50**       |
| 1,000   | $5.00              | $5.00            | **$10.00**      |
| 10,000  | $50.00             | $5.00            | **$55.00**      |

Implementation TCO dominates at small scale: SDK upgrades, IAM redesign, onboarding automation, and EventBridge runbooks often exceed AWS tenant line items for the first year.

## Pre-Adoption Considerations

### IAM and RBAC

Map organizational roles before creating tenants:

| Role           | Permissions                                     | Typical owner              |
| -------------- | ----------------------------------------------- | -------------------------- |
| Tenant admin   | CreateTenant, associations, policy updates      | Platform team              |
| Tenant sender  | SendEmail + `ses:TenantName`                    | Application workload       |
| Tenant auditor | GetTenant, ListRecommendations, CloudWatch read | Security / compliance      |
| Account owner  | Full SES + Support                              | Cloud center of excellence |

Never attach admin policies to application credentials. Rotate SMTP credentials per tenant when customers receive dedicated SMTP users.

### Resource ownership

Document which team owns identity DNS (customer vs platform), configuration set design (central vs delegated), and pause/reinstate authority (ops vs customer success). Ambiguity here delays reinstatement after false-positive findings.

### Configuration Sets and domains

Every tenant send requires a configuration set associated to that tenant. If the identity has a default configuration set, it must still be associated via tenant resource linkage. Domain verification (DKIM, MAIL FROM) remains at the identity level—tenants do not replace DNS work documented in [SES migration guides](/blog/how-to-migrate-from-sendgrid-to-amazon-ses/).

### VDM and reporting

Virtual Deliverability Manager operates at **account** level. Enabling VDM doubles per-message charges for analyzed sends. Tenant metrics in CloudWatch complement—but do not replace—VDM inbox placement dashboards for domain-level insight.

### Monitoring and operational overhead

Budget on-call time for `Sending Status Disabled` events. Each pause may require customer outreach, list hygiene fixes, and reinstatement approval. Automate notification via EventBridge; do not rely on console polling.

### Migration effort

Expect 2–8 engineering weeks for mature ISV platforms depending on send path count (API, SMTP, batch workers), suppression Lambda branches, and IAM centralization. Use the migration checklist in the implementation section.

### Compliance and disaster recovery

Tenants do not encrypt email or store message bodies. GDPR, CAN-SPAM, and industry rules still apply per customer relationship. DR plans must address Regional SES outages—tenants do not replicate across Regions automatically.

### Infrastructure as Code

`AWS::SES::Tenant` supports `ResourceAssociations` and `Tags` at create time. Suppression attributes may require API/CLI if not yet in your CloudFormation resource type version—validate in target Region before pipeline commit.

### Regional behavior

Create tenant inventory per Region. A customer failover from `us-east-1` to `us-west-2` requires duplicate tenants, associations, and IAM updates. Global Endpoints (MREP) address send resilience separately—see `docs/aws-ses-mrep-tenants-combined.drawio` in this repository.

## Advantages of Tenant Management

- Logical reputation isolation within one account
- Automated pause per tenant (Standard/Strict policies)
- Native per-tenant CloudWatch metrics
- IAM simplification via `ses:TenantName`
- Tenant-level suppression (2026)
- EventBridge integration for ops automation
- Scales to thousands of tenants without N AWS accounts
- Cleaner offboarding (delete associations, then tenant)

## Limitations and Downsides

> **Warning** — Tenants **do not** improve inbox placement by themselves. They contain blast radius when reputation degrades.

- Regional only; multi-Region = duplicate work
- Migration complexity from config-set-only designs
- Sends fail if associations or `TenantName` missing
- Account-level reputation risk remains (AWS fact)
- Minimum volume thresholds before some findings trigger
- Reinstated grace period can mask lingering issues
- Vendor pattern lock-in to SESv2 tenant model
- Extra AWS and engineering cost vs config sets alone

> **What broke** — A platform running 40 retailers on shared account-level suppression saw transactional password resets blocked for 39 retailers after one retailer's promotional list imported dead addresses. Complaint processing called `PutSuppressedDestination` without `TenantName`. Fix: enable `SuppressionScope: TENANT` at tenant creation and pass `--tenant-name` on all suppression API calls. Detection: sudden cross-customer send volume drop in app metrics while SES account status stayed healthy.

## Enterprise Implementation Guide

### Planning and tenant model design

1. Inventory customers/BUs → candidate `TenantName` (stable, not display name)
2. Map identities and config sets per tenant
3. Choose reputation policy per tier (Strict for new, Standard for mature)
4. Define pause → notify → remediate → reinstate runbook

### IAM, identity onboarding, configuration sets

> **Reproduce this** — Clone [`examples/ses-tenant-management/`](https://github.com/factualminds/factualminds-astro/tree/main/examples/ses-tenant-management). Set `AWS_REGION`, `TENANT_NAME`, `IDENTITY_ARN`, `CONFIG_SET_ARN`, then run `./scripts/onboard-tenant.sh`. CloudFormation and IAM policy templates included.

Naming convention example: `{customer_slug}-tenant`, `{customer_slug}-cs`, domain identity per customer.

### Monitoring, testing, rollout, rollback

- Deploy EventBridge rule → SQS → Lambda for pause alerts
- Test Strict policy on sandbox tenant with seeded bounces (monitor account impact)
- Roll out per cohort: new customers first, migrate legacy second
- Rollback: remove `TenantName` from sends (reverts to non-tenant sends) only if associations allow—plan explicitly

#### Migration checklist (config-set-only → tenants)

| Phase            | Actions                                                                      |
| ---------------- | ---------------------------------------------------------------------------- |
| **Assess**       | Export all config sets, identities, and send volumes per downstream customer |
| **Design**       | Assign `TenantName` per customer; document shared vs dedicated resources     |
| **Pilot**        | One low-risk customer; Strict policy; validate metrics in CloudWatch         |
| **SDK**          | Upgrade to SESv2; add `TenantName` to `SendEmail` / bulk APIs                |
| **SMTP**         | Add `X-SES-TENANT` to all SMTP paths                                         |
| **Suppression**  | Recreate tenants with `SuppressionScope: TENANT`; update Lambda processors   |
| **IAM**          | Replace broad `ses:SendEmail` with `ses:TenantName` conditions               |
| **Events**       | Subscribe ops queue to EventBridge pause and finding events                  |
| **Cutover**      | Enable tenant sends per customer; monitor 72 hours before next wave          |
| **Decommission** | Remove non-tenant send paths only after full validation                      |

#### Operational readiness checklist

- [ ] CloudWatch dashboard: sends, bounces, complaints by `TenantName`
- [ ] EventBridge rule deployed with tested SQS/Lambda target
- [ ] Runbook: pause → customer notification → root cause → reinstate
- [ ] On-call alert when `Sending Status Disabled` fires
- [ ] Quarterly IAM review of tenant admin policies
- [ ] Service Quota request filed if approaching 10,000 tenants
- [ ] Per-Region tenant inventory documented
- [ ] CloudTrail alerts on `DeleteTenant` in production
- [ ] Customer SLA language updated for tenant-pause scenarios ([SLO design guide](/blog/customer-facing-sla-slo-design-aws/))
- [ ] Backup send path documented for catastrophic Region failure (non-tenant fallback is not automatic)

## Best Practices

- **Naming:** `{env}-{customer}-tenant`; tag with `cost-center`, `customer_id`
- **Least privilege:** Never attach admin tenant policies to senders
- **Automation:** Provision tenants in onboarding Lambda; store `TenantArn` in app DB
- **IaC:** Version CloudFormation/Terraform; see [`terraform-vs-aws-cdk-infrastructure-as-code-decision-guide`](/blog/terraform-vs-aws-cdk-infrastructure-as-code-decision-guide/)
- **Monitoring:** Dashboard per tenant; alarm on `Sending Status Disabled` events
- **CloudTrail:** Audit `CreateTenant`, `UpdateReputationEntityCustomerManagedStatus`
- **Documentation:** Runbook link in every tenant record

## Common Mistakes

1. Tenants without configuration sets on every send
2. Config sets sufficient but tenants added anyway (overengineering)
3. One tenant for all customers (defeats purpose)
4. Missing `TenantName` on API/SMTP
5. IAM policies without `ses:TenantName` condition
6. Manual console-only provisioning at scale
7. Shared suppression scope for ISV platforms
8. Ignoring regional duplication
9. Expecting tenants to fix bad list hygiene
10. No EventBridge automation on pause events

## Reference Enterprise Architectures

### Enterprise SaaS (marketing automation shape)

A platform sending promotional and transactional mail for many retailers routes **all** sends through SESv2 with `TenantName`. Each retailer receives:

- Dedicated tenant with `SuppressionScope: TENANT`
- Two configuration sets: `retailer-{id}-txn` and `retailer-{id}-mkt` with separate IP pools where volume justifies dedicated IPs ($24.95/IP/month)
- Strict reputation policy for first 30 days, then Standard after baseline metrics stabilize
- Onboarding Lambda invoking `CreateTenant` + `CreateTenantResourceAssociation` when sales provisions a new account

EventBridge forwards pause events to a shared ops queue; customer success receives the tenant ARN and finding description within minutes.

### Managed email platform (MSP)

MSPs often host dozens of clients with uneven volume. Long-tail clients share a **managed dedicated IP pool** via one configuration set; enterprise clients get dedicated pools. Every client still gets a **unique tenant** so a local gym's spam complaint does not pause a fintech client's transactional receipts.

### Marketing platform

Advertisers are tenants. Campaign sends must include both `TenantName` and the advertiser's configuration set. Creative review stays in the application; reputation enforcement stays in SES. Integrate with [SendGrid-to-SES migration patterns](/compare/sendgrid-to-aws-ses/) when advertisers move from legacy ESPs.

### Multi-brand retailer

Brand A and Brand B share corporate AWS billing but never share reputation. Each brand: one tenant, one marketing config set, one transactional config set. Corporate HR mail may live in a third tenant with lower volume and shared IPs.

### Healthcare

HIPAA-bound workloads may still use SES for **operational** mail (appointment reminders, not clinical record content in body). Tenants separate hospital affiliates; PHI boundary decisions remain with compliance. Pair with [AWS cloud security services](/services/aws-cloud-security/) for logging and encryption.

### Banking

Retail banking marketing and statements benefit from tenant separation by product line. For core banking divisions under regulatory separation, **separate AWS accounts** often remain the answer—tenants complement but do not replace account-level audit boundaries.

### Government

Agencies frequently mandate account isolation. Tenants help when policy allows shared accounts for **sub-agency** streams (e.g., public notices vs internal alerts).

### Internal enterprise platform

Engineering, HR, and Sales each receive tenants. Internal senders rarely need Strict policies; Standard suffices. Central IT retains tenant admin IAM; departments receive sender-only roles.

Diagrams: `docs/ses-tenant-management-core-architecture.drawio`, `docs/ses-tenant-send-validation-sequence.drawio`, `docs/ses-tenant-saas-platform-reference.drawio`, `docs/ses-tenant-decision-accounts-vs-tenants.drawio`.

## Decision Matrix

| Scenario           | Config sets only | Tenants only | Tenants + config sets | Multi-account | Hybrid |
| ------------------ | ---------------- | ------------ | --------------------- | ------------- | ------ |
| Startup            | **Best**         | —            | —                     | —             | —      |
| SMB single brand   | **Best**         | —            | —                     | —             | —      |
| Growing SaaS       | Good             | —            | **Best**              | —             | —      |
| Enterprise ISV     | Partial          | Risky        | **Best**              | Good          | Good   |
| Multi-brand retail | Partial          | —            | **Best**              | Good          | —      |
| Healthcare         | Partial          | —            | Good                  | **Best**      | Good   |
| Banking            | —                | —            | Good                  | **Best**      | Good   |
| Government         | —                | —            | —                     | **Best**      | Good   |
| MSP                | Partial          | —            | **Best**              | Good          | —      |

## FactualMinds Expert Recommendations

**When tenants are essential:** ISV or MSP platforms with **50+** downstream senders in one SES account, especially when a single customer's complaint spike previously threatened account-wide sending.

**When tenants add little:** Single-brand transactional mail, or organizations already running one SES account per customer via a landing zone.

**SaaS adoption path:** (1) Migrate to SESv2, (2) add config sets per stream, (3) enable tenants for new customers, (4) backfill legacy customers in waves, (5) enable tenant suppression and EventBridge automation.

**Enterprise adoption path:** Start with BU-level tenants; keep regulated divisions on separate accounts if compliance requires it.

**Migration:** Run parallel sends without `TenantName` only during cutover windows; associate resources before switching; never delete identities still linked to tenants.

Need hands-on help? See our [Amazon SES consulting](/services/aws-ses/) and [SES migration services](/services/aws-ses-migration/).

## Frequently Asked Questions

1. **What are Amazon SES tenants?** Logical containers for identities, config sets, templates, and per-tenant reputation in one account.
2. **When did tenants launch?** August 1, 2025, all commercial SES Regions.
3. **Is there an activation step?** No account flag; use SESv2 APIs or console immediately (AWS fact).
4. **How many tenants can I create?** 10,000 default; 300,000 with quota increase.
5. **Do tenants cost extra?** Yes—$0.005/tenant/mo + $0.005/1k tenant emails.
6. **Do tenants improve deliverability?** They isolate enforcement; they do not auto-improve inbox placement.
7. **Tenants vs configuration sets?** Complementary; use both on ISV platforms.
8. **Tenants vs separate accounts?** Tenants are cheaper and simpler; accounts are stronger isolation.
9. **Required headers for SMTP?** `X-SES-TENANT` and `X-SES-CONFIGURATION-SET`.
10. **Required API parameter?** `TenantName` on `SendEmail` / `SendBulkEmail`.
11. **What is Standard policy?** Auto-pause on high-severity findings.
12. **What is Strict policy?** Auto-pause on any finding.
13. **Can I manually pause a tenant?** Yes—`UpdateReputationEntityCustomerManagedStatus`.
14. **What happens when paused?** Sends for that tenant fail until reinstated.
15. **Are tenants regional?** Yes—create per Region.
16. **Can templates be shared?** Yes, via resource association.
17. **Can identities be shared?** Yes, but dedicated per customer is safer for ISVs.
18. **Does CloudFormation support tenants?** Yes—`AWS::SES::Tenant`.
19. **How do tenant suppression lists work?** Set `SuppressionScope: TENANT` at create; use `TenantName` on suppression APIs.
20. **Does PutSuppressedDestination support tenants?** Yes—optional `TenantName` parameter.
21. **Are contact lists per tenant?** No—account-level resource.
22. **Does VDM work per tenant?** VDM is account-level; metrics are not tenant-native in VDM.
23. **What CLI version is required?** AWS CLI 2.28.0+ documented in AWS blog examples.
24. **Can nested tenants exist?** No—flat structure only.
25. **Does account reputation still matter?** Yes—AWS warns combined tenant activity affects account standing.
26. **What EventBridge events fire?** Sending status changes and advisor recommendation open/close.
27. **How do I test policies safely?** Use isolated test tenant, Strict policy, controlled bounce seeds—monitor account metrics.
28. **Can I delete an identity associated to a tenant?** No—remove association first.

## What to Do This Week

**Decision checklist**

- [ ] Count downstream senders in one SES account (>50 → strong tenant case)
- [ ] Confirm SESv2 SDK/CLI versions in production
- [ ] Map identities and config sets per customer/BU
- [ ] Estimate tenant AWS fees ($0.005/tenant/mo + volume)
- [ ] Choose Standard vs Strict policy tiers
- [ ] Plan tenant-level suppression for ISV platforms
- [ ] Deploy EventBridge pause automation
- [ ] Clone `examples/ses-tenant-management` for first tenant

**Implementation checklist**

- [ ] Create pilot tenant with identity + config set associations
- [ ] Update send path with `TenantName`
- [ ] Attach IAM `ses:TenantName` sender policy
- [ ] Wire bounce handler with `PutSuppressedDestination --tenant-name`
- [ ] Dashboard CloudWatch metrics by tenant
- [ ] Document reinstate runbook
- [ ] Schedule legacy customer migration waves

**Next steps:** [Book a deliverability assessment](/contact-us/) or review [SES ecommerce patterns](/blog/aws-ses-ecommerce-email-marketing/) for suppression automation.

## What This Post Doesn't Cover

- Mailbox-provider-specific inbox placement mechanics (Gmail Postmaster, Yahoo CFL)
- Deliverability Expert Services engagements
- Cross-Region tenant replication or Global Endpoints interaction (see `docs/aws-ses-mrep-tenants-combined.drawio` for MREP patterns)
- Full legal/compliance sign-off for regulated industries—engage counsel alongside architecture
- SES Mail Manager and ingress endpoint pricing

### Official AWS references

- [Tenants — Developer Guide](https://docs.aws.amazon.com/ses/latest/dg/tenants.html)
- [Tenant-level suppression](https://docs.aws.amazon.com/ses/latest/dg/sending-email-suppression-list-tenant-level.html)
- [What's New — Aug 1, 2025](https://aws.amazon.com/about-aws/whats-new/2025/08/amazon-ses-tenant-isolation-automated-reputation-policies/)
- [Messaging Blog Part 1](https://aws.amazon.com/blogs/messaging-and-targeting/improve-email-deliverability-with-tenant-management-in-amazon-ses/) / [Part 2](https://aws.amazon.com/blogs/messaging-and-targeting/implement-tenants-in-your-amazon-ses-environment-part-2-assessment-and-planning/) / [Part 3](https://aws.amazon.com/blogs/messaging-and-targeting/implement-tenants-in-your-amazon-ses-environment-part-3-implementation-guide/)
- [CreateTenant API](https://docs.aws.amazon.com/ses/latest/APIReference-V2/API_CreateTenant.html)
- [PutSuppressedDestination API](https://docs.aws.amazon.com/ses/latest/APIReference-V2/API_PutSuppressedDestination.html)
- [AWS::SES::Tenant](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-ses-tenant.html)

## FAQ

### Does Amazon SES charge extra for tenant management?
Yes. AWS bills $0.005 per tenant per month plus $0.005 per 1,000 emails sent through tenants, on top of standard SES send charges. See the SES pricing page for current rates.

### When should you NOT use SES tenant management?
Skip tenants for single-brand senders, low-volume deployments, or organizations that already isolate email with separate AWS accounts per customer. Configuration sets alone are enough for stream separation without tenant overhead.

### What happens if you forget TenantName on a send request?
SES does not attribute the send to your intended tenant. Reputation metrics, suppression scope, and IAM conditions tied to ses:TenantName will not apply as expected—effectively bypassing tenant isolation.

### Can one SES tenant span multiple AWS Regions?
No. Tenants are regional. You must create and monitor tenants separately in each Region where you send email.

### Do tenants automatically improve inbox placement?
No. Tenants isolate reputation tracking and enforcement. Inbox placement still depends on authentication, list hygiene, content, and IP reputation—the same factors as before tenants existed.

### What is the difference between Standard and Strict reputation policies?
Standard pauses a tenant on high-severity findings (AWS documents bounce rate above 15% and complaint rate above 1% in the implementation guide). Strict pauses on any finding, including lower thresholds (bounce above 10%, complaint above 0.5%).

### Can configuration sets and tenants be used together?
Yes—and for most ISV platforms they should be. Configuration sets separate sending streams (marketing vs transactional, IP pools, event destinations). Tenants add per-customer reputation enforcement and IAM scoping.

### What could go wrong during tenant migration?
Common failures include shared account-level suppression blocking other tenants, sends without associated configuration sets, and application code still on SES v1 APIs that lack tenant parameters.

---

*Source: https://www.factualminds.com/blog/amazon-ses-tenant-management-enterprise-guide/*