The Noisy Neighbour Problem in Shared SES Accounts
Any platform that sends email on behalf of multiple customers from a single Amazon SES account faces a structural risk that is easy to overlook until it causes a real incident. SES tracks bounce rates, complaint rates, and suppression lists at the account level by default, so a single customer with poor list hygiene can drag down the deliverability of every other customer sharing that account. Mailbox providers see the account's aggregate sending reputation, not the behaviour of individual senders within it. One tenant's spam-trap hits become everyone's problem.
This is the noisy neighbour problem, and for SaaS platforms, email agencies, and multi-brand senders it is more than a theoretical concern. A B2B SaaS product might have hundreds of customer workspaces all routing transactional mail through the same SES account. The moment one of those workspaces sends to a stale list, bounces spike, complaint rates climb, and the platform risks hitting sending thresholds that affect customers who have done nothing wrong. Before August 2025, the only robust architectural answer was to provision a separate AWS account per customer, which is expensive and operationally burdensome. That calculus has now changed.
What SES Tenants Are and When They Launched
On 1 August 2025, AWS launched the ability to provision isolated tenants within a single SES account and apply automated reputation policies to manage email sending. The feature gives platform builders a first-class abstraction for multi-tenant email architecture without the overhead of managing separate AWS accounts.
Tenants are logical containers that group related SES resources together. Each tenant can have its own verified sending identities, configuration sets, and templates, along with independent reputation metrics and sending status. This isolates and independently manages email sending for different customers or business units within a single SES API v2 account. The service supports up to 10,000 tenants per account by default, with the limit raiseable to 300,000 on explicit request, meaning even large SaaS platforms can work within a single account rather than fragmenting infrastructure across multiple AWS organisations.
A second major capability arrived on 1 June 2026, when AWS launched tenant-level suppression lists. This extension completed the isolation picture by ensuring that bounces and complaints from one tenant no longer pollute the suppression state of every other tenant in the account.
How Reputation Bleed Happens: a Concrete Scenario
Consider a SaaS platform that provides email marketing tools to small businesses. All customers send through a shared SES account under a shared sending domain. Customer A acquires a list of addresses that have not opted in and sends a promotional campaign. Several hundred addresses hard-bounce. SES adds each of those addresses to the account-level suppression list. Customer B, who has a legitimate opted-in relationship with some of those same addresses, can no longer reach them. SES accepts the send request but silently drops the message before it reaches the receiving mail server. Customer B raises a support ticket asking why their emails are not arriving, and the platform team has no clean answer.
This is cross-tenant suppression contamination. Beyond the immediate deliverability loss, it creates unfair outcomes and an increased support burden. Worse, if Customer A's behaviour is severe enough to generate complaint findings at account level, SES may intervene across the whole account, pausing sending for all customers simultaneously. The SES Tenants feature was designed specifically to contain this blast radius.
Core Concepts: Tenants, Configuration Sets, Identities, and Templates
Understanding how the four resource types relate to each other is essential before setting anything up. A tenant is the top-level container. Each tenant must have at least one verified sending identity (a domain or email address) and at least one configuration set associated with it before it can send mail. Templates are optional but can also be scoped to a tenant, keeping transactional message designs cleanly separated between customers.
A single resource can be associated with multiple tenants, which allows resource sharing while maintaining separate reputation tracking per tenant. In practice, a platform can use a shared sending domain across tenants whilst still isolating each tenant's bounce and complaint metrics. When sending, the caller specifies the tenant either by including the TenantName parameter in SES API v2 calls or by passing the X-SES-TENANT header over SMTP. SES then attributes all downstream metrics and suppression events to that specific tenant rather than to the account as a whole.
Setting Up Your First Tenant via the Console and CLI
In the SES console, navigate to the Tenants section and create a new tenant by providing a meaningful name that maps to your customer identifier. Once the tenant record exists, associate resources with it. At minimum, link a verified identity and a configuration set. If the tenant needs its own dedicated IP pool, that can be associated at this stage too.
From the CLI, the same flow uses three commands. First, create the tenant container:
aws sesv2 create-tenant --tenant-name "acme-corp"
Then associate a configuration set and an identity using the create-tenant-resource-association operation, passing the resource ARN and tenant name for each. Configuration sets must be associated with the tenant at send time for reputation metrics to be attributed correctly. If an email is sent without specifying a tenant, SES treats it as an untenanted send and the metrics roll up to the account level as before. Enforcing the tenant parameter at the application layer is therefore important from day one.
When automating tenant creation during customer onboarding, the CreateTenant API integrates naturally into a provisioning Lambda or a step in a Step Functions workflow. The entire lifecycle, from creation and resource association through to status updates and deletion, is managed through the SES API v2 without requiring any cross-account infrastructure changes.
Automated Reputation Policies: Standard, Strict, and None
Each tenant has a reputation policy that controls how SES responds when it detects deliverability problems. AWS offers three options.
Standard is the recommended setting for most production tenants. It pauses a tenant's sending automatically when high-severity reputation findings are detected, for example when bounce or complaint rates cross thresholds that indicate a significant deliverability problem. Low-severity findings are surfaced as recommendations without triggering an automatic pause.
Strict pauses sending for any reputation finding, whether high or low severity. This offers maximum protection and is a sensible default for new or untrusted tenants where you have less confidence in a customer's list hygiene. Once a tenant has established a track record, downgrading to Standard is straightforward via the API.
None disables automated pausing entirely whilst still tracking findings. Reputation findings are still generated at both severity levels based on metrics such as bounce rates and complaint rates, but those findings are visible without triggering automatic action. This setting is useful during an initial monitoring period or when a platform is implementing its own custom reputation management logic that reacts to EventBridge events directly. It is worth noting that even with None selected, AWS reserves the right to pause a tenant exhibiting severe reputation issues in order to protect the shared infrastructure.
Tenants can also be paused manually via API, which is useful when a platform detects problems through its own monitoring before SES's automated systems do. After the underlying issues are resolved, sending can be reinstated. During the reinstatement period, SES continues to monitor metrics closely before returning the tenant to full active status.
Tenant-Level Suppression Lists: Isolating Bounces and Complaints Per Customer
Prior to June 2026, all tenants in an SES account shared a single account-level suppression list. When a recipient bounced or complained about one tenant's email, that address was suppressed for every tenant in the account. The tenant-level suppression feature launched on 1 June 2026 closes this gap by giving each tenant its own isolated suppression list, so that bounces and complaints affect only the tenant that generated them.
Two settings control suppression behaviour for each tenant: suppression scope and suppressed reasons. The scope can be set to TENANT, which directs SES to use the tenant's own list, or ACCOUNT, which retains the previous shared-list behaviour and is the default for both existing and new tenants. The suppressed reasons field controls which event types trigger automatic suppression: BOUNCE, COMPLAINT, or both.
You can configure these settings at tenant creation time by passing SuppressionAttributes to the CreateTenant API, or update them later using PutTenantSuppressionAttributes. SES automatically records bounces and complaints to the appropriate tenant's list once tenant-level suppression is enabled. Manual management of suppressed addresses is available through PutSuppressedDestination, GetSuppressedDestination, DeleteSuppressedDestination, and ListSuppressedDestinations, each of which accepts a TenantName parameter to scope the operation.
One important operational point: disabling tenant-level suppression does not delete existing entries from the tenant's suppression list. If you re-enable tenant suppression later, those entries remain active. This makes it safe to temporarily switch a tenant back to account scope without losing the suppression history you have accumulated.
EventBridge Notifications: Reacting to Tenant Status Changes in Real Time
SES publishes notifications to Amazon EventBridge when tenant status changes occur or when new reputation findings are detected. This makes it straightforward to wire tenant reputation events into existing incident-response workflows. A typical architecture routes EventBridge events through an SNS topic to trigger a Lambda function that updates a customer dashboard, sends an internal Slack alert, or automatically opens a support ticket when a tenant is paused.
The events SES emits include sending-status changes such as a tenant moving from active to paused, and advisor recommendation events that surface new reputation findings. Tracking both event types separately is worthwhile: a status-disabled event demands immediate action, whilst a recommendation event is an early warning that gives you time to investigate before SES intervenes automatically.
When a tenant is paused, whether automatically through a reputation policy or manually, no emails can be sent through that tenant until the status is reinstated. The effective sending status is derived from both customer-managed and AWS-managed statuses: if either is set to DISABLED, the tenant cannot send. Building a clear internal runbook for the reinstatement process, including checks on bounce rates, complaint rates, and list sources before re-enabling a tenant, is strongly recommended.
Monitoring Gaps the Native Console Still Leaves Open
The SES console and EventBridge integration provide solid primitives, but they leave meaningful visibility gaps that matter at scale. The console provides per-tenant status and current findings, but it does not offer cross-tenant alerting. If you want to know which of your 500 tenants crossed a bounce-rate threshold in the last hour, you need to build that aggregation yourself using CloudWatch metrics and custom queries. There is no native view that ranks tenants by reputation health or flags those approaching a danger zone before findings are generated.
The EventBridge integration is event-driven, which means it tells you when something has already happened. There is no built-in mechanism for threshold alerting on trends, for example notifying you when a tenant's seven-day complaint rate is climbing steadily but has not yet crossed the threshold that triggers a finding. Catching problems at that earlier stage is where proactive monitoring pays dividends.
Webhook delivery is another gap. SES can route events to SNS, SQS, or Kinesis, but there is no first-party webhook endpoint that a SaaS platform can configure directly without building and hosting its own event consumer. For teams who want to pipe reputation events into their own dashboards or third-party observability tools, that is additional infrastructure to maintain.
Historical trend data is also limited. The console shows current reputation state and recent findings, but reviewing how a specific tenant's bounce rate has trended over the past thirty days requires pulling CloudWatch metrics manually or building a custom data pipeline. For platform teams that need to have evidence-based conversations with customers about their email hygiene, a clean historical view per tenant is essential.
How SES Monitor Fills Those Gaps
SES Monitor tracks bounce and complaint rates at the configuration-set level, which maps directly onto the tenant architecture described here. Using one configuration set per tenant gives you precise per-customer metrics without any additional instrumentation. Historical trend charts show how a tenant's rates have moved over days or weeks rather than just their current state, making it far easier to spot a gradual deterioration before it becomes a formal reputation finding.
Threshold-based alerts fire before SES takes automated action, giving your team a window to investigate and potentially resolve the underlying issue without the tenant ever being paused. Those alerts can be delivered by email or by webhook, meaning you can push reputation events directly into your internal tooling, whether that is Slack, PagerDuty, or a custom operations dashboard, without managing your own EventBridge consumer infrastructure. For platform teams who need to demonstrate due diligence on reputation management to their customers, the combination of per-tenant historical data and proactive alerting closes the visibility gap that the native console leaves open.
Migration Checklist: Moving to the Tenant Model
If you are currently running multiple customers through a shared SES account without tenant isolation, the migration path is manageable but requires care. Work through the following steps in order.
First, audit your existing configuration sets and verified identities, and map each one to the customer it belongs to. This mapping becomes the foundation for your tenant design. Create a tenant for each customer using the CreateTenant API, ideally matching tenant names to the customer identifiers already used in your application layer so that correlation is straightforward.
Second, associate each customer's configuration set and verified identities with their corresponding tenant using CreateTenantResourceAssociation. If any resources are legitimately shared across customers, associate them with multiple tenants.
Third, update your application's sending code to pass the TenantName parameter, or the X-SES-TENANT header for SMTP sends, on every outbound message. This is the critical step: any send that does not specify a tenant still rolls up to account-level metrics, so an incomplete rollout will produce misleading data.
Fourth, enable tenant-level suppression for each tenant, setting the suppression scope to TENANT and configuring the suppressed reasons appropriate to each customer's mail type.
Fifth, set reputation policies. Standard is appropriate for established customers with known good list hygiene. Strict is sensible for new customers until they have a proven track record. Configure EventBridge rules to capture tenant status changes and route them to your alerting pipeline.
Finally, verify that per-tenant metrics are appearing correctly in the console before treating the migration as complete. Run a small volume of test sends through each tenant and confirm that bounce and complaint events are attributed to the correct tenant's metrics and suppression list.
Tenants versus Separate AWS Accounts: When to Use Which
The SES Tenants feature is the right architecture for the vast majority of multi-tenant SaaS senders. It provides strong reputation isolation, automated protective policies, per-tenant suppression, and real-time event notifications, all within a single AWS account that is operationally straightforward to manage and audit.
Separate AWS accounts remain appropriate in a narrower set of scenarios: where regulatory requirements mandate complete infrastructure separation between customers, where a single high-volume customer needs dedicated IP warm-up and independent SES sending quotas, or where a customer's contractual terms explicitly prohibit shared infrastructure. For everyone else, the tenant model offers a clean, scalable answer to the noisy neighbour problem without the operational complexity of cross-account management. The August 2025 launch and the June 2026 suppression extension together deliver the isolation primitives that multi-tenant email platforms have needed for years.