[rhooke]

These restrictions are only for the SES sandbox mode. You fill in a form to get out of sandbox mode and then you can send many more per day (still only 14/second or so).

You only verify addresses you want to send from (for testing you might verify one to try sending to as per the sandbox rules). You wouldn't get customers to verify their addresses here, as that would let you send email on their behalf.

See here: https://docs.aws.amazon.com/ses/latest/DeveloperGuide/reques...

[bmhin]

All very good info that as far as I know is all pretty unique to SES regarding the default/sandbox vs the upgraded production capabilities. The set up makes a lot of sense to prevent abuse and it works just fine out of the box for dev purposes. The production version also operates way more how you'd actually expect an email service to work.

All that said, I don't know of any other services that have this "production" upgrade that is needed other than maybe just the general service limits (which have always seemed more of a "protect you from yourself" situation) so it can be a touch confusing.

[acdha]

Sandbox mode is also great for low-volume internal mail like notifications from cron.

My guess is that the main argument for sandbox mode is that it requires you to explicitly say you don’t spam and will handle reports, giving them carte blanche to yank your account if you do. Given how slimy email marketing is I suspect someone at AWS didn’t want to deal with people lying to their support people all of the time.

[throwaway823882]

And once you are out of sandbox mode, it scales pretty well. We regularly send millions of mails in 24hr periods. Some gotchas come in when you need to set up DKIM/etc and other providers may need to handle mail for the same domain.