We're launching a new SaaS application and need Amazon SES only for low-volume transactional messages such as account verification, login one-time passwords, and password resets. We won't send marketing campaigns, use purchased lists, or perform bulk outreach, and we requested an initial sending limit of only 1,000 emails per day.
Our team already uses SES across several customer accounts without any history of abuse. During the review, AWS asked about our sending practices, which we explained in detail. They also asked why we couldn't use accounts where SES limits had already been increased. We explained that this is a new company, product, and AWS organization, so the account was deliberately created as a dedicated production environment.
Despite providing that information, AWS rejected the production-access request without giving a specific reason, stating that it could not disclose the assessment criteria. Being stuck in the SES sandbox is now delaying the application launch.
Has anyone successfully appealed a rejection like this? Is there an effective escalation path or a way to request a manual review? I understand the need to prevent email abuse, but the current process seems to block legitimate new products along with abusive senders.
4 Answers
The request should clearly document the application, expected daily volume, message types, signup and authentication flows, list-acquisition practices, bounce and complaint handling, domain verification, and unsubscribe or suppression behavior where applicable. If the initial request was rejected, submit a carefully revised request through the SES console and open a support case asking for the production-access review team to reassess it. There may not be a guaranteed escalation route, but a complete operational description gives the reviewers the most useful information.
A separate AWS organization can matter because SES reviews are account-specific and may have limited history to evaluate. The fact that other services are available to a new account doesn’t necessarily mean SES will treat it the same way; outbound email carries elevated abuse and reputation risks. That said, the lack of a specific rejection reason makes it difficult for legitimate teams to correct whatever triggered the decision.
If SES access is blocking the launch, using another transactional email provider may be the quickest practical workaround. It can be frustrating when the rest of the infrastructure is already in AWS, especially when auditing and compliance are easier with one provider, but SES approval isn’t guaranteed for every new account or organization.
Keeping everything in AWS is a reasonable preference, and SES is clearly designed for transactional SaaS email. Unfortunately, the current approval process appears to favor preventing abuse over making low-volume access immediately available to new customers. If support has already reviewed the case and won’t provide more detail, running email through another provider temporarily may be the only way to avoid delaying the product launch while continuing to request SES access.
Related Questions
Can't Load PhpMyadmin On After Server Update
Redirect www to non-www in Apache Conf
How To Check If Your SSL Cert Is SHA 1
Windows TrackPad Gestures