Challenge
A high-volume email system needs to handle delivery feedback as well as sending. Bounces and complaints provide signals that help the sender respond to delivery problems and protect sending quality. The goal was to build a scalable, event-driven pipeline that could process delivery notifications in real time and persist them for analysis.
My contribution
I deployed Sendy inside an AWS VPC and integrated it with Amazon SES for email delivery. On top of that, I built an event-driven feedback pipeline using SNS, Lambda, and DynamoDB to capture and store delivery receipts, bounces, and complaints automatically.
Infrastructure: Sendy on AWS
Sendy runs in a private subnet behind an Application Load Balancer. A Bastion Host in the public subnet provides SSH access for administration, while a NAT Gateway handles outbound traffic. SES credentials are managed through IAM, keeping secrets out of the application layer.
SMTP pipeline architecture
The SMTP pipeline captures SES delivery feedback through SNS topics. SES publishes delivery, bounce, and complaint events to SNS, which triggers a backend Lambda function to process and store each notification in DynamoDB. A separate path stores raw email data in S3, exposed through API Gateway to a frontend Lambda for dashboarding.
How it works
SES identity verification — domain identities are verified in SES and notification types (delivery, bounce, complaint) are mapped to SNS topics.
SNS → Lambda trigger — the backend Lambda subscribes to the SNS topic. Each event record is parsed to extract the notification type, sender, recipient, message ID, and timestamp.
DynamoDB storage — three tables capture the full delivery picture:
| Table | Records |
|---|---|
SMTPDeliveryNotifications | Successful deliveries with SMTP response |
SMTPBounceNotifications | Hard and soft bounces with diagnostic codes |
SMTPComplaintNotifications | Spam complaints |
The Lambda distinguishes hard bounces (Permanent/General, Permanent/NoEmail) from soft bounces and routes each record to the appropriate table.
Outcomes
Supported 1M+ emails per month and improved deliverability by 30% through automated bounce tracking and complaint suppression.
Engineering considerations
A successful send request is not proof of delivery. Duplicate SNS events, delayed notifications, and the distinction between a temporary soft bounce and a permanent hard bounce are worth handling explicitly — suppressing addresses after a hard bounce avoids reputation damage that affects the entire sending domain.
Supporting examples
Related learning material on monitoring and serverless security: