Amazon SES production access request: what to write (and what gets rejected)

You need to leave the Amazon SES sandbox. The production access request form is five fields and a checkbox. Most people fill it in quickly and get denied with a template reply that says nothing useful.

The form is short but the bar is specific. AWS rejects applications that are vague about where addresses come from, unclear about bounce handling, or inconsistent about use case. This is the field-by-field breakdown: what to write in each box, what gets rejected and why, and two copy-ready templates you can adapt for transactional-only or mixed sending.

If you have already been denied and need to understand what went wrong or how to respond, AWS SES production access denied? What AWS actually wants covers denial psychology, what the reviewer checks, and the region-retry strategy. This post is the form itself.

What production access is and why it matters

New SES accounts start in a sandbox. You can send, but only to verified email addresses and domains (or the SES mailbox simulator), with a maximum of 200 messages per 24-hour period and 1 message per second. Sending authorization to non-verified addresses is disabled, and account-level suppression bulk actions are unavailable. This is enough for testing and not enough for anything real.

Production access removes those sandbox restrictions. You can send to any recipient address (though your From/Source/Sender/Return-Path identities must still be verified), and the 200-message-per-24-hours and 1-message-per-second caps are lifted. Your new sending limits appear in the SES console under Account dashboard → Sending limits. You can request increases through AWS Service Quotas or by opening a support case. You apply for production access through the SES console or the CLI, and AWS reviews the application manually. AWS Support provides an initial response within 24 hours, though it may take longer if they need more information. Denial comes with no explanation beyond “for security purposes, we cannot provide specific details.”

The application is a form. You describe what you send, how you got the addresses, how you handle bounces, and what volume you need. AWS uses it to decide whether you are a legitimate sender or a risk to Amazon’s IP reputation. The decision is a human reviewing what you wrote, not an automated check. That means the wording matters.

The production access request form, field by field

The form is in the SES console under Account dashboard → Sending request, or you can submit it via the AWS CLI with aws sesv2 put-account-details --production-access-enabled --mail-type TRANSACTIONAL|MARKETING --website-url ... --additional-contact-email-addresses ... --contact-language EN|JA. The fields are the same either way.

Once submitted, you cannot edit the details until the review is complete.

1. Mail type

This is a dropdown with two options: Transactional or Marketing.

Transactional means messages triggered by user action: password resets, order confirmations, receipts, account notifications. Recipients expect them because they triggered the send themselves.

Marketing means promotional email: newsletters, product updates, campaigns. Recipients opted in but may no longer want them.

Choose the type that represents the majority of your volume. If you send both, choose the type that accounts for more than half your sends. You can send both types from the same account — AWS does not restrict you to one or the other — but the reviewer evaluates your application based on what you declare. AWS monitors all accounts to keep complaint rates under 0.1% and bounce rates under 5%, and transactional email (which recipients triggered themselves) generating complaints is a stronger signal that something is wrong than marketing email generating the same rate.

Common mistake: choosing Transactional because it sounds more legitimate or easier to approve, then sending newsletters or campaigns. AWS monitors your sends after approval. If your complaint patterns look like marketing email but you filed as transactional, your account can be placed under review or probation. Declare what you actually send.

If you are genuinely sending both types in roughly equal volume, choose the one you will start with at launch. You can update your mail type later by reopening the production access case and describing the additional use case, but it is cleaner to be accurate from the beginning.

2. Website URL

The domain or URL where recipients can learn about you, where your signup form lives, or where the product you are emailing about is documented.

AWS checks this. If the URL is a coming-soon page, a domain parked with a registrar placeholder, or a URL that 404s, the application is denied. The reviewer wants to verify that you are a real business or product with a public presence.

What works:

https://example.com — your actual product or company site, live and navigable.
https://example.com/subscribe — the page where users sign up for your newsletter, if that is what you are applying for.
https://docs.example.com — a documentation site, if your product is developer-facing and the docs are the natural place a recipient would land.

What does not work:

A domain with no site, just a blank page or hosting provider default.
A site under construction or a landing page that says “launching soon.”
A URL to a login-walled application where the reviewer cannot see anything without an account.

The URL does not have to be the exact domain you will send from, but it should be obviously related. If you are sending from emails.example.com and your website is example.com, that is fine. If you are sending from example.com and your website is totallyunrelated.net, the reviewer will wonder why, and you should explain it in the use case description.

One edge case: if you are sending transactional email for a product that is not yet launched but has a real landing page describing what it does, that is usually acceptable. The reviewer is looking for evidence that you are not a spammer, not for proof of revenue or traction. A credible landing page is enough.

3. Use case description

This is the make-or-break field. In the console, it is a text box with no character limit and no structure. Most applicants write two sentences and get denied. AWS wants specifics.

(Note: The AWS CLI put-account-details command includes --production-access-enabled, --mail-type, --website-url, --additional-contact-email-addresses, and --contact-language, but does not have a parameter for use case description text. Use case detail is provided in the console form or in the resulting AWS Support case.)

The reviewer is trying to answer four questions:

Where do your addresses come from? Not “users sign up” — a spammer would say that too. The answer is: what form, what confirmation step, whether it is double opt-in, and whether you have ever purchased, rented, or imported addresses from a third party.
How do recipients stop receiving your email? The answer is: every message has an unsubscribe link, it is processed automatically, it takes effect immediately, and (if true) you support one-click unsubscribe per RFC 8058.
How do you handle bounces and complaints? Not “we monitor bounces” — that is an intention. The answer is: we have configured SES to send bounce and complaint notifications to SNS topics, we have subscribed an endpoint that writes the address to a suppression list, and every send path checks the suppression list before sending.
Is your volume plausible? Include your expected daily or monthly send volume and peak sending rate if relevant (AWS’s guidance for large senders asks for daily/weekly volumes and peak transactions per second in the use case description). If you are asking for high volume but your website describes a two-person team that launched last week, explain why. If you are sending only password resets and account notifications, say so and give a realistic daily figure. Do not inflate the numbers to look established — a volume claim that does not match your described business makes the application look implausible, and implausible gets denied.

The application that passes is the one that forces you to have already built the suppression system, not just plan to build it. The specific wording below assumes you have the SNS bounce and complaint topics set up, you have a working suppression handler, and you can describe a mechanism rather than a promise.

4. Additional contacts (optional)

Email addresses of other people at your organization who should be notified if AWS contacts you about your account. You can add up to 4 additional email addresses. This is optional. Leave it blank if you are a solo founder or if you are the only person who should receive compliance or reputation notifications.

If you add contacts, use real addresses. AWS does not verify them during the application, but if they send a compliance warning and the addresses bounce, that is a mark against your account’s credibility.

5. Preferred contact language

Choose English or Japanese. This determines the language AWS Support will use when communicating with you about your account. Most applicants choose English.

6. Acknowledgement checkbox

A required checkbox with a statement to the effect of: “I acknowledge that I will only send to people who have explicitly requested my email, and that I have processes in place to handle bounces and complaints.”

Check it. If you cannot honestly check it, do not apply — build the bounce and complaint handling first, then come back.

This is not fine print. It is a binding statement that AWS will evaluate you against if your account is later placed under review. If you checked the box and then ignored bounces or sent to a purchased list, the checkbox is evidence that you misrepresented your practices.

Two templates: transactional-only and transactional + marketing

The templates below are for the use case description field. They are not scripts to copy verbatim — they are structures that force you to include the four answers AWS wants. Replace everything in [brackets] with your actual system, and delete any sentence that is not true of your setup.

Template 1: Transactional email only

We send transactional email for [product name], a [one-sentence description of what it does]. Messages are password resets, login verification codes, order confirmations, and account notifications triggered by user actions. Recipients are registered users of our platform who provided an email address at signup and verified it by clicking a confirmation link sent to that address.

All email addresses are collected directly by us through our signup form at [example.com/signup]. We do not purchase, rent, scrape, or import addresses from third-party lists.

We have configured an SES configuration set with SNS event destinations for bounce and complaint notifications. These notifications are delivered to a Lambda function that writes the address to our suppression list in [DynamoDB / PostgreSQL / RDS]. Every send checks the suppression list before queuing the message. Hard bounces and complaints are suppressed automatically and permanently.

Transactional messages do not include an unsubscribe link, because they are account-related notifications that users cannot opt out of while maintaining an active account. Users can close their account at any time, which stops all transactional email.

We expect approximately [N] emails per day, primarily password resets and [other transactional type]. Our sending domain [example.com] is verified with DKIM, and we publish a DMARC policy at _dmarc.example.com.

Template 2: Transactional + marketing email

We send both transactional and marketing email for [product name], a [one-sentence description]. Transactional messages are password resets, receipts, and account notifications triggered by user action. Marketing messages are a weekly newsletter and occasional product updates sent to users who have explicitly opted in.

Transactional recipients are our registered users, who provide an email address at signup and verify it by clicking a confirmation link. Marketing recipients opt in separately via a checkbox during signup or through a subscription form at [example.com/subscribe]. The opt-in checkbox is unticked by default. After opting in, recipients receive a confirmation email and are added to the marketing list only after clicking the confirmation link in that email. We do not purchase, rent, scrape, or import third-party addresses.

Every marketing message includes a visible unsubscribe link in the footer and a List-Unsubscribe header with support for one-click unsubscribe per RFC 8058. Unsubscribes are processed programmatically and take effect immediately — there is no manual review, no support ticket, and no delay. Transactional messages are limited to user-triggered actions and do not include marketing content.

We have configured SES configuration sets for transactional and marketing sends separately. Both are routed to SNS topics that deliver bounce and complaint notifications to our application endpoint. The endpoint writes the address to our suppression list in [DynamoDB / PostgreSQL / RDS], which is checked before every send. Hard bounces and complaints are suppressed permanently. We monitor bounce and complaint rates in CloudWatch and treat sustained increases above 5% (bounces) or 0.1% (complaints) as incidents requiring immediate investigation.

We expect approximately [N] emails per day at launch, split roughly [X]% transactional and [Y]% marketing. Our sending domain [example.com] is verified with DKIM, and we publish a DMARC policy. We are separating transactional and marketing sends into different configuration sets to isolate their reputations.

What gets rejected: common reasons and how to avoid them

AWS does not tell you why your application was denied, but patterns emerge from enough denials. These are the gaps that consistently lead to rejection.

Vague use case with no mechanism

“We send emails to our users” is a category, not a description. “We monitor bounces and complaints” is an intention, not a mechanism. The reviewer cannot verify either statement.

The fix: name the concrete system. Not “we handle bounces,” but “bounce notifications are delivered via SNS to a Lambda function that writes the address to a DynamoDB suppression table, which is checked before every send.” If you cannot write that sentence, you do not have the system yet. Build it, then reapply.

No bounce or complaint handling

Applying without SNS bounce and complaint topics configured is the most common failure. AWS wants to see that you have built the suppression plumbing before you apply, not that you plan to build it.

Why this matters: if you describe a system you have not built and your application is approved, you are now sending production email with no suppression. Your bounce and complaint rates will climb, and AWS will place your account under review or probation within days or weeks. You have traded a denial for a much worse outcome.

Build the suppression system first. Then describe what you built. If you need help with the SNS and Lambda setup, the production access guide walks through the wiring in detail.

Purchased, rented, or scraped lists

If your addresses came from a list broker, a data provider, a scrape of public websites, or any source other than your own signup or transaction flow, AWS will deny the application. This is not negotiable.

Email addresses are not transferable property. A recipient who gave their address to Company A did not give permission to Company B, even if Company B bought the list. AWS does not approve production access for sending to third-party lists, and admitting that your addresses came from a third party is an automatic denial.

If you have addresses from a previous platform (you migrated from Mailchimp or another provider), that is different — those are still your addresses, collected by you. Describe the acquisition: “addresses were collected via our signup form between [dates] and migrated from [previous platform] on [date]. All recipients confirmed opt-in during the original signup flow.”

Coming-soon or incomplete website

If your website URL shows a placeholder, a domain-for-sale page, or a “launching soon” landing page with no real content, the application is denied. The reviewer cannot verify that you are a legitimate sender.

Launch a minimal public site first. It does not need to be beautiful or complete — a landing page that explains what the product does, who it is for, and how to contact you is enough. If you are sending email about something, there should be a public place where a recipient can go to learn what it is.

MailType mismatch between the form and reality

If you select “Transactional” but your use case description talks about newsletters, campaigns, or promotional updates, the application is inconsistent. Newsletters are marketing email. Select “Marketing” and describe your opt-in flow.

Conversely, if you select “Marketing” but you are only sending password resets and account notifications, you are describing transactional email. Select “Transactional” and clarify that recipients are your registered users and the sends are user-triggered.

The MailType field is not about what you wish you were sending or what sounds easier to approve. It is about what you actually send. Match the field to the description.

Unrealistic volume with no explanation

Requesting 100,000 emails per day when your website launched last week and has 50 signups is implausible unless you explain it. The reviewer sees the mismatch and assumes fraud or spam.

If your volume is legitimately high relative to your public presence — you are sending on behalf of a larger partner, you are migrating an existing user base, you are launching with a pre-built list from your previous product — say so. “We are migrating 30,000 users from [previous platform], where we have been sending email since [year]. Expected daily volume is [N] based on our current active user count.”

If your volume is modest, request modest limits. Asking for 10,000 or 20,000 emails per day is more credible for a new product than asking for 500,000, and you can increase the quota after launch once you have clean metrics. AWS approves increases quickly for accounts with low bounce and complaint rates.

After you submit: what happens next

Once submitted, you cannot edit the details until the review is complete. AWS Support provides an initial response within 24 hours, though the review may take longer if they need additional information from you. You receive an email when the request is processed, either with approval or denial.

If approved

Your account moves to production immediately. The sandbox restrictions are lifted: you can send to any recipient address (though your From/Source/Sender/Return-Path identities must still be verified), the 200-message-per-24-hours and 1-message-per-second limits are removed, and account-level suppression bulk actions become available. Your daily send quota is visible in the SES console under Account dashboard → Sending limits.

Approval is not the finish line. AWS monitors accounts continuously. If your bounce rate rises above 5% or your complaint rate rises above 0.1%, AWS can place your account under review, probation, or (in severe cases) shut down your sending. Watch those two metrics. They are the leading indicators of list quality and suppression hygiene.

Enable CloudWatch alarms for bounce rate and complaint rate. Set the bounce alarm to trigger at 4% and the complaint alarm at 0.08%. This gives you early warning before AWS intervenes.

If denied

The email says “we are unable to grant your request” and “for security purposes, we are unable to provide specific details.” This is a template. Every denial gets the same message. It is not describing your specific failure — it is AWS’s standard reply.

What AWS actually wants covers what to do after a denial: how to rewrite the application, whether to retry in a different region, and what to change before your second attempt. The short version: fix the application first. Most denials are for vague use case descriptions or missing bounce handling. Reapplying with the same wording in a different region is not a fix.

You can reply to the support case if you have clarifying information or if you built the suppression system after the initial denial. AWS Support can reopen the case and re-review it. If you make a second application without changes, you will likely get a second denial.

One common mistake: assuming the denial means your use case is not allowed. Most denials are not about use case — they are about insufficient detail or missing suppression plumbing. Legitimate senders get denied for vague applications. Rewrite the use case description using the templates above, verify that your SNS topics and suppression logic are working, and reapply.

Region strategy: when to apply in a different region

Production access is granted per region. An application denied in us-east-1 does not affect your ability to apply in eu-west-1 or us-west-2. You can apply in multiple regions, and each is reviewed independently.

This is useful when you were denied in one region and you have improved your application. Apply in the region you actually want to send from — the one closest to your users or closest to your infrastructure. Do not apply in six regions at once. It looks like spam.

One legitimate use for multi-region applications: redundancy. If you want the ability to fail over to a different region if your primary region has an outage or your account in that region is placed under review, apply for production access in two regions. Use the same use case description for both. AWS does not penalize you for redundancy planning.

The checklist: verify before you submit

Before you submit the production access request, confirm:

If any of these is not true, fix it before applying. An incomplete application is denied, and a denial means rewriting the application, waiting for a second review, and delaying your launch.

The production access request is five fields and a checkbox. Three of them are straightforward. One of them — the use case description — determines the outcome. Write it as a description of a system you have already built, not a plan for what you will build. Name the mechanism. Be specific about acquisition, suppression, and volume. Link the pieces: the domain, the website, the bounce handler, the suppression list.

AWS approves legitimate senders. The bar is not high, but it is specific. Vague applications get denied. Applications that describe working suppression systems get approved.

If you are still in the planning phase and you need to understand what “working suppression system” means in practice, or if you have been denied and you are trying to figure out what to fix, the production access guide is the next read. It covers what AWS is checking, the SNS setup that converts promises into descriptions, and what to do after a denial.

If you are choosing between SES and a managed API and cost or lock-in is part of the decision, Resend vs Amazon SES compares pricing and ownership at real volumes.

Selva Mail is a licensed email platform that deploys to your AWS account and sends through your SES. It provisions the SNS topics, the suppression list, and the bounce handler as part of the deploy, which means the production access application describes a system you already have rather than one you still need to build. One-time license, $497. See what’s included.