The Amazon SES sandbox: what it limits and how to get out of it

The Amazon SES sandbox is the restricted mode every new SES account starts in. While you're in it, you can only send to email addresses and domains you've verified (or to the SES mailbox simulator), up to 200 messages per 24 hours and 1 message per second. To leave it, you request production access from the SES console, describing what you send and how you handle bounces and complaints. AWS gives an initial response within 96 hours. All of this is per AWS Region.

Everything below comes from AWS's own production access documentation and sending quota pages, checked in October 2026. AWS changes these pages, so confirm before you rely on a detail.

What does the SES sandbox restrict?

AWS puts new accounts in the sandbox to prevent fraud and abuse and to protect sender reputation, its own and yours. You can use every SES feature, but with these limits:

Two points catch people out. First, the sandbox is per Region: approval in us-east-1 does nothing for eu-west-1. Second, production access doesn't remove identity verification. You still have to verify every address or domain you use as the From, Source, Sender or Return-Path.

The sandbox is fine for building and testing. The mailbox simulator lets you trigger bounces and complaints on purpose, which is exactly what you should test before applying.

Before you request production access

A little preparation makes the request stronger and saves a round of questions:

1. Verify your sending domain. AWS calls this a best practice that helps requests get approved faster. Publish the DKIM records SES gives you, plus SPF and DMARC; our guides to DKIM and DMARC cover the records.
2. Build bounce and complaint handling, and test it. AWS's messaging blog recommends testing this before you apply. At minimum, set up event notifications (for example through Amazon SNS) and check that a simulated bounce reaches your app and stops further mail to that address. Accounts created since November 2019 also use the account-level suppression list by default, which stops SES sending to addresses that hard bounced or complained.
3. Make your website match your use case. AWS asks for your URL "to help us better understand the kind of content you plan on sending." A placeholder page, or a site about something else, works against you.
4. Know your numbers. Expected emails per day and per week, and your peak sending rate per second.

How to request production access, step by step

From the SES console, as of October 2026:

1. Open the Amazon SES console in the Region you'll send from.
2. In the navigation pane, choose Account dashboard.
3. In the box that says your account is in the sandbox, choose View Get set up page, then Request production access.
4. Choose Marketing or Transactional, whichever describes the majority of your mail. AWS defines marketing as one-to-many promotional mail to a targeted list, and transactional as one-to-one mail triggered by a user action, like a receipt or password reset.
5. Enter your Website URL.
6. Under Additional contacts, add up to four email addresses that should get messages about your account. Add a monitored team address, not just your own.
7. Choose a Preferred contact language (English or Japanese).
8. Tick the Acknowledgement box: you agree to send only to people who explicitly asked for your mail and confirm you have a process for bounce and complaint notifications.
9. Choose Submit request.

You can also do it from the command line, which helps if you're automating account setup:

aws sesv2 put-account-details \
  --production-access-enabled \
  --mail-type TRANSACTIONAL \
  --website-url https://example.com \
  --additional-contact-email-addresses ops@example.com \
  --contact-language EN \
  --region us-east-1

Once submitted, you can't edit the details until the review is complete. AWS may follow up in a support case asking about your use case, so watch the inbox for your AWS account's email address and the additional contacts.

What to write in your use case

AWS says it considers each request carefully, and its own blog post on moving out of the sandbox stresses that it's important to provide specifics. A request that only says "please remove us from the sandbox" invites questions or a denial. Cover these points in plain sentences:

What your company does and what you'll send. Describe one or two concrete use cases: "We run an appointment-booking app for physiotherapy clinics. We send booking confirmations, reminders 24 hours before an appointment, and password resets." If you can, paste a sample email for each, with personal details removed.

Where your recipients come from. Explain how addresses get onto your list: users who create an account, customers who book, subscribers who confirm by double opt-in. Say plainly that you don't buy, rent or share lists; AWS's terms prohibit sending to purchased or rented lists. If you send marketing mail, say how people opt in and whether you confirm signups.

How you handle bounces and complaints. Say what happens when you're notified: "Bounce and complaint notifications go to an SNS topic; our app marks the address as undeliverable and never sends to it again. We also keep the SES account-level suppression list on." AWS's blog asks this question in two parts: how you're notified, and what you do after.

How people unsubscribe. For marketing mail, describe the unsubscribe link and how fast it takes effect. If you send to Gmail and Yahoo at volume, mention one-click unsubscribe (RFC 8058), which they require for bulk marketing mail; our Gmail and Yahoo bulk sender guide has the details. For purely transactional mail, say that it's transactional and that you send no marketing.

Your volume. Expected daily and weekly volume and peak messages per second. You can request a higher sending quota in the same request.

Any earlier denial. If you were refused before, say so and explain what changed.

How long does it take?

AWS's documentation says the AWS Support team provides an initial response within 96 hours, and grants requests within that window when it can. If AWS needs more information, it takes longer. If AWS asks questions, answer them in the support case with the same specifics as above.

Plan around the 96 hours. Don't schedule a launch for the day after you submit.

Common reasons for rejection, and what to do

AWS usually doesn't give a detailed reason for a denial. Based on what its documentation and blog ask for, these are the gaps that most often lead to one:

To try again, reply in the existing support case with the missing details rather than opening a fresh one, and mention what changed.

Sending quotas after approval, and how they grow

SES has two main limits per Region: a sending quota, the most recipients you can send to in a rolling 24-hour period, and a sending rate, the most messages SES accepts per second (short bursts above it are allowed). Quotas count recipients, not messages: one email to 10 people uses 10. AWS doesn't publish a fixed starting quota for production accounts; it varies with your use case.

If you go over a limit, SES drops the message and doesn't retry it. The API returns a ThrottlingException with "Daily message quota exceeded" or "Maximum sending rate exceeded"; SMTP returns 454 Throttling failure. AWS suggests waiting up to 10 minutes and retrying, so build that backoff into your sender.

Quotas grow in two ways:

• Automatically. SES may raise your quotas, often before you need them, if you send real production mail (not tests to fake addresses), regularly approach your daily quota without exceeding it, send content recipients want, and keep bounce and complaint rates low.
• On request. In the Service Quotas console, choose your Region, then Amazon Simple Email Service (SES), pick the sending quota or rate, and request an increase. AWS aims to answer within 24 hours, as of October 2026, but may refuse if the use case doesn't fit its policies.

A higher quota doesn't make mailbox providers trust you faster. If you'll move a lot of volume onto a new setup, ramp gradually; our IP warm-up guide explains why, and the SES dedicated IP guide covers how SES warms dedicated addresses.

After the sandbox: keeping production access

Leaving the sandbox isn't the last check. AWS monitors bounce and complaint rates on every account and places accounts under review at a 5% bounce rate or a 0.1% complaint rate, and may pause sending at 10% or 0.5%. Our guide to an Amazon SES account under review covers what triggers that and how to recover. Set up CloudWatch alarms on those metrics on day one.

It's also worth knowing what SES's $0.10 per 1,000 emails covers and what you build around it. Our Amazon SES pricing explainer has the full cost picture as of October 2026.

If you'd rather not run the AWS side

SES is the cheapest way to send email at scale if you're comfortable with AWS and happy to build event handling, logs, alerts and pause logic around it. Many teams are, and for them it's a good choice.

If you aren't, OwnMailServer is managed sending with a Resend-style API and SMTP. There's no sandbox, but there is a review: we check every signup's website, domain and list source, usually within one business day, and we don't accept cold outreach or bought lists. Warm-up, monitoring, suppression and automatic pauses are included. It costs more per email than SES on a shared IP; at 250,000 emails a month with a dedicated IP it's about the same. The trade-offs are on our Amazon SES alternative page, and prices are on the pricing page.