Sending Email with Amazon SES

SES is a Regional service. Everything on this page (identities, quotas, configuration sets, SMTP credentials, suppression settings) belongs to one Region in one account; if notifier can run in two Regions, you set all of it up twice. The SES v2 API (sesv2 in the CLI, SesV2Client in the Java SDK) is the current API; the older v1 API (aws ses) still works but newer features, including a 40 MB message limit, are v2 only.

The path in the diagram is the whole model: your application hands a message to SES, SES signs it and delivers it over SMTP, and the outcome comes back as an event that you must act on. A bounce or complaint that nobody handles keeps hurting the sending reputation of the domain, which is the single most common reason SES accounts get throttled.

An identity is the thing you are allowed to send from: either a domain (every address at example.com) or a single email address. SES refuses to send from anything that is not a verified identity in the same Region.

An address is covered by a verified domain identity automatically, so Bookshelf verifies example.com once and then sends from no-reply@example.com, orders@example.com and any other address without further steps. The domain identity is also where authentication is configured.

Every new SES account in a Region starts in the sandbox. In the sandbox you can send only to verified identities (or to the mailbox simulator addresses), at most 200 messages per 24 hours and 1 message per second. That is enough to develop notifier but not to email customers. Moving out of the sandbox is a request that AWS reviews; it is a per-Region, per-account step, and AWS asks for the kind of mail you send, how you obtain recipient addresses, and how you handle bounces and complaints.

A configuration set is a named bundle of sending settings that you attach to a message (or set as the identity’s default). Its most important job is carrying event destinations: places where SES publishes one event per send, delivery, bounce, complaint, reject, delivery delay, subscription, open and click.

A configuration set also controls the sending pool (a dedicated IP pool), custom open and click-tracking domains, reputation metrics and whether sending is enabled for that set, which lets you pause one stream of mail without touching the rest. Up to 10 event destinations can be attached to one configuration set.

SES offers two ways in. Choose by what the caller can do, not by habit.

Applications should send with an IAM role, scoped to the sending identities and the configuration set. This is the permission policy for the notifier task role or Lambda execution role (its trust policy is the ECS tasks or Lambda principal, see Identity and Access):

The ses:FromAddress condition stops a compromised notifier from sending as any other address in the domain. When a message uses a stored template, add arn:aws:ses:us-east-1:111122223333:template/order-confirmation to Resource. The send-only policy for an SMTP user is the same two statements reduced to the single action ses:SendRawEmail on , which is what SES’s own AmazonSesSendingAccess policy contains. The administrator who sets SES up needs ses: plus Route 53 write access to the zone, and, for the console’s "Create SMTP credentials" flow, iam:CreateUser, iam:CreateGroup, iam:PutGroupPolicy, iam:AddUserToGroup and iam:CreateAccessKey, which are high-privilege permissions that deserve a separate break-glass role. SES also supports identity policies so that another account can send as your identity; see the SES developer guide on sending authorization.

Reference: Identity and access management in Amazon SES and Actions, resources and condition keys for the SES v2 API.

A hard bounce means the address will never work; a soft bounce is a temporary failure that SES retries for a while before reporting it; a complaint means the recipient pressed "report spam". Sending again to hard-bouncing or complaining addresses is what damages a sender’s reputation, so the loop is: receive the event, mark the address, stop sending.

SES helps with the account-level suppression list. Once enabled for bounces and complaints, SES refuses to deliver to any address on the list and counts the attempt as a suppressed send rather than a bounce. You can list, add and remove addresses.

In the console these settings are under Configuration > Suppression list. The separate, AWS-wide global suppression list (addresses that recently hard-bounced for any SES customer) is applied by SES regardless of your settings, which is why a send to a never-used address can bounce immediately. Remove an address from your own list only when the recipient has fixed the mailbox and asked to receive mail again.

Bookshelf’s feedback handler consumes Bounce and Complaint events from the EventBridge rule above, flags the customer record (so orders-api stops asking notifier to mail the address) and logs the SES messageId. The correlation uses the orderId message tag, because SES documents message tags as the reliable way to correlate events with sends.

Reference: Using the Amazon SES account-level suppression list, How email sending works in Amazon SES and put-account-suppression-attributes.

Mailbox providers decide where a message lands from your reputation. SES gives you three levels of visibility:

Practical rules that matter more than any feature: send only to people who expect the message, include a List-Unsubscribe header for anything that is not strictly transactional, keep the From domain the verified identity, and do not retry blindly on an auto-response or a hard bounce.

SES can also receive mail for a verified domain. Receipt rules (in a rule set, with an MX record pointing the domain at inbound-smtp.<region>.amazonaws.com) run actions such as storing the message in S3, publishing to SNS or invoking Lambda; the receiving feature is available only in some Regions. Mail Manager is the newer, broader product: ingress endpoints with traffic policies, rule sets, SMTP relays to a downstream mail server and message archiving. Tenants let one account separate sending streams (for example per customer of a multi-tenant SaaS) with their own reputation tracking and automatic pausing. Bookshelf needs none of them, so this page only names them; see the SES developer guide for each.

SES quotas are per Region and per account. The ones that matter first:

Quotas count recipients, not messages: a message to ten addresses uses ten of the daily quota. To request an increase choose Account dashboard > Request a sending limit increase (or use Service Quotas where listed), explain the volume and the bounce handling, and expect AWS to raise the limit in steps as your reputation allows. Check the current numbers in aws sesv2 get-account. Reference: Service quotas in Amazon SES and Managing your Amazon SES sending limits.

Prices change and differ by Region; this page names the dimensions and not the amounts. Check the Amazon SES pricing page and the AWS Pricing Calculator (both dated by the page, 2026-10-01 at the time of writing) before you plan.

Two AWS messaging products that older guides recommend are ending, and the replacement is SES or a non-AWS product:

For Bookshelf the only change is that new work targets SES for email and AWS End User Messaging for SMS or push.

SES identities and configuration sets cost nothing while idle, but event destinations, Route 53 records, SMTP users and templates remain until you remove them. Delete in this order:

Production access is an account setting and is not "cleaned up"; the account stays out of the sandbox. Delete the SQS queue and the Lambda or ECS service that consumed the events with the commands on their own pages. If you created the resources with CloudFormation, aws cloudformation delete-stack removes the identity, configuration set and records the stack owns.