I requested production access for Amazon SES and provided a detailed explanation of our email program, but the request was denied without a specific reason. We run an education website for adults covering relationships, intimacy, communication, and consent. The content is written and contains no explicit imagery.
Our planned email volume is small: fewer than 100 recipients initially and fewer than 2,000 messages per month within about a year. We are starting with no active list. Addresses from an older plugin were deleted and will not be reused.
Readers subscribe through an intentional form on our own website. We do not buy, rent, scrape, import, or pre-check subscriptions. Every address uses double opt-in: the address remains pending until the recipient clicks a unique, expiring, single-use confirmation link. Unconfirmed addresses are deleted after 14 days.
We use format validation, MX checks, disposable-domain blocking, typo detection, honeypot protection, and per-IP rate limiting. Every message includes one-click unsubscribe support and the appropriate List-Unsubscribe headers. Bounces and complaints are sent through Amazon SNS to an automated suppression list, and hard bounces or complaints are suppressed permanently. We also monitor bounce and complaint rates and would pause sending if they became problematic.
The account is about five years old but has very little usage, averaging roughly $0.50 per month for services such as storage and Lambda. The request was rejected with only a generic message saying that the sending-limit increase could not be approved.
What information might be missing? Should I change the request, ask for reconsideration, or use another email provider?
4 Answers
You can submit a concise manual reconsideration request rather than repeating the entire explanation. Emphasize that the list is built only through confirmed opt-in, show the live signup flow, describe the exact email types and expected volume, and clarify how suppression is enforced. It may also help to verify the domain and sender identity first and provide a sample of the actual content.
SES usually does not reveal the exact risk signal behind a denial. In this case, the combination of an almost-unused account, a new or low-history sending domain, no sending history, and content involving adult relationships or sexuality may have triggered an abuse-risk review even though the program is legitimate. A detailed compliance description helps, but it does not guarantee approval.
Before requesting another review, make the technical setup explicit. Include the website URL, signup page, privacy policy, unsubscribe page, and an example email if possible. Explain that the From address uses your website domain, that SPF, DKIM, and DMARC will be configured, and whether messages are sent through the SES API or SMTP. Also state that each message has one identifiable recipient rather than using hidden or bulk-recipient tricks.
Another provider may be the practical option, especially while you establish domain and sending history. You do not have to move the rest of your infrastructure away from Amazon. Choose a service whose acceptable-use policy clearly permits educational sexual-health or relationship content, since some providers prohibit adult-related material broadly even when it is non-explicit.
A provider that accepts transactional or newsletter traffic may still review the content category, so check its policy before building the integration. Using a separate provider temporarily can also give you measurable delivery history if you later reapply to SES.
Account age alone may not be enough. Providers often care more about actual history, verified identity, domain reputation, and whether the proposed content fits their acceptable-use rules.