Amazon SES Setup for Tracking Bounces and Complaints

Objective

To configure Amazon SES to capture and analyze bounce and complaint notifications for emails sent through SES, ensuring efficient handling of email delivery issues and maintaining sender reputation.

Set Up Amazon SES

Verify Your Domain/Email Address:

• Go to the Amazon SES console.
• Verify the email addresses or domain from which you plan to send emails.
• Optional: Add the TXT, CNAME, and MX records to your DNS for domain verification (if sending from a domain).

Optional: Enable DKIM (DomainKeys Identified Mail):

• In SES, enable DKIM to sign emails and improve deliverability.
• Update your DNS with the DKIM records provided by SES.

Send Test Emails

• Use the SES console or an application to send test emails to ensure the setup is correct.

Configure Bounce and Complaint Notifications

Create a Configuration Set:

• In SES, create a configuration set to track email sending events like bounces or complaints. Attach Event Destinations:
• Create new Amazon SNS as an event destination in the configuration set.
• Specify which events (bounces/complaints) you want notifications for.

Note: Make the separate event destination for bounce and complaint in configuration set.

Set Up Amazon SNS for Notifications

Subscribe to the Topics:

• Add subscriptions to the topics based on your preference:
• Email (to receive notifications in your inbox).

Outcome

By completing this setup, you will:

• Automatically track emails that are bounced or marked as complaints.
• Receive notifications through Amazon SNS.
• Use the data to improve email deliverability and reduce sending to invalid or flagged addresses.
• You can also check the suppression list in SES to see the list of bounce and complaint.

Comments

[Odinaka Robert Nnamani]

Good walkthrough — one design note on the separate event destinations: a single destination carrying both event types works too, since every SNS message carries a notificationType field your endpoint can route on; separate topics only pay off when you want independent retry/DLQ policies per type. Worth adding: the SNS email subscription is fine for visibility but can't parse JSON — real suppression needs an HTTPS or Lambda subscriber that classifies on bounceType/bounceSubType and only suppresses Permanent bounces, since retrying transients is how bounce rates compound toward SES's ~5% pause threshold. Did you end up wiring the HTTPS endpoint, or is email subscription where it stopped?

[Odinaka Robert Nnamani]

Smit — you walked through the full manual SES bounce/complaint setup: domain verification, DKIM, config sets, SNS destinations. rootmail's beta is open now, and it replaces that entire walkthrough.

What took you a full guide to document becomes a signup flow. Bounce classification, suppression, delivery visibility — managed, not hand-rolled.

8 seats, closed beta. You felt the setup cost directly, so you'd know immediately if we're actually eliminating it.

Want in? rootmail.io/beta