I requested Amazon SES production access for a new AWS account and have been waiting about five days without a clear decision, despite an initial response suggesting I would hear back within 24 hours. The case appears to be moving between support teams.
This is a small, time-limited application for a closed group of up to 150 recipients connected to a government organization. It will send only transactional messages—such as login links and status updates—with an expected volume of 20 or fewer emails per day and roughly 2,000 messages over the application's lifetime. There will be no marketing email.
The recipient list is curated, and the application handles hard bounces and complaints through the SES suppression list and an SNS notification workflow. The sending domain has been verified with SPF, DKIM, and DMARC, and testing has been completed using verified addresses in the SES sandbox. The website is live with a login page and contact information.
The main possible concerns seem to be that both the AWS account and sending domain are relatively new. I can also clarify the opt-out process, provide sample messages, and request a very small initial sending quota if that would help. Has anyone dealt with a similar SES review, and what is the best way to move the request forward?
3 Answers
If the project deadline matters, I would avoid making SES approval the only path. A dedicated provider such as Postmark, Resend, Mailgun, SendGrid, or another SMTP service may be easier for a low-volume application. You can use that temporarily while keeping the SES request open in parallel.
SES can be inexpensive and reliable after approval, but the review queue is not a good dependency for a launch. For a very small test, manually verified sandbox addresses are also workable while the application is being finalized.
The lack of an unsubscribe or opt-out path for status messages could raise concerns. Even when mail is transactional, recipients should have a clear way to stop anything that is not strictly required, remove their address, or contact an administrator. Otherwise, someone who no longer wants the messages may just mark them as spam, which hurts deliverability.
I would separate security or access emails from optional updates, explain which messages are essential, and describe exactly how an administrator removes a recipient. Also include a real sample email with the footer and contact details.
That is a fair point. We can add a clearer opt-out and recipient-removal process before sending another update to the case.
A new account combined with a new domain is probably the biggest factor. Production access is a risk review, not just a check that your DNS records are configured correctly. Reviewers usually want a concise explanation of the consent source, application URL, sample messages, complaint and bounce handling, and why the requested quota matches the use case.
I would update the case with a short, reviewer-friendly summary and ask for a very small starting quota, such as 50 messages per day. Include the exact first-week volume rather than focusing only on the application's lifetime total. Unfortunately, the remaining step may simply be waiting for the review team.
We may proceed with a tiny test using three manually verified addresses and revisit production access before the next stage of the project.