Amazon SES is the price leader for high-volume email. At serious sending volume, it is extremely difficult to beat on raw cost.
The trade-off is setup complexity. SES lives inside AWS, starts in sandbox mode, and expects the operator to be comfortable with IAM users, verified identities, regions, and AWS feedback infrastructure. For agencies already using AWS or planning for scale, those trade-offs are often worth it.
What Amazon SES is and when it makes sense
Amazon SES is best for agencies that either already know AWS or send enough volume that the price difference becomes meaningful. If volume is modest and simplicity matters more, SendGrid or Brevo are usually easier. If volume is high and cost control matters, SES is hard to ignore.
| Volume | Cost |
|---|---|
| First 62,000 emails per month | Free when sending from an EC2 instance |
| All emails | $0.10 per 1,000 emails |
| Dedicated IP | $24.95 per month per IP, optional |
At scale, SES can cost dramatically less than most other providers. The real question is whether the team is comfortable with the AWS side of the setup.
Understand sandbox mode first
Every new SES account starts in sandbox mode. That means you can only send to verified recipients, you are limited to one email per second, and your daily sending cap is heavily restricted.
This is normal. It is AWS's abuse-prevention step for new accounts, and moving out of sandbox is a one-time process.
- Only verified recipient addresses can receive mail while in sandbox
- The default sending limit is one email per second
- The daily send cap is 200 emails per day
- Production access requests are typically reviewed within 24 to 48 hours
Before you start
- An AWS account
- A domain or subdomain you want to send from
- Access to your DNS settings
- An IAM user with SES and SNS access
Part 1: create an IAM user with the right permissions
Inside AWS, create a dedicated IAM user for the platform rather than using root credentials. This is cleaner and safer.
Attach the `AmazonSESFullAccess` and `AmazonSNSFullAccess` policies, then create an access key and secret key for that user.
- Copy the Access Key ID and Secret Access Key immediately
- Use a dedicated IAM user rather than sharing broader AWS credentials
- SNS access matters because SES feedback is delivered through SNS infrastructure
Part 2: verify your sending domain in SES
In AWS, open the SES console, choose the region you plan to send from, go to `Verified identities`, and create a new domain identity.
Leave Easy DKIM enabled unless you have a specific reason not to. SES will then give you the DNS records needed for verification and DKIM signing.
- Choose the SES region first and remember it
- Use the same region later when connecting SES in the platform
- Wait until the identity shows as verified before treating the provider as ready
Part 3: request production access
If the account is still in sandbox mode, request production access from the SES account dashboard. In the request, describe the use case plainly: review request invitations sent to real customers of real businesses who are expecting those emails.
Clear, honest wording usually helps more than vague compliance language.
Part 4: connect SES in the platform
Go to `Platform -> Messaging -> Email`, click `Add Provider`, name the provider, expand `Other Providers`, choose `Amazon SES`, and move through the setup wizard.
| Field | What to enter |
|---|---|
| Key | Your AWS Access Key ID |
| Secret | Your AWS Secret Access Key |
| Region | The exact AWS region where SES was configured and the domain was verified |
If the region is wrong, verification fails even when the keys themselves are correct.
Part 5: throttling and AWS feedback setup
The default throttling should stay conservative while the account is still in sandbox. Once you receive production access, update the throttling to match the actual SES sending rate shown in the SES account dashboard.
During feedback setup, the platform creates the AWS plumbing needed for bounce and complaint tracking, including a Configuration Set and SNS resources.
- One email every one second is the correct sandbox-safe default
- After sandbox, update throttling to match your real SES send rate
- If feedback setup fails, the IAM user is often missing SNS permissions
Part 6: summary, sender details, and testing
- Use a from address on the verified SES domain
- Set clear from and reply-to details
- If sandbox is still active, test only with recipient addresses verified in SES
- After production access is approved, revisit throttling immediately
How SES interacts with custom-plan credits
SES changes the delivery provider. It does not change the custom-plan invite credit model in a normal agency-managed sending setup.
If an SES-powered invite fails because of credits, the usual problem is still the assigned customer plan email limit rather than the SES integration itself.
- Transactional emails remain separate from invite credits
- Normal agency-managed invite emails still respect the customer plan email limit
- The main exception remains customer-owned Gmail or Outlook sending from inside the customer account