Amazon SES Suppression Lists: Account, Config Set, and Tenant

If Amazon SES accepted the API call but the receipt never arrived, check suppression before you debug templates. SES evaluates one list per SendEmail: a configuration-set override if present, else a tenant list (since June 2026), else the account-level list. The AWS-managed global list is still there and is not customer-editable. Removing an address without fixing the bounce that listed it usually recreates the same failure.

The problem that looks like a silent send

Transactional mail fails quietly when suppression is working as designed. The SendEmail call returns success. The address is on a list. SES does not attempt delivery. The user never sees the password reset. Support sees “the API worked.”

That is not a template bug and it is not always a quota issue. It is the suppression map. Quota still matters — suppressed attempts count against the daily sending quota even though they do not inflate bounce-rate or complaint-rate reputation metrics the same way a live bounce does. See Amazon SES sending limits and quotas if the account is also near its cap.

Four layers, one evaluation

Think of SES suppression as four layers. Only one list is consulted for a given send.

1. AWS-managed global suppression list. Always on. Not customer-editable. The old public removal form is gone. An address here can still be attempted if your account-level (or a higher-priority override) is the list SES actually evaluates — but a subsequent hard bounce can land the address on both global and account lists.
2. Account-level suppression list. Customer-owned, regional, scoped to the AWS account in that Region. Addresses are stored with a reason: BOUNCE, COMPLAINT, or both depending on how you configured account attributes. Hard bounces can add addresses automatically. Soft bounces do not. You can add and remove addresses in the console or with PutSuppressedDestination, GetSuppressedDestination, DeleteSuppressedDestination, and ListSuppressedDestinations.
3. Configuration-set override. Not a separate list. A config set can say “use account settings,” “override and suppress only these reasons,” or “override and disable suppression for this stream.” Unspecified reasons after an override can fall back to the global list. This is how teams try to split marketing and transactional streams inside one account.
4. Tenant-level list (launched 1 June 2026). Isolates bounces and complaints per tenant so one customer’s complaints do not poison every other tenant on the account. Scope is TENANT (use that tenant’s list) or ACCOUNT (use the account list). Default for new and existing tenants is ACCOUNT until you change it. Reason flags are BOUNCE, COMPLAINT, both, or empty. Empty reasons mean no check and no recording. Tenants and tenant lists are regional and are not replicated. Deleting a tenant deletes that tenant’s list.

Live precedence in current AWS tenant docs: configuration set → tenant → account. SES evaluates exactly one suppression list per SendEmail call.

Why addresses land on a list

• Hard bounce. The mailbox does not exist or the domain rejects permanently. SES can add the address to the account list (and it may already be on the global list).
• Complaint. The recipient marked the message as spam at a provider that shares complaint data with SES. Gmail does not send complaint data to SES. A Gmail user hitting Spam is not auto-added to your account-level list for complaints.
• Manual add. Operators put an address on the list after a support ticket or a legal hold. Console bulk add and PutSuppressedDestination both require a reason.

Suppression protects sender reputation. It is not a substitute for list hygiene or for a complaint webhook in the app. If you need the application to know why a receipt never left, wire events — see transactional email webhooks.

How to look up and remove one address

Do not export the whole list to find one user.

1. In the SES console, open Configuration → Suppression list. Filter by the exact address.
2. Or call GetSuppressedDestination with that address. If you are on a tenant list, pass TenantName. Case must match. SES stores addresses case-sensitively: [email protected] is not the same entry as [email protected].
3. Read the reason and the last update time. A BOUNCE from last week is a different decision than a two-year-old COMPLAINT.
4. If you remove it, use the console or DeleteSuppressedDestination (again with TenantName when the live list is the tenant list).
5. Send one test. If it hard-bounces again, the address will return to the list and you have spent quota to learn what you already knew.

Bulk add and bulk delete use import jobs against an S3 object. You cannot call PutSuppressedDestination or create those import jobs while the account is still in the SES sandbox. Get production access first; the sandbox article is how to move Amazon SES out of the sandbox.

Short CLI shape for a single lookup on the account list:

aws sesv2 get-suppressed-destination --email-address [email protected]

Add --tenant-name when the send path uses tenant scope. Do not script a mass delete because “customers are complaining.” That is how you recreate the bounce that listed them.

Should transactional and marketing share one list?

Usually no. A marketing complaint should not block a password reset, and a one-off bounce on a receipt should not silently drop the next newsletter without a review. In SES the practical split is:

• Separate configuration sets for transactional versus marketing.
• Do not override a transactional config set to “no suppression.” That config set will still attempt addresses the rest of the account already learned are dead, and those attempts still consume quota. They can also produce the bounce that damages the domain.
• If a legal or compliance stream must still attempt an address suppressed for marketing complaints, treat that as a documented exception with a dedicated config set — not as a reason to disable suppression account-wide.

Reputation context that is not SES-specific lives in why your emails go to spam. Operating playbooks for bounce versus complaint versus delay belong in a later companion article; this page is only the SES map.

When TENANT scope is the right default

Agencies and multi-tenant SaaS that send two brands from one SES account used to share one account-level list. One tenant’s harvested list or complaint spike suppressed receipts for everyone else. Tenant-level lists exist to stop that.

Use TENANT scope when:

• Each customer or brand can generate its own bounces and complaints.
• You already identify the tenant on SendEmail.
• You are willing to manage per-tenant lists (same CRUD APIs, plus PutTenantSuppressionAttributes or SuppressionAttributes on CreateTenant).

Leave ACCOUNT scope when the account has one product, one list, and no tenant isolation problem. Switching a tenant to TENANT does not copy the account list into the tenant list. Plan the cutover so existing suppressions are not forgotten.

AWS bundled tenants on Enterprise plans in July 2026 and also sells them à la carte. That is pricing context, not a reason to turn tenant lists on without an isolation problem.

Three failures this map explains

Password reset that used to work. The address hard-bounced once — typo, expired mailbox, or a corporate gateway. SES added it for BOUNCE. Every later reset is suppressed. Look up the address, confirm the mailbox exists now, then delete that one entry. Do not wipe the list.

Two brands, one account, pre-June 2026 habits. Brand A’s campaign complaints sat on the account list and blocked Brand B’s receipts. Tenant lists with TENANT scope keep those events apart. Config sets alone do not give you two lists; they only change which list and which reasons apply to a send.

Config set set to “no suppression.” Legal notices still go out. Dead mailboxes bounce. Quota moves. Reputation takes the hit the list was built to avoid. If you need that path, cap volume and watch bounce events in near real time.

What this is not

This article is about Amazon SES. ArawaMail is a single-workspace mailbox plus API product. It documents outgoing webhooks and mailbox spam handling. It does not document SES-style account or tenant suppression lists, and it should not be described as “SES with a nicer UI.” Do not assume an ArawaMail workspace inherits this four-layer map.

If the broader goal is transactional mail that support can see and that lives on the same domain as human inboxes, start from ArawaMail transactional email and stop treating transactional mail as a side project.

How we analyzed the SES map

The layer order and APIs are taken from the current AWS SES Developer Guide pages for account-level suppression, configuration-set overrides, and tenant-level lists, plus the June 2026 launch note and the July 2026 Messaging Blog isolation write-up. Operational caveats that shaped the advice: suppressed sends still consume quota; addresses are case-sensitive; Gmail does not feed complaints into SES; sandbox accounts cannot call PutSuppressedDestination; tenant lists are regional; deleting a tenant deletes its list; SES evaluates one list per send. We did not invent an ArawaMail equivalent.

FAQ

Why did SES accept the call if the user never got the message?
Acceptance means the API request was valid. Suppression happens after that. Check the list that the configuration set / tenant / account path actually evaluates.

Can I remove an address from the global list?
No. The old public form is gone. Use the account-level or tenant list as the list you control. A later hard bounce can still write the address back.

Does deleting a suppression fix deliverability?
Only if the destination can receive mail now. Otherwise you spend quota to recreate the bounce.

Do Gmail Spam clicks suppress the address?
Not via SES complaint events. Gmail does not provide that complaint data to SES. Gmail users can still be added for hard bounces or by hand.

Which list should a new SaaS tenant use?
Set scope to TENANT with BOUNCE and COMPLAINT if tenants can hurt each other. Leave ACCOUNT if you have one product and one list on purpose.

Find the address, read the reason, fix the destination, then remove that one entry. The list is a reputation brake. Treat it like one.