Amazon SES Explained: Sandbox, Production Access, and Sending Quotas
How Amazon SES is organised: verified identities, the sandbox and production access request, sending quotas and send rate, the SMTP and API interfaces, and the authentication and anti-spam compliance work.
Amazon Simple Email Service (SES) is the email sending and receiving service inside AWS. It is not a mailbox product like Gmail; it is an outbound (and optionally inbound) mail engine that your applications call through SMTP or an API. This guide explains how SES is organised: verified identities, the sandbox and production access, sending quotas, the SMTP and API interfaces, and the authentication and compliance work you need to do before sending real traffic.
Identities: what SES lets you send from
Every message you send through SES must come from a verified identity. SES supports two kinds. An email address identity is verified by clicking a confirmation link that AWS sends to that address. A domain identity is verified with DNS records and lets you send from any address at that domain, which is what production systems normally use.
Domain identities are verified through DKIM. With Easy DKIM, SES generates CNAME records that you publish in your DNS zone, and AWS rotates the signing keys for you. If you prefer to manage your own keys you can use Bring Your Own DKIM and publish a TXT record instead. Either way, once the records resolve, the domain moves to a verified state in the SES console.
Identities are regional. A domain verified in us-east-1 is not verified in eu-west-1 unless you repeat the process there. Quotas, configuration sets and suppression lists are also per region, so most teams pick one region for mail.
- Email address identity
- Verified by confirmation link, one address only
- Domain identity
- Verified by DKIM DNS records, covers every address at the domain
- Custom MAIL FROM domain
- Optional subdomain you control, used for SPF alignment
- Scope
- Per AWS region
Sandbox versus production access
A new SES account starts in the sandbox in every region. The sandbox exists to stop unproven senders from harming the reputation of AWS mail infrastructure. According to AWS documentation, sandbox accounts can only send to verified identities or to the SES mailbox simulator, and they are held to a low daily quota and per-second rate. That is enough to test integration code, not enough to run a product.
To send to arbitrary recipients you request production access. The request is made from the SES console or the AWS Support Center and asks for concrete details: the region, the type of mail (transactional, marketing, or both), your website, how recipients opt in, how you process bounces and complaints, and an example message. AWS reviews the request and either grants access or asks for more information. The process and its questions are described in the SES production access documentation.
Sending quotas and how they change
SES enforces two numbers per region. The sending quota is the maximum number of recipients you can address in a rolling 24-hour period. The maximum send rate is how many messages per second the service will accept. Both appear on the SES console dashboard and through the API.
When production access is first granted, AWS assigns starting values. Those values are not fixed. AWS raises them automatically as an account sends steadily, keeps bounce and complaint rates low, and comes close to using its existing quota. You can also open a service quota increase request when you have a concrete need. The mechanics are covered in the managing sending quotas guide.
Marketplace listings often describe SES accounts by their quota. The variants on the CloudAccountHub product page are labelled SMTP 50K Limits and SMTP 100K Limits; the label states the quota tier as listed and nothing more. Whatever the starting number, the account keeps that quota only while sending stays within AWS policy.
| Limit | What it controls | How it grows |
|---|---|---|
| Sending quota | Recipients per 24 hours, per region | Automatic increases with healthy sending, or a quota request |
| Maximum send rate | Messages per second | Raised alongside the sending quota |
| Message size | Bytes per message including attachments | Fixed by AWS; check current documentation |
SMTP interface and the SES API
SES exposes two ways to hand it mail. The SMTP interface is the drop-in option: any application, CMS or mail library that speaks SMTP can point at the regional SES endpoint. SES accepts STARTTLS on port 587 and TLS-wrapped connections on port 465, with alternate ports documented for networks that block those. SMTP credentials are generated from an IAM user’s access key and secret, not your console password, so you can scope and rotate them like any other IAM credential. The setup is described in the SES SMTP documentation.
The SES API (currently SESv2) is what the AWS SDKs and CLI use. It supports raw messages, templated messages with per-recipient substitution, and bulk sends. It suits high-throughput systems because it avoids SMTP session overhead and returns a message ID you can correlate with later events.
Configuration sets and events
Both interfaces can tag messages with a configuration set. Configuration sets publish sending events (send, delivery, bounce, complaint, open, click, reject) to Amazon SNS, CloudWatch, Kinesis Data Firehose or EventBridge. Wiring bounces and complaints back into your application is how you stop mailing dead addresses, and AWS asks about it when you request production access.
Authentication, reputation and compliance
Deliverability depends on three DNS-based checks that receiving servers apply. SPF lists which servers may send for a domain. SES uses amazonses.com as the envelope sender by default, so for SPF alignment under DMARC you configure a custom MAIL FROM subdomain and publish its MX and SPF records. DKIM is handled by the identity verification described earlier. DMARC is a policy record you publish yourself that tells receivers what to do when SPF or DKIM fails; start with a monitoring policy and tighten it once reports look clean. The SPF, DKIM and DMARC setup article in this library walks through the records.
AWS tracks reputation metrics per account: bounce rate, complaint rate and, with Virtual Deliverability Manager enabled, engagement by mailbox provider. AWS documentation recommends keeping bounce rates under 5 percent and complaint rates under 0.1 percent, and describes the review process above those levels. The account-level suppression list stops SES from sending to addresses that recently hard-bounced or complained.
Legal compliance is your responsibility, not the service’s. Commercial mail sent through SES must follow the anti-spam law that applies to you and your recipients, such as CAN-SPAM in the United States, CASL in Canada, and GDPR and the ePrivacy rules in the European Union. In practice that means documented consent, a working unsubscribe mechanism, an accurate sender identity and a physical address in marketing mail. The AWS Acceptable Use Policy also applies, and purchased or scraped lists are a common reason accounts lose production access.
Where to go next
SES is a component of a normal AWS account, so everything here assumes the surrounding IAM, billing and region model. The AWS platform overview explains how those fit together.
- See the listed quota tiers on the Amazon SES account product page, or browse AWS account listings if you need a full account around SES.
- Read SPF, DKIM and DMARC setup before you request production access.
- Compare interfaces in SMTP versus API for sending email.
- Learn how reputation and warm-up work in Email deliverability basics.
- Browse every guide in the Cloud Library.