If you’re like me and your web server’s hosted by AWS, you’ll eventually want your applications to send users emails, especially if your website supports things like user accounts. After my first attempt at getting approved for production access failed, I did some more thorough research into the matter before trying it again. You should take everything said here into account before requesting production access, as they may cut you off after several denials.
By default, Amazon SES places you in sandbox mode. It works fine, but there’s a severe limitation on who you’re allowed to send messages to. You can only send mail to verified identities, essentially meaning you’ll only be able to send mail to yourself (or people you work with that you manually add to the list). If you only ever need your program to send emails to yourself, you can just stay in Sandbox (provided you stay under the 200 daily limit). If you want to email anything outside your verified identities list, you’ll need to request production access.
Before you even open the form, consider the following…
AWS Is Very Strict on Mailing Lists
Although you may use SES for mass mail and marketing purposes, they are very strict with how this is handled. If you are using SES for marketing, you must provide detailed information about how you’re going to handle that mailing list. Some key things to remember:
- You must get consent from users before sending them any emails.
- If using mailing lists, provide detailed information on how you gain your lists and provide assurances that these people actually consented to your emails. If you buy a huge list of emails online and start sending away, Amazon will get mad at you. Ideally, the only email addresses you’re using in lists will be collected from your website via opt-in options. Or they will be clients of yours who have already given you permission to message them.
- Make sure there’s an easy way for users to unsubscribe from your mailing lists. Usually an “unsubscribe” link at the bottom of each email. Explain in detail where you’ll be putting the unsubscribe feature and how it is implemented.
- Ensure that you have policies in place to handle user complaints.
- Ensure that your system will not constantly bog the servers down with bounced email addresses. If an email is undeliverable, and you keep trying to send it, you’re wasting AWS resources and it will negatively affect your reputability metrics. You should have a system in place to remove the bounced addresses from your mailing lists, so it doesn’t keep trying to resend them.
Understand and Set Up Simple Notification Services (SNS)
AWS provides a complete guide on how to set up SNS with SES. Be sure to implement this prior to submitting your request for production access. Once setup, SNS will notify you at a specified email address whenever a bounce occurs or a complaint is received.
Have a plan in place for handling these bounce requests and complaints, and explain exactly what you will do in the details when you submit your request for production access. In my request, I said something like “SNS has been configured to alert the webmasters of any bounces or complaints via email. In the event of a bounce, the system will not retry sending the email, and the address will be removed from the system. If a complaint is received, the user’s account will be removed from my system and they will receive no further correspondence.”
For Transactional Purposes
This is what I specified when I got this website approved for SES. Things such as user account activation emails, password resets, etc. are transactional. Since my website only uses emails for these kinds of user-initiated events, I said exactly that in my approval request. I told AWS exactly how I obtain emails through the registration process, that the users agree to receive emails, they sign the website’s terms of service, and that users can delete their account (by checking my provided privacy policy).
I specifically told them that these emails are not automated and are only triggered upon the user request. Since I am not using this website for marketing purposes, I also said “no mass mailings will be sent from this service, it is purely for transactional events.”
After explaining that I’m not using SES for marketing purposes, that I had SNS setup, and that I had plans in place for handling issues, AWS approved me on my second try. So be sure to make sure you follow all of the above for the best chances of getting approved. If you fail more than once, I’ve read that they may permanently restrict you from production access with no options of recourse.
Common Reasons You May Not Be Approved
The age and payment history of your account may also be a factor in determining eligibility. If you just opened a brand-new account, haven’t used any other services, and are immediately trying to sign up for SES, it may seem suspicious.
Another reason you may not be approved is ignorance of the fact that AWS isn’t something like SiteGround or HostGator (I did this the first time when I submitted a poorly detailed request). You can’t just register an account, pay ten bucks, and start sending emails. That said, SES is much more reliable than what you’ll get through a shared web host. The chances of your emails actually making it to the inbox, and not spam, is much higher with SES than a lot of other cheap services.
Despite being called Simple Email Services, it’s really not that simple unless you’re already an experienced AWS user. Still, once you understand the basics, it becomes simpler. The first time I tried to request production access, I did not know I needed to set up SNS, which could be why I was immediately denied. I should have read their documentation more thoroughly the first time.
You must specify how you handle bounces and complaints!!!
The next reason most common reason people don’t get approved is probably because they’re missing things like privacy policies and terms of service, or did not explain how they got permission from the users to use their email addresses.
Don’t say you’re just using it for training purposes or testing. That defeats the purpose of a production environment. Only try to move to production after you’ve tested all your systems in the sandbox, and your site is ready for prime time.
You don’t have to write a thousand word essay, but you should convey all the above points in a clear, cohesive manner. The entire request should probably be no longer than a paragraph or two.
Keeping Your Status
Provided you don’t start sending massive amounts of unsolicited spam, you likely won’t have to do much to keep your SES account in good standing. However, AWS uses metrics to determine your “reputation” for sending emails. If your reputation falls too low, the service may be paused or ended indefinitely.
Other Resources
- Multiple End Customers (Multi-tenancy) Using SES (AWS Docs)
- If you need to send emails on behalf of many different customers you should read this blog post from AWS.