For a Node.js app that needs a straightforward, team-wide suppression list, Resend is the simpler documented fit. Its SDK provides direct operations to add, retrieve, and remove suppressed addresses, and its webhooks can report suppression changes. Amazon SES remains a strong option when you already use AWS controls or need suppression isolation between application tenants. This is an implementation-fit comparison—not a claim that Resend is cheaper or delivers email more reliably.
Why suppression matters for transactional welcome emails
A transactional welcome email should not go to an address that has permanently bounced or complained about earlier mail. A suppression list gives the provider a record of addresses the application should not send to. Without one, a signup flow can keep attempting delivery to an address that has already been rejected, or send again after a complaint.
For a Node.js team, the practical question is how easily the provider lets the application manage that list, understand why an address was suppressed, and keep its own records aligned with the provider. Resend and Amazon Simple Email Service (SES) both support suppression controls, but their scope and integration models differ.
Resend: direct Node.js suppression operations
Resend automatically suppresses addresses after hard bounces or complaints, and also supports manual additions. The reason recorded can be bounce, complaint, or manual. Its Node.js SDK documents calls on the Resend client, including resend.suppressions.add({ email }) for one address and resend.suppressions.batch.add({ emails }) for a batch. A batch can contain up to 100 addresses. See Resend’s suppression documentation for the current API details.
#1 Best Overall
Resend’s suppression list is team-wide: an address suppressed for one domain also applies across the team’s other domains and subdomains. If a send matches an entry, Resend skips delivery until the entry is removed.
Inspect, remove, and react to entries
Teams can inspect suppressions in the dashboard or through the API. The documented entry information includes its origin and, for automatic suppressions, a reference to the email event that triggered it. An entry can be removed by suppression ID or email; bulk removal supports up to 100 entries at a time.
Rank #2
Resend documents the suppression.added and suppression.removed webhook events, as well as email.suppressed when an outgoing message matches an existing entry. Those events can help an application keep its own suppression state or audit trail synchronized.
Removing an entry is not a guarantee that future mail will be delivered. A new bounce or spam complaint can cause the address to be suppressed again. Treat removal as a deliberate correction, not as a way to override the recipient’s mail system or complaint history.
Recommended Free Tools
Rank #3
Amazon SES: account, global, and tenant suppression
SES has more than one suppression mechanism, and the distinction matters. The customer-controlled account-level list is not the same as AWS’s global suppression list. For multi-tenant applications, SES also offers tenant-level suppression lists.
Account-level suppression
SES account-level suppression can be configured for bounces, complaints, or both, using the SES API v2 or the console. It can also be scoped to configuration sets. If an address appears on the account list for a reason enabled in the account setting, SES accepts the send request but does not deliver the message. Account-level entries remain until removed, and customers can retrieve or list them through SES API operations. The AWS account-level suppression guide describes the available controls.
Rank #4
Account-level suppressed attempts do not contribute to the reputation bounce or complaint rate metrics described in AWS’s guide, but they do count against the daily sending quota. One important limitation: Gmail does not provide complaint data to SES, so reports made with Gmail’s spam button do not populate the SES complaint suppression list.
AWS-managed global suppression
SES’s global suppression list is managed by AWS, enabled for all SES accounts, and cannot be queried or edited directly by customers. It applies to hard-bounced addresses, which AWS may retain for up to 14 days. SES accepts a send attempt to an address on this list but does not deliver it; the resulting Permanent / Suppressed bounce notification is the only way for a customer to learn that the address was on the global list. These attempts count toward both the account’s daily quota and bounce rate. See AWS’s global suppression list documentation.
Tenant-level suppression for multi-tenant apps
For applications that send on behalf of multiple customers, SES tenant-level suppression can isolate one tenant’s bounce and complaint history from another’s. A tenant can use its own suppression list or the account list, with suppression reasons set to hard bounces, complaints, or both. Tenant lists require SES multi-tenancy and are Region-specific.
Configuration-set behavior takes precedence over tenant settings, which in turn take precedence over account defaults. That precedence should be reflected in an application’s design and troubleshooting: a tenant’s expected policy may not be the effective one if a configuration set supplies a different setting. AWS announced tenant-level suppression on June 1, 2026; see the AWS announcement.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Resend vs. SES: which suppression model fits?
| Decision | Resend | Amazon SES |
|---|---|---|
| Node.js integration | Documented direct SDK methods for adding, batch adding, and removing suppressions; dashboard/API retrieval and webhook events are also documented. | AWS documents SES API v2 and CLI management; the cited sources do not establish an equivalent Node.js-specific suppression abstraction. |
| Default scope | Team-wide across domains and subdomains. | Account-level by default, with tenant-level isolation available for multi-tenant setups. |
| Suppression reasons | Automatic hard-bounce and complaint entries, plus manual additions. | Account and tenant settings can cover bounces, complaints, or both; the AWS global list concerns hard bounces. |
| Visibility | Dashboard/API inspection and documented suppression webhooks. | Account and tenant entries can be retrieved or listed through SES API operations; the global list cannot be queried. |
| Operational caveat | Removing an entry does not guarantee delivery; another bounce or complaint can suppress it again. | Account-level suppressed attempts count against the daily quota. Global-list attempts count against the quota and bounce rate. |
| Tenant isolation | The cited documentation describes team-wide scope. | Tenant lists can separate suppression behavior, are Region-specific, and are subject to configuration-set precedence. |
How to choose for a Node.js welcome-email flow
Choose Resend for simple team-wide management
Resend is a reasonable choice when your main requirement is for application code to manage a shared suppression list without building a suppression workflow around broader AWS account and configuration-set controls. Its documented Node.js calls cover common add and removal tasks, while retrieval and webhook events offer ways to audit and mirror changes.
Choose SES for AWS operations or tenant isolation
SES is a better fit when the rest of your email operation already depends on AWS controls, or when customer-by-customer isolation is important. Tenant-level suppression addresses a real limitation of a single shared list, provided the application uses SES multi-tenancy and accounts for Region and configuration-set precedence.
The available documentation does not establish a comparative delivery advantage, implementation-time benchmark, or relative cost for either provider. Choose based on the suppression scope and operational integration your application needs rather than assuming either provider will improve inbox placement.
Quick Recap
Practical safeguards for welcome-email suppression
- Record the suppression reason and provider event where available, so support staff can distinguish a bounce, complaint, and manual action.
- Make suppression checks part of the send path for welcome messages and any retry or resend mechanism.
- For SES, verify which configuration set, tenant, and account settings apply to each message; the effective policy follows the documented precedence.
- Do not automatically remove suppressions simply because a user signs up again. Investigate the address and reason before allowing another send.
- Monitor provider events and reconcile local state with provider state, especially if the application stores its own suppression records.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
