We are building a similar serverless no-code inbox (with SES and S3) not for outgoing emails, but to only receive them [0].
Our service doesn't require a user to sign-up with any existing identity (like email or phone number), and so, when they make payments, we send the invoices from the payments-processor to an email (corresponding to the customer-id) on our subdomain that goes to SES which promptly plonks it into an S3 bucket set up to life-cycle it out after 60 days, encrypting it with keys associated with customer-id. This encryption serves us well when the customer chooses to rotate / delete their pseudo-anonymous identity (and the keys along with it), as then all data in our systems associated with their id (the archived emails, for example) is essentially tombstoned.
The reason we prefer serverless over other solutions is not because of its scale or low-cost, but high-availability.
Our service doesn't require a user to sign-up with any existing identity (like email or phone number), and so, when they make payments, we send the invoices from the payments-processor to an email (corresponding to the customer-id) on our subdomain that goes to SES which promptly plonks it into an S3 bucket set up to life-cycle it out after 60 days, encrypting it with keys associated with customer-id. This encryption serves us well when the customer chooses to rotate / delete their pseudo-anonymous identity (and the keys along with it), as then all data in our systems associated with their id (the archived emails, for example) is essentially tombstoned.
The reason we prefer serverless over other solutions is not because of its scale or low-cost, but high-availability.
[0] https://docs.aws.amazon.com/ses/latest/DeveloperGuide/receiv...