Amazon SES Tenant Management: The Ultimate Enterprise Guide

On August 1, 2025, AWS shipped tenant management in Amazon SES—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.

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

See architecture diagram: docs/ses-tenant-management-core-architecture.drawio (repo path).

Why AWS Introduced Tenants

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):

# 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

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

Tenant Management vs Configuration Sets

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

See 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.

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

From a real engagement (architecture shape) — A marketing-automation platform at TargetBay scale (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:

• $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

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):

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:

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.

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/. 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)

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)
• 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
• 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 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 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

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 and SES migration services.

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 or review SES ecommerce patterns 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
• Tenant-level suppression
• What’s New — Aug 1, 2025
• Messaging Blog Part 1 / Part 2 / Part 3
• CreateTenant API
• PutSuppressedDestination API
• AWS::SES::Tenant