To move Amazon SES out of the sandbox, request production access for the exact AWS Region you will send from. First verify a domain, describe your real sending use case, publish a website, explain how recipients are obtained, and implement bounce and complaint handling. Approval removes recipient-verification restrictions; your production quotas remain region-specific and depend on the approved use case.
What the Amazon SES sandbox restricts
New Amazon SES accounts begin in the sandbox in each AWS Region. In sandbox mode, you can send only to verified email addresses or domains and to the SES mailbox simulator. AWS currently documents a limit of 200 messages per rolling 24 hours and one message per second. Quotas count recipients, not simply API requests.
The sandbox is useful for integration testing, but it blocks a normal production workflow: customers should not have to verify their own addresses before receiving a receipt, password reset, alert, or onboarding message.
Before you request SES production access
A strong request shows that a real business controls the sender, has a legitimate audience, and can stop harmful sending. Prepare these items first:
- Choose the correct AWS Region. Sandbox status, verified identities, and sending quotas are region-specific.
- Verify your sending domain. Domain verification is more scalable than verifying individual From addresses. Configure DKIM and plan SPF and DMARC alignment.
- Publish a working website. It should explain the product, business identity, contact route, and privacy practices.
- Define the message type. Be specific: password resets, invoices, account alerts, opt-in newsletters, or another clear use case.
- Explain recipient acquisition. State how users register or consent. Never imply that purchased or scraped lists will be used.
- Handle bounces and complaints. Configure SES event notifications, email feedback forwarding, or another reliable event pipeline and suppress unsafe recipients.
- Estimate realistic volume. Give current and near-term numbers rather than requesting an unjustified maximum.
If these controls feel like extra plumbing, that is the real operational difference between an email API and a complete delivery workflow. ArawaMail’s transactional email platform combines company-managed domains with sending for mailbox users, libraries, and API integrations, while ArawaMail API keys can be restricted to one domain.
How to request SES production access
1. Open the SES account dashboard in your sending Region
In the AWS console, switch to the Region where your application is configured. Open Amazon SES and choose the option to request production access. A production approval in one Region does not automatically remove the sandbox in another.
2. Select your mail type and provide a website URL
Choose the category that best matches the dominant traffic. Transactional mail is triggered by a user or system event; marketing mail is promotional or subscription-based. If you send both, describe both honestly and explain how consent, unsubscribe, and suppression differ.
For a clearer distinction, read what transactional email is.
3. Write a concrete use-case description
Avoid “we need email for our app.” A useful description names the product, recipients, triggering events, expected daily and peak volume, consent source, and controls for bounces, complaints, and unsubscribes.
Example: “Our SaaS sends account verification, password-reset, invoice, and security-alert messages to users who create accounts on our website. We expect 300 messages per day initially and a peak of 1,000. We verify our domain with DKIM, process SES bounce and complaint events, immediately suppress hard bounces and complaints, and do not use purchased lists.”
4. Submit and monitor the request
Review the details for accuracy, submit, and watch the AWS account’s contact email and Support Center. If AWS asks a follow-up question, answer directly with evidence about the website, recipients, sending process, and safeguards.
What production access changes—and what it does not
| Area | Sandbox | After production access |
|---|---|---|
| Recipients | Must be verified, except SES simulator addresses | Can be unverified; your From identity must still be verified |
| Daily quota | 200 recipients per rolling 24 hours | Region- and use-case-specific quota |
| Sending rate | 1 recipient per second | Region- and account-specific rate |
| Reputation duties | Required during testing | Still required; approval is not a deliverability guarantee |
Production access does not authenticate your domain for you, clean recipient data, guarantee inbox placement, or automatically make your application retry safely. Use SPF, DKIM, and DMARC correctly and investigate spam-placement causes before scaling.
Test the pipeline without damaging reputation
Use the SES mailbox simulator to test successful delivery, bounce, complaint, out-of-office, and suppression scenarios. AWS states that simulator messages do not affect your daily sending quota or deliverability metrics, although they remain subject to your maximum sending rate and are billable.
Then test your application end to end: event trigger, queue, API response, delivery event, bounce or complaint ingestion, suppression, retry policy, logs, and support visibility. Developers using Laravel can also compare their implementation with ArawaMail’s Laravel email guide and the email webhooks guide.
Common reasons a production-access request is weak
- The website is missing, unfinished, or unrelated to the stated sender.
- The use case is vague or the requested quota is disproportionate.
- The applicant cannot explain how recipients joined the list.
- There is no bounce, complaint, unsubscribe, or suppression process.
- The request is filed in a different Region from the application.
- The plan depends on cold outreach, scraped data, or purchased recipients.
How we analyzed this
This guide follows AWS’s current SES production-access, quota, simulator, event-notification, and suppression documentation. We separated three often-confused layers: account authorization (leaving the sandbox), identity authentication (proving and signing for a domain), and recipient-quality operations (handling consent, bounces, and complaints). ArawaMail documentation was checked separately so comparisons reflect its company-managed-domain, mailbox, and API architecture.
Frequently asked questions
Is Amazon SES sandbox status global?
No. Sandbox status is specific to each AWS Region. Request access in every Region from which you intend to send.
Do recipients need verification after SES production access?
No. Production access allows sending to unverified recipients, but the sender identity—an email address or domain—must still be verified.
How long does SES production approval take?
There is no safe universal time estimate. Submit a complete, verifiable request and monitor AWS for approval or follow-up questions.
Does leaving the sandbox guarantee inbox delivery?
No. It changes account restrictions. Delivery still depends on authentication, reputation, content, recipient quality, and how you respond to bounces and complaints.
Can I test bounces before production approval?
Yes. Use the Amazon SES mailbox simulator, which supports success, bounce, complaint, out-of-office, and suppression scenarios while the account is in the sandbox.