Why Suppression Matters More Than Most Developers Realise
Every email sent to an address that cannot or will not receive it is a small act of self-harm. Hard bounces signal to the wider email ecosystem that your sending practices are poor. Spam complaints tell inbox providers that recipients did not want what you sent. Amazon SES takes both signals seriously. AWS publishes a two-tier threshold system: keep your bounce rate below 5% and your complaint rate below 0.1% as a recommended ceiling, with account pauses becoming likely above 10% bounce or 0.5% complaint. Exceeding even the lower thresholds risks your account being placed under review.
Suppression lists are the mechanism that prevents repeat offences. When an address is suppressed, SES accepts your send request but drops the message before it ever reaches the receiving mail server, protecting your sending reputation without requiring application-code changes on every send. The problem is that most SES developers are aware of only one layer of this protection. The full architecture contains three distinct layers, and since June 2026 a third layer has arrived that fundamentally changes how multi-tenant platforms should approach suppression. Understanding all three, and how they interact, is the foundation of a sound deliverability strategy.
The Three-Layer Suppression Hierarchy
Amazon SES resolves suppression settings in a strict precedence order from highest to lowest: configuration set, then tenant, then account. The three layers themselves are the global suppression list, the account-level suppression list, and, for multi-tenant environments, the tenant-level suppression list introduced on 1 June 2026. Each layer has a different owner, a different scope, and a different purpose. Ignoring layers you did not know existed leads to suppression events that are confusing to diagnose and expensive to recover from.
The Global Suppression List
The global suppression list is owned and managed entirely by SES. It operates in the background and you cannot interact with it directly. You cannot query it, add addresses to it manually, or remove addresses from it on demand. It exists because all SES customers share the same pool of IP addresses unless they use dedicated IPs, and SES must protect those shared resources from being harmed by any individual sender repeatedly attempting delivery to addresses that are clearly dead.
When any SES customer sends a message that results in a hard bounce, SES adds that address to the global suppression list. The address remains on the list for a period of time that grows with each subsequent bounce, giving the address a chance to become valid again. An address can remain on the global suppression list for up to 14 days. If you attempt to send to an address on the global suppression list, SES accepts the message but does not deliver it, and that attempt counts against your account's bounce rate and your daily sending quota. Critically, if you have enabled your account-level suppression list, it overrides the global list for your account: SES will still attempt delivery to an address you explicitly want to reach. This makes the account-level list a more precise tool than simply relying on the global list alone.
The practical implication is that you should treat suppressed-bounce notifications with the same urgency as real hard bounces. If you are sending to addresses that trigger global suppression events repeatedly, those events accumulate in your bounce rate just as genuine failed deliveries do. Enabling the account-level suppression list, described below, is the most direct way to prevent this from happening more than once per address.
The Account-Level Suppression List
The account-level suppression list is owned and managed by you. If your SES account was created after 25 November 2019, it is enabled by default for both bounces and complaints. If your account predates that, you must enable it explicitly using the PutAccountSuppressionAttributes operation in the SES API v2. You configure two things: which suppression reasons cause an address to be added automatically (BOUNCE, COMPLAINT, or both), and which of those reasons should block future sends.
Once enabled, SES automatically adds addresses that produce hard bounces or spam complaints to your account-level list, depending on your configured reasons. Note that only hard bounces are added automatically; soft bounces are not. Also note that Gmail does not provide complaint data to SES via feedback loops, so Gmail spam reports will not populate your suppression list automatically. When you subsequently attempt to send to a suppressed address whose reason matches your account settings, SES accepts the message but does not attempt delivery. Sends blocked by your account-level list do not count against your Reputation.BounceRate or Reputation.ComplaintRate metrics, unlike sends blocked by the global list. That distinction matters: your account-level list protects your reputation metrics in a way the global list alone does not.
You can manage the list via the SES console or the API. ListSuppressedDestinations returns all suppressed addresses. PutSuppressedDestination lets you add addresses manually, for example when importing a suppression list from a previous email service provider. DeleteSuppressedDestination removes an address when you have verified it is genuinely valid and deliverable again. For bulk operations you will need production access; sandbox accounts cannot import or export suppression data in bulk.
One important gotcha: SES account suppression lists are case-sensitive at the API level. When an address is stored as User@Example.com, an API call using user@example.com will not find or affect that entry, even though SES treats both as the same address for the purpose of actually sending mail. Always normalise addresses to lowercase in your application before making suppression list API calls, and normalise consistently when you import historical data.
SES is also region-specific. A suppression list in eu-west-1 is entirely separate from one in us-east-1. If you send from multiple regions you must manage suppression independently in each, or route all sending through a single region and manage the list there.
Configuration-Set-Level Suppression Overrides
Configuration sets add a layer of fine-grained control. You can configure a specific configuration set to override the account-level suppression settings for any sending stream that uses it. This is useful for transactional mail such as password resets or security alerts, where you may legitimately need to attempt delivery even to an address that has previously bounced a marketing email. You can instruct SES to use no suppression at all for that configuration set, or to suppress only one type of event rather than both.
The SuppressionOptions object for a configuration set includes a SuppressionScope field that determines which suppression list SES consults for emails sent using that set. You can override the scope, the suppressed reasons, or both independently, giving precise control over suppression behaviour for each sending workflow without altering your account-wide defaults. With the arrival of tenant-level suppression, this same SuppressionScope field can also be set to TENANT, directing all sends using that configuration set to consult the tenant's own isolated list rather than the account-level list.
Tenant-Level Suppression Lists
The problem they solve
Before 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, even those with a perfectly valid, opted-in relationship with the same recipient. This is cross-tenant contamination, and it creates serious operational problems: one tenant's poor list hygiene blocks another tenant's legitimate delivery, tenants raise support tickets asking why their mail is being suppressed without a clear answer, and the problem compounds as more tenants are added to the account.
The only workarounds before this feature existed were to provision separate SES accounts per tenant, which is operationally expensive, or to build custom suppression logic entirely in your application layer, which is complex and error-prone to maintain.
How tenant-level suppression works
Amazon SES now supports tenant-level suppression lists, launched on 1 June 2026, allowing email senders to isolate bounces and complaints per tenant. With tenant-level suppression enabled, each tenant maintains a separate suppression list, ensuring that bounces and complaints affect only the tenant that generated them. This eliminates cross-tenant contamination at the platform level without requiring separate SES accounts.
Two settings control suppression behaviour for each tenant. The suppression scope determines which list SES uses: TENANT instructs SES to use the tenant's own isolated list, while ACCOUNT is the default for both existing and new tenants and falls back to the shared account-level list. The suppressed reasons setting determines which events trigger an addition to the list: BOUNCE, COMPLAINT, or both. You must provide both settings together using the PutTenantSuppressionAttributes API operation, or supply SuppressionAttributes when creating a tenant with CreateTenant. Setting both to null clears the tenant's suppression settings and returns the tenant to the default account-scope behaviour.
When the scope is TENANT, SES checks only the tenant's suppression list at send time and skips the account-level list entirely. An address that is on the account-level list but not on a tenant's own list will not be suppressed for that tenant. For automatic recording, hard bounces are added to the tenant's list and to the global suppression list, but not to the account-level list. Complaints are added to the tenant's list only. When a recipient marks a previously reported message as not-spam, SES automatically removes the COMPLAINT-reason entry from the tenant's list.
API operations and identifying suppression events
You can manually manage suppressed addresses for a specific tenant using the standard suppression list API operations, with the addition of the TenantName parameter. Passing TenantName to PutSuppressedDestination, GetSuppressedDestination, DeleteSuppressedDestination, and ListSuppressedDestinations targets the operation at that tenant's isolated list rather than the account-level list. Omitting TenantName causes the operation to act on the account-level list as before, preserving backwards compatibility.
When SES suppresses a message because the address is on a tenant's suppression list, you can identify the event in your bounce notifications: the bounce type will be Permanent with a subtype of OnTenantSuppressionList. This makes it straightforward to distinguish tenant-level suppression events from account-level ones in your event processing pipelines.
Configuration sets can also override tenant-level suppression. The SuppressionScope field on a configuration set's SuppressionOptions can be set to TENANT to force tenant-scoped suppression for all sends using that set, or to ACCOUNT to force account-scoped behaviour regardless of the tenant's own settings. If you set SuppressionScope to TENANT on a configuration set, every SendEmail or SendBulkEmail request using that configuration set must include a tenant name; requests without one are rejected.
One further operational consideration: disabling tenant-level suppression for a tenant does not delete existing entries from that tenant's suppression list. If you re-enable tenant-level suppression later, those entries remain active. Factor this into any migration or testing plan.
Practical example for a SaaS platform
Consider a SaaS marketing automation platform with Tenant A and Tenant B. Tenant A runs an aggressive campaign and a recipient, jane@example.com, marks one of its emails as spam. Without tenant-level suppression, jane@example.com would be added to the shared account-level list, and Tenant B, which has a valid opted-in relationship with jane@example.com, would be unable to send her a critical transactional receipt. With tenant-level suppression enabled for both tenants, the complaint from Tenant A's campaign is recorded only on Tenant A's suppression list. Tenant B's send to jane@example.com proceeds normally, because her address does not appear on Tenant B's list.
To enable this for an existing tenant using the AWS CLI, run the put-tenant-suppression-attributes command, specifying the tenant name, setting the suppression scope to TENANT, and setting the suppressed reasons to BOUNCE and COMPLAINT. The operation is idempotent, so it is safe to call multiple times with the same parameters. To return a tenant to account-scoped behaviour, either set the scope back to ACCOUNT or omit both scope and reasons to clear the tenant's settings entirely.
Choosing the Right Suppression Strategy
For a solo sender or a small business sending a single programme of mail, the account-level suppression list with BOUNCE and COMPLAINT reasons enabled is almost always the right choice. It is simple to manage, protects your reputation metrics, and requires no additional infrastructure beyond enabling it in the console or via the API.
For a multi-brand enterprise sending distinct programmes from a single account, configuration-set-level overrides let you tune suppression per stream. Your transactional configuration set can bypass the account-level list for critical alerts, while your marketing configuration set enforces strict suppression for both bounces and complaints. This requires discipline in always applying the correct configuration set to each send.
For an agency or SaaS platform managing email on behalf of multiple customers, tenant-level suppression is now the correct architectural choice. Each customer becomes a named tenant in SES multi-tenancy with their own isolated suppression list. One customer's deliverability problems no longer contaminate another's, support queries about mysterious suppression become answerable, and the platform scales cleanly regardless of how many customers are added.
Monitoring and Alerting
The SES console provides a view of your account-level suppression list and aggregate reputation metrics, but it is not a real-time monitoring tool. By the time you notice a pattern in the console, your bounce or complaint rate may already be approaching a threshold that triggers an SES account review.
The correct approach is to process bounce and complaint events as they arrive. Amazon SES can publish sending events through a configuration set's event destination to an Amazon SNS topic, delivering JSON notifications that contain the bounce type, bounce subtype, and the affected email addresses. Your application should consume these events, update its own database to reflect suppression status, and trigger alerts before rates approach the recommended 5% bounce or 0.1% complaint ceilings. AWS publishes a second, harder pair of thresholds at 10% bounce and 0.5% complaint above which sending can be paused; alerting well before the lower recommended levels gives you the reaction time to intervene.
For multi-tenant environments, this event processing must be tenant-aware. The bounce subtype OnTenantSuppressionList identifies events recorded against a tenant's own list, while OnAccountSuppressionList identifies account-level events. Routing these events to the correct tenant's metrics pipeline lets you track each tenant's bounce and complaint rate independently, which is essential when you need to identify which tenant is driving a spike and take corrective action, whether that means reviewing the tenant's list hygiene, temporarily suspending their sending, or alerting them to a problem in their contact acquisition process.
Tools such as SES Monitor surface per-configuration-set bounce and complaint events, giving you a real-time view of each sending stream's health without having to build and maintain a bespoke event processing pipeline. When each tenant is associated with a dedicated configuration set, per-tenant reputation tracking becomes a natural consequence of the architecture rather than an additional engineering effort.
Common Mistakes and How to Avoid Them
The most widespread mistake is failing to synchronise the SES suppression list with your own application database. SES will silently drop sends to suppressed addresses, but your application may still consider those addresses valid active subscribers. The result is a growing gap between your perceived audience size and your actual deliverable audience, and a risk that application-layer retries or list imports re-introduce suppressed addresses to future campaigns.
A related mistake is ignoring suppressed-bounce notifications. When SES generates a bounce with a subtype of OnAccountSuppressionList, many developers treat it as a non-event because the message was not actually delivered. Sends to addresses on the global suppression list, however, do count against your bounce rate, so repeatedly sending to globally suppressed addresses will degrade your reputation metrics even though nothing was delivered.
Cross-region suppression gaps catch teams who expand into a new SES region without replicating their suppression data. Your suppression list in one region has no knowledge of suppression events that occurred in another. If you migrate sending regions or begin using a secondary region for resilience, export your existing suppression list and import it into the new region before you begin sending.
Finally, suppression lists require periodic auditing. Addresses can be removed from your suppression list when you have strong evidence they are now valid, for example when a user corrects a typo in their address and re-confirms. Without a regular review process, suppression lists grow without bound and may contain addresses whose suppression reason is no longer relevant.
Suppression Configuration Checklist
Amazon SES suppression architecture has three layers: the SES-managed global list that operates in the background, the customer-managed account-level list that protects your reputation metrics, and, since June 2026, the tenant-level list that eliminates cross-tenant contamination for multi-tenant platforms. Each layer serves a distinct purpose, and using them in combination, governed by the configuration-set override mechanism, gives you precise control over suppression behaviour across every sending stream in your account.
Use the following checklist to verify your suppression configuration is sound. Enable the account-level suppression list for BOUNCE and COMPLAINT reasons if it is not already active. Normalise all email addresses to lowercase before making suppression list API calls to avoid case-sensitivity issues. Use configuration-set-level overrides to exempt critical transactional streams where appropriate. If you manage multiple tenants from a single SES account, enable tenant-level suppression for each tenant using PutTenantSuppressionAttributes with SuppressionScope set to TENANT. Ensure your event processing pipeline consumes SNS bounce and complaint notifications and updates your application database in real time. Set up alerting that fires before your bounce rate approaches 5% or your complaint rate approaches 0.1%. If you send from more than one AWS region, manage suppression lists independently in each region. Audit your suppression list regularly and remove addresses only when you have confirmed they are genuinely deliverable again.