The three Amazon SES best practices that prevent account suspension are: keep your hard bounce rate below 2% (AWS pauses sending at 10%), keep your complaint rate below 0.08% (AWS pauses sending at 0.5%), and authenticate every message with SPF, DKIM, and DMARC (AWS, 2026). Everything else on this checklist - warm-up schedules, suppression lists, configuration sets, SNS feedback - exists to keep those three numbers safe. The rest of the post walks the full twenty-item list in the order you should implement them.
Why authentication comes first
AWS requires SPF, DKIM, and DMARC alignment for any sender above 5,000 messages per day under the 2024 Gmail and Yahoo bulk sender rules, and SES will refuse to enforce DMARC alignment if you verify only an email address instead of the full domain. Verify the apex domain in the SES console, enable Easy DKIM (AWS-managed 2048-bit keys published as three CNAMEs), publish an SPF record that includes amazonses.com, and add a DMARC record at _dmarc.yourdomain.com starting at p=none with an rua mailbox for aggregate reports.
Verify the sending domain itself, not just you@domain.com, because address-only verification cannot align DMARC. Use Easy DKIM at 2048-bit; only switch to BYODKIM (bring-your-own DKIM, where you generate and host the private key yourself) if your security policy forbids AWS-managed keys. Set SPF to v=spf1 include:amazonses.com -all, or ~all if you also send through other providers, and stay under the RFC 7208 ten-DNS-lookup limit. Start DMARC at p=none, monitor the aggregate reports for 30 days, then move to p=quarantine once alignment is clean. Finally, configure a custom MAIL FROM domain (the envelope sender, e.g. mail.yourdomain.com) so the SPF check aligns with your visible From address.
Why your list source decides your complaint rate
A 0.1% complaint rate triggers an AWS review and 0.5% triggers suspension, and the single biggest predictor of complaints is whether subscribers actually asked to hear from you (AWS, 2026). Purchased lists, scraped addresses, and single opt-in forms regularly produce complaint rates above 1% on their first send, which is ten times the AWS warning threshold. Double opt-in - a confirmation click on every signup - is the only practice that survives every ISP policy change.
Require that confirmation click on every signup form, and reject role addresses like info@, admin@, and sales@ at form submission because their complaint rates are an order of magnitude higher. Re-engage subscribers who have not opened in 90 days with a single sunset campaign, then remove the non-responders. Never import a list you did not collect yourself, since SES support will not reinstate accounts suspended for purchased-list complaints. For any list older than 30 days, run it through a validator such as NeverBounce or ZeroBounce before the first send.
How to warm up a new sending domain
ISPs throttle unknown senders by default, and a sudden jump from zero to 50,000 messages per day will inflate your bounce rate past the 5% review threshold within hours. AWS recommends ramping new domains gradually over 2-4 weeks. The pattern below mirrors what major ESPs use internally and is detailed in our Amazon SES warm-up guide.
Send to your most engaged 10% of subscribers first (recent openers and clickers), because their opens and replies build the positive reputation signal ISPs use to decide whether the next batch reaches the inbox. Double the daily volume every 48 hours, not every 24, so each new ISP has time to score the previous day's traffic. Never pause for more than 14 days mid-warm-up - reputation decays measurably after two weeks of silence. Hold send times to the same hour on the same weekdays throughout the ramp so the volume curve looks deliberate, not erratic.
How to handle bounces and complaints in real time
Only hard bounces count toward the 5%/10% AWS thresholds, but a hard bounce you send twice counts twice - so the cost of not suppressing them compounds with every campaign. Soft bounces (full mailbox, temporary 4xx errors) are excluded from the rate but should still trigger a retry-then-suppress policy after five consecutive failures. SES will publish every bounce and complaint event in real time to SNS (Amazon's pub/sub notification service), and the suppression list is account-wide.
Subscribe an SNS topic to bounce and complaint notifications on every verified identity, and use the account-level suppression list (the UpdateAccountSuppressionAttributes API) so suppressions apply across every configuration set. Auto-suppress on any hard bounce or complaint within 60 seconds of receipt, and set CloudWatch alarms at a 2% bounce rate and a 0.05% complaint rate - well below the review thresholds, so you have time to react. Never re-send to a hard-bounced address, even 12 months later; the underlying mailbox is gone, and the second attempt costs you reputation again.
Why every sending stream needs its own configuration set
A configuration set is SES's per-stream control plane (the unit that owns event publishing, sending pause, and IP-pool routing for a stream of messages). Without configuration sets you cannot separate transactional from marketing reputation, tag campaigns for analytics, or route events anywhere except the default. AWS recommends one configuration set per sending stream (transactional, marketing, password-reset) so a marketing reputation incident does not block your password reset emails.
Create at least three configuration sets named transactional, marketing, and system, and enable event publishing to CloudWatch for real-time rates plus Kinesis Firehose or S3 for long-term log retention. Tag every send with a campaign-id message tag so you can pinpoint which campaign drove a metric spike. When reputation degrades, disable sending on the affected configuration set instead of pausing the whole account - that keeps password resets flowing while marketing is held back.
Why ongoing authentication hygiene matters more than first-day setup
A DKIM key still in use from 2020 is a strong signal that the sending program is unmanaged, and forwarded mail can leak unsigned through mailing lists or auto-forwarding rules. The 2024 Gmail bulk sender rules explicitly call out DMARC alignment failures as a blocking factor, and DMARC aggregate reports (the RUA XML feeds your _dmarc record requests from each ISP) are the only way to spot new sending sources before they damage your reputation.
Rotate Easy DKIM keys at least every 12 months, noting that AWS only rotates BYODKIM keys on explicit request. Parse DMARC RUA reports weekly using a free tier from Postmark, Valimail, or dmarcian. Audit verified identities quarterly and remove any unused domain or address so a forgotten test domain cannot be hijacked. Re-verify DKIM after every DNS migration, because the CNAME records SES requires can silently break when zones move between providers.
How to keep SES costs and IAM blast radius small
SES charges $0.10 per 1,000 emails plus data transfer (AWS, 2026), but a compromised IAM key sending 10 million messages overnight will both bankrupt you and get the account permanently banned. Set a CloudWatch alarm on Send count, not just on dollar spend, because billing alarms lag by several hours and a runaway send finishes in minutes.
Alarm on any hour where send volume exceeds three times the trailing 7-day average, so a key compromise trips the alert before the bill does. Pick the SES region nearest your largest recipient cluster (sub-50ms regional latency matters for transactional mail). Skip dedicated IPs below roughly 100,000 emails per month; the shared SES pool has better warmed reputation at that volume. Scope every IAM role to ses:SendEmail on specific configuration sets, never ses:*, so a leaked key cannot also delete identities or change suppression rules.
The complete SES best-practices checklist
Twenty practices map onto five categories: authentication, list quality, sending pattern, feedback handling, and ongoing cost and security hygiene. The table below summarises every practice covered above, ordered by what to set up first.
| Practice | Category | Priority |
|---|---|---|
| Verify the sending domain (not address) | Authentication | Critical |
| Enable Easy DKIM 2048-bit | Authentication | Critical |
| Publish SPF including amazonses.com | Authentication | Critical |
| Publish DMARC at p=none with RUA | Authentication | Critical |
| Custom MAIL FROM domain | Authentication | High |
| Double opt-in on every signup form | List quality | Critical |
| Suppress hard bounces within 60s | List quality | Critical |
| 90-day re-engagement / sunset | List quality | High |
| Reject role addresses at signup | List quality | High |
| 14-30 day warm-up for new domains | Sending pattern | Critical |
| Double volume every 48 hours | Sending pattern | High |
| SNS bounce/complaint feedback | Feedback handling | Critical |
| Account-level suppression list | Feedback handling | Critical |
| CloudWatch alarms at 2% bounce / 0.05% complaint | Feedback handling | High |
| One configuration set per stream | Configuration | High |
| Event publishing to CloudWatch + S3 | Configuration | High |
| Rotate DKIM keys every 12 months | Ongoing | Medium |
| Parse DMARC RUA reports weekly | Ongoing | High |
| Volume-anomaly CloudWatch alarm | Cost / security | High |
| IAM scoped to ses:SendEmail per config set | Cost / security | High |
For a deeper walkthrough of deliverability tuning beyond this checklist, see our Amazon SES deliverability guide.
When a management layer earns its keep
Every practice on this list is implementable in raw SES with IAM, SNS, CloudWatch, and a Lambda or two. The reason teams adopt a management layer like Mailblast is that the work is real: suppression-list sync, double opt-in forms, configuration-set routing, DMARC report parsing, and per-campaign tagging take weeks to build from scratch and ongoing engineering hours to maintain. Mailblast sits on top of your own SES account (BYO-SES, where the AWS bill, the sending reputation, and full control stay with you) and handles the operational layer - drag-and-drop campaigns, subscriber lists, double opt-in, suppression sync, automation, and analytics - so the checklist above runs by default. See our Amazon SES deliverability guide for the deeper rationale.
FAQ
What bounce rate gets you suspended from Amazon SES?
AWS places your SES account under review at a 5% hard bounce rate and pauses sending at 10%. Only hard bounces - permanent failures like invalid mailboxes - count toward the rate. Soft bounces from full inboxes or temporary outages are excluded, so suppress hard bounces immediately to stay under 2%.
What complaint rate is safe on Amazon SES?
AWS flags accounts for review at a 0.1% complaint rate and suspends sending at 0.5%. That is one complaint per 1,000 emails for review and five per 1,000 for suspension. Healthy senders stay under 0.08%. Subscribe to SNS complaint notifications and remove complainers within minutes, not days.
Do I need DKIM and SPF and DMARC on Amazon SES?
Yes. SPF and DKIM are required for Gmail and Yahoo bulk sender rules, and DMARC with at least a p=none policy is mandatory for senders above 5,000 messages per day. Verify your sending domain (not just an address) in SES, enable Easy DKIM with 2048-bit keys, and publish a DMARC record before your first campaign.
Should I use a dedicated IP on Amazon SES?
Only above roughly 100,000 emails per month with consistent daily volume. Below that, the shared SES IP pool delivers better because AWS warms it continuously. A dedicated IP requires a 4-6 week warm-up and falls back to a cold reputation if you pause sending for more than two weeks.
What is the most common reason Amazon SES accounts get suspended?
Sudden volume spikes against a cold list. Sending 50,000 emails on day one from a new domain triggers ISP throttling, which inflates the bounce rate above 5%. The fix is a 14-30 day warm-up schedule starting at 50 messages per day and doubling every 48 hours while monitoring the reputation dashboard.
Disclosure: Mailblast is a hosted management layer for your own Amazon SES account. You keep the AWS bill, the sending reputation, and full control of the underlying SES configuration; Mailblast runs the operational layer (lists, double opt-in, suppression, automation, analytics) so the practices above stay in place by default.