How to get out of SES sandbox

Totally feel you. Random throwaway accounts with 50k prod access across regions are everywhere, and somehow those get auto-approved with zero real setup. No, you don’t need to deploy your app first — the issue is more about domain age, content, and SES being overly paranoid. Sadly, there’s no real support number — just the ticket system and patience.

Oh, you’re trying to get out of the SES sandbox the normal, legit way? Good luck! Hope you’ve got some patience and a flawless use case explanation, because you’re about to go through the same hoops many of us had to jump through — back when access actually meant something.

Funny thing though — while you’re busy crafting the perfect request, somewhere out there, someone’s buying a production-approved SES account for $5 on a shady forum, no questions asked. They’ll send spam all day long, burn the IP, and toss the account like a napkin. And we are the ones getting flagged, limited, reviewed, and delayed because of it.

I’ve had multiple accounts — all properly set up, verified domains, low complaint rates — and I still get throttled or reviewed. Meanwhile, the auto-approval system keeps the floodgates open for abusers.

So yeah… try your luck with the form. Be polite. Explain how you're not a spammer. Then pray it lands on someone who still cares — because clearly, the bots don’t.

Hi! No, you don’t need to deploy your Spring Boot app first — SES doesn’t require a live application to approve production access. That said, new domains or websites without much public content often trigger rejections. SES is quite strict, especially with new accounts.

Meanwhile, mystery accounts with no website and a Gmail contact get 50k limits across 3 regions. Classic. No, you don’t need the app live. You just need… well, no one really knows anymore. Welcome to the SES circus.

Getting out of the Amazon SES sandbox is an important step for sending emails to unverified addresses and increasing your sending limits. However, you don't need to have your Spring Boot application deployed on AWS before requesting to move out of the sandbox.

To request removal from the sandbox, you need to submit a case through the AWS Support Center. This process involves providing details about your use case, including:

1. The type of emails you plan to send
2. Your website URL
3. A description of how you'll use Amazon SES
4. Additional contact email addresses

It's important to clearly explain your intended use of SES for sending reset password emails through your custom domain. Make sure to emphasize that you'll only be sending emails to users who have explicitly requested them (in this case, for password resets).

If your requests are being rejected, it may be because you haven't provided enough information or your use case doesn't align with Amazon's policies. To improve your chances of approval:

1. Provide a detailed explanation of your email sending practices
2. Ensure you have proper authentication set up for your domain (SPF, DKIM)
3. Describe your process for handling bounces and complaints

Unfortunately, there isn't a specific customer service number to call for SES sandbox issues. The process is handled through the AWS Support Center.

If you continue to face rejections, you might want to consider:

1. Reviewing Amazon's best practices for sending emails
2. Temporarily using the sandbox environment for testing while you set up your application
3. Consulting with an AWS solutions architect or partner for guidance

Remember, even while in the sandbox, you can still send emails to verified addresses and use the Amazon SES mailbox simulator for testing. This allows you to set up and test your Spring Boot application's email functionality before getting production access.
Sources
Moving out of the Amazon SES sandbox - Amazon Simple Email Service
Request production access (Moving out of the Amazon SES sandbox) - Amazon Simple Email Service
Migrating to Amazon SES from another email-sending solution - Amazon Simple Email Service