Getting production access on Amazon SES is the first hurdle. Keeping it is the ongoing one, and it comes down to two numbers AWS watches continuously.
The two metrics
| Metric | What it measures | Why it matters |
|---|---|---|
| Bounce rate | Messages rejected by the receiving server | Sustained high rates suggest poor list hygiene |
| Complaint rate | Recipients marking mail as spam | The strongest negative signal a receiver can send |
AWS publishes review thresholds for both. The safe operating position is well below them, not just under them, because the metrics are calculated over a rolling window and a single bad campaign moves them.
Hard and soft bounces
A hard bounce is permanent: the address does not exist. Remove it immediately and never send to it again. Continuing to send to known-bad addresses is what drives a bounce rate into review territory.
A soft bounce is temporary: mailbox full, server unavailable. Retry a limited number of times, then treat it as permanent. SES handles some retry logic, but your application should not keep queuing indefinitely.
Build this before you send at volume
- Create SNS topics for bounces and complaints.
- Configure a configuration set that publishes those event types.
- Subscribe an endpoint that writes events to your database.
- Suppress automatically. A hard bounce or any complaint adds the address to your own suppression list, checked before every send.
- Alert on rate changes, not just absolute numbers, so a developing problem surfaces early.
Relying only on the account-level suppression list is insufficient, because it does not stop your application from repeatedly attempting sends that will fail.
Preventing the problem upstream
- Confirmed opt-in where practical. It costs list size and buys deliverability.
- Never buy or scrape lists. This is the fastest route to suspension.
- Validate addresses at capture with syntax and domain checks.
- Re-engage or remove dormant addresses. Old lists accumulate spam traps.
- Honour unsubscribes immediately and put the link where people can find it. A hard-to-find unsubscribe converts into a complaint, which is far worse.
Separate your streams
Transactional mail such as receipts and password resets has very different engagement from marketing mail. Mixing them means a poorly performing campaign damages the reputation your password resets depend on.
Use separate configuration sets, and separate identities or dedicated IPs where volume justifies it, so the two reputations do not contaminate each other.
Authentication is prerequisite
None of this helps if your mail is not authenticated. Publish DKIM records, align SPF, and set a DMARC policy. See SES authentication setup and, for the sandbox and limits, SES production access explained.
Our Amazon SES listings cover configurations with 50K and 100K daily sending limits, already out of sandbox.
Common questions
What bounce rate is safe?
AWS publishes the thresholds at which accounts come under review. Operate well below them rather than near them.
Does SES suppress addresses for me?
There is an account-level suppression list, but you should maintain your own so your application stops attempting the send.
Do complaints from one campaign affect transactional mail?
They can, if both share the same identity and reputation. Separate the streams.