Amazon SES Raises Limits on Identities, Tenants and Configuration Sets

Amazon SES has raised the ceiling on three resources that multi-tenant senders burn through fastest: email identities, tenants and configuration sets. In an announcement posted on 11 November 2026, AWS said a single account "can now keep pace with your growth", so teams no longer need to split email workloads across several AWS accounts just to stay under per-account limits.

The change matters most to SaaS platforms, agencies and any product that sends on behalf of its own customers. Those senders typically create one verified domain, one tenant and one configuration set per customer or brand, and AWS now adds AI agents to that list. Each new customer adds rows to every one of those counters, and hitting a hard ceiling used to mean opening a second account and running the same infrastructure twice.

What AWS announced

The announcement is short and makes three changes. First, the limits on email identities, tenants and configuration sets are higher. Second, customers can see their current usage against each of those limits and ask for an increase in the AWS Service Quotas console, the same place where SES sending quota and sending rate increases are already requested. Third, the SES console now lets you search identities, tenants and configuration sets by name or by status, which AWS presents as a way to manage accounts that hold thousands of them.

The SES service quotas page lists the defaults that apply. An identity, meaning a verified domain or email address used to send, has a default quota of 10,000 per AWS Region. Tenants and configuration sets each have a default quota of 10,000. All three are flagged as adjustable. Quotas in SES apply per Region, so an account sending from two Regions has two separate sets of counters.

AWS did not publish the new upper bound it is willing to grant, so the practical ceiling depends on the increase request you file. The announcement does not change the sending quota (messages per 24 hours) or the sending rate (messages per second), which are still set per account and raised through their own review.

Why multi-tenant senders care

The three resources map to the way SES isolates customers. An identity is the domain or address a customer sends from, and each one needs its own DKIM setup. A configuration set carries event publishing (bounces, complaints, deliveries, opens and clicks sent to CloudWatch, SNS, Firehose or EventBridge) and can tie mail to a dedicated IP pool. A tenant is the container that groups the two together.

Tenant management is the part with the biggest deliverability impact. According to the SES tenants documentation, each tenant gets its own reputation metrics: bounce rate, complaint rate (including feedback loop complaints from mailbox providers) and third-party signals. When a tenant crosses a threshold, SES records a low or high severity reputation finding and, depending on the reputation policy you choose, pauses that tenant only. The other tenants keep sending. AWS describes this as the answer to a long-standing problem: one customer's poor list could previously get the whole SES account paused.

Three reputation policies are available. Standard, the default, pauses a tenant on high severity findings. Strict pauses it on any finding. None records findings but never pauses automatically. Sending through a tenant requires naming it in the API call or, over SMTP, in an X-SES-TENANT header, and SES checks that the identity and configuration set in the request belong to that tenant.

That isolation only works if every customer actually gets a tenant. A platform with 15,000 customers that runs into a ceiling has two bad options: put several customers in one tenant, which brings back shared reputation risk, or open a second AWS account and split its monitoring, suppression handling and IP pools. Higher, adjustable limits remove that trade-off inside one account.

Action checklist

• Check your usage against the identity, tenant and configuration set quotas in the Service Quotas console, Region by Region.
• Request an increase early if you are within reach of a quota; plan for the time AWS needs to review the request.
• Map one tenant per customer if you still group customers together, so that one bad list cannot pause everyone.
• Pick a reputation policy on purpose: Standard is the default, Strict suits new or untrusted customers, and None leaves enforcement entirely to you.
• Add the tenant to every send, through the API parameter or the X-SES-TENANT SMTP header, and confirm the identity and configuration set are associated with it.
• Review a multi-account setup you built only to work around limits; merging accounts can simplify suppression lists, event publishing and monitoring.

Context: SES and growing platforms

Our Amazon SES review covers pricing and features in detail, but the platform's appeal to SaaS builders has always been low cost per message and full API control, balanced by a lot of do-it-yourself work on reputation. Tenant management, and now the room to create one tenant per customer at scale, moves part of that work into SES itself. It does not replace list hygiene: bounce and complaint rates are still what trigger findings, so each tenant needs clean addresses and working unsubscribes. Our guide to domain and IP reputation explains which signals mailbox providers weigh.

Sources

1. AWS: Amazon SES now supports higher limits for email identities, tenants, and configuration sets, 11 November 2026 (primary source)
2. Amazon SES Developer Guide: Service quotas in Amazon SES
3. Amazon SES Developer Guide: Tenants

Related on SMTPedia

• Amazon SES Guide 2026: cost, setup, limits and deliverability
• How to add an Amazon SES unsubscribe link
• Best transactional email services in 2026