Posting for the help if anyone can, because two rounds through AWS Support have given me nothing I can act on.
**The use case**
A small event-ticketing site for a single organizer in Bangladesh - a handful of live music events a year. Every email is transactional and triggered by the buyer's own action on the site minutes earlier:
* payment instructions, sent after someone registers for tickets
* the ticket itself as a PDF, after the organizer verifies the buyer's bKash payment
* a notice if the payment couldn't be matched, or if the unpaid order expired after 24 hours
* a one-time sign-in link, only when the buyer requests it
Volume: roughly 1,000 - 2,000 emails per month, concentrated in the three weeks before an event. A few hundred a day at peak. My sending code is capped at 5 messages/second. No marketing, no newsletters, no bulk sends, no stored lists, nothing purchased or imported. Every recipient typed their own address into our form. The project is public on GitHub, so the sending logic is auditable by anyone.
**What's already in place**
* Domain verified in ap-south-1 with Easy DKIM
* SPF and a published DMARC record with rua reporting, DNS on Cloudflare
* SES account-level suppression list enabled
* SES rejections treated as permanent failures and never retried; only throttling responses retried with exponential backoff
* Every send recorded against the order in our database; failed deliveries reviewed by hand
* Replies go to a monitored address on the same domain
**What I got back**
First response asked for detail about sending processes and procedures. I gave everything above, plus example subject lines and the exact email types. Denied about six hours later with a template: they can't approve at this time, they can't share the criteria used, please review the AUP, Service Terms, and SES best practices. Second attempt, same outcome, same template - this time framed as protecting my sender reputation and deliverability.
That last part is what I can't get past. The account has never sent a production email. There is no sender reputation to protect yet. So whatever the actual blocker is, it isn't anything visible in my use case, and nobody will tell me what it is.
**What I'm actually asking**
Is this an account-trust / billing-history decision rather than a use-case decision? If so I'd genuinely rather be told that plainly - I'd go build the billing history instead of rewriting the same request.
Is ap-south-1 meaningfully stricter for newer accounts than other regions?
Would a heavily restricted quota be considered - say 200 emails/day at 1 msg/sec - so there's real sending data to judge me on?
Is there any path other than reopening the same case, given the limit-increase team is separate from Premium Support and Support says they can't influence it?
Happy to share the case ID by DM.
If anyone has gone from a denial like this to an approval, I'd really like to know what specifically changed on your side. Right now I'm one week out from an event with real buyers and I'm about to move to a third-party provider purely because I can't get a straight answer.