You're right! Bounces and complaints needs to be handled properly and the design does not reflect that.
SES uses account-level suppression lists, to avoid sending emails to addresses that has complaints, hard bounced or soft bounced a number of times. It does not automatically handle bounces sent over email, and I've not seen a provider out there doing that but I could be missing it.
We do manually monitor those however, by having the FROM address directed at an inbox that we monitor. Out of the 4M emails we send per month, we only get one bounce email back. And that's not really a bounce but a "please confirm you are real" bounce.
This could probably be automated with SES too, by parsing incoming emails and adding addresses to bounce list. For that 1 email per month we decided not to add that complexity.
Note: This setup is used for transactional emails, where users opt in via account creation and the first email sent is a verification email, to check that the address is real and that the user owns it.
SES uses account-level suppression lists, to avoid sending emails to addresses that has complaints, hard bounced or soft bounced a number of times. It does not automatically handle bounces sent over email, and I've not seen a provider out there doing that but I could be missing it.
We do manually monitor those however, by having the FROM address directed at an inbox that we monitor. Out of the 4M emails we send per month, we only get one bounce email back. And that's not really a bounce but a "please confirm you are real" bounce.
This could probably be automated with SES too, by parsing incoming emails and adding addresses to bounce list. For that 1 email per month we decided not to add that complexity.
Note: This setup is used for transactional emails, where users opt in via account creation and the first email sent is a verification email, to check that the address is real and that the user owns it.