I built my authentication system with Cognito, but launch is blocked because SES is still in sandbox and cannot send verification, password-reset, and other transactional account emails. I submitted two sandbox-exit requests and received the same generic rejection, with no explanation. My use case is limited to user-triggered Cognito emails and internal feedback notifications—no marketing—with fewer than 100 messages per day initially. The account is several years old but has low personal-project usage. I have a verified domain in us-east-1, Easy DKIM, a custom MAIL FROM subdomain, aligned SPF and DMARC, suppression handling, SNS bounce and complaint notifications, CloudWatch alarms, and linked terms and privacy pages. What else should I provide to improve the request, and is it better to keep Cognito while using another provider through a Lambda trigger?
4 Answers
For low-volume authentication mail, I would keep Cognito rather than replacing the entire authentication system. Wire the email provider behind a configurable sender so you can use a fallback while SES is being reviewed. Be explicit that the messages are only verification, password reset, MFA, or similar account notifications—not campaigns or cold outreach. A provider switch is usually much smaller than migrating auth, but it is worth keeping SES available because it is inexpensive once the account is approved.
Your DNS and authentication setup sound fine. This is probably an account-trust or abuse-prevention review rather than a configuration problem. Reopen or reply to the existing support case with a live signup URL, exact expected volume, sample verification and reset messages, and a clear explanation of how users trigger the mail. Also describe what happens after a bounce or complaint—such as adding the address to a suppression list, stopping future sends, and alerting when thresholds are exceeded. If approval remains blocked, you can keep Cognito and use a custom email sender Lambda trigger with another provider.
The request was eventually approved after the case was reopened and reviewed again. The strongest follow-up focused less on repeating DNS records and more on the real user flow, message examples, expected volume, and concrete bounce and complaint handling.
Make the request as specific and operational as possible. Include the exact Cognito templates, From address, sample subjects and bodies, the signup path reviewers can test, confirmation that all messages are user-initiated, and your bounce and complaint workflow. Explain how you will retain event records, suppress problematic addresses, and alert on unusual rates. It also helps to include your app URL, support or contact page, domain history, and a fallback plan so authentication is not completely dependent on an approval queue. Reviewers are often more concerned with whether unwanted mail could continue after something goes wrong than with whether DKIM is configured correctly.
I had included most of that but not a live signup URL. I’ll add one to the case, and if that still doesn’t work I’ll use the Lambda-based provider option.