Blog/aws ses production access

AWS SES Production Access: How to Get Out of the Sandbox

Request AWS SES production access step by step: the console form, the CLI call, what to prepare, how to track the review, and what to do if it stalls.

7 min readUpdated Oct 22, 2026

To get AWS SES production access, open the SES console in the region you send from, go to Account dashboard, choose View Get set up page, then Request production access, and submit the short form (mail type, website URL, contacts, and an acknowledgement). You can do the same from the CLI with aws sesv2 put-account-details --production-access-enabled. AWS says it gives an initial response within 96 hours, and the approval only applies to that one region.

Until then, your account is in the SES sandbox: you can only send to verified addresses, at most 200 messages per 24 hours and 1 per second. The rest of this guide covers what to set up before you ask, the exact form and CLI call, how to check the review from code, and what to do when the request stalls or gets denied.

What the SES sandbox blocks

Every new SES account starts in the sandbox, and the sandbox status is separate in each AWS Region. Here is what changes when you leave it, from the AWS production access docs:

SandboxProduction
RecipientsVerified addresses and domains, plus the mailbox simulatorAny address
Daily quota200 messages per 24 hoursSet for your use case
Send rate1 message per secondSet for your use case
Sending authorizationDelegates cannot send to unverified addressesNormal
Account suppression listBulk actions and suppression list API calls disabledAvailable
From, Sender, Return-PathMust be verifiedStill must be verified

The last row trips people up. Production access removes the recipient restriction, not the sender one. You still need a verified identity for every From address in every region you send from. For domains you add to Mailmark, the domain setup docs list the DNS records that verify them.

Quotas count recipients, not messages: one email to 10 recipients uses 10 of your 200, according to the sending quota docs.

Before you request: a checklist

The form takes two minutes, but a thin request is what gets questions back from the reviewers. AWS recommends verifying a domain first because it gets requests approved faster. Have these in place before you submit:

  • A verified domain identity in the region you will send from, with its DKIM records published. If you are new to the records involved, the DNS setup guide walks through MX, SPF, DKIM, and DMARC.
  • Bounce and complaint handling that actually runs. The form makes you confirm you have a process for bounce and complaint notifications. Point SES feedback at an SNS topic or an inbox (setup docs) and make sure bounced and complaining addresses get removed from your lists.
  • A live website at the URL you will enter, ideally on the same domain you send from, that shows what your product is and where people sign up.
  • An opt-in story. Know how every recipient asked for your email (signup, purchase, password reset) and how they unsubscribe.
  • A list of regions. Decide every region you will send from. Each one needs its own request, identities, and DKIM setup.

Region mismatch

The most common "I was approved but I'm still sandboxed" case is a region mismatch. Your app sends through eu-west-1 while the request was approved in us-east-1. Check the region in your SDK client or SMTP endpoint before anything else.

Request production access in the console

From the AWS procedure:

  1. Open the SES console and switch to the region you want to send from.
  2. In the navigation panel, choose Account dashboard.
  3. In the "Your Amazon SES account is in the sandbox" box, choose View Get set up page, then Request production access.
  4. Pick Marketing or Transactional, whichever describes most of your mail (the table below helps).
  5. Enter your Website URL.
  6. Under Additional contacts, add up to 4 addresses that should hear about your account.
  7. Choose a Preferred contact language (English or Japanese).
  8. Tick the Acknowledgement that you only send to people who asked for your email and that you handle bounces and complaints.
  9. Choose Submit request.

AWS opens a support case for the review automatically. You can't edit the details while the review is open.

Marketing or Transactional?

You mostly sendChoose
Password resets, receipts, signup confirmations, alerts triggered by a user actionTransactional
Newsletters, product announcements, promotions to a listMarketing
Both, but most volume is app notificationsTransactional
Both, but most volume is campaignsMarketing

AWS defines transactional mail as one-to-one and triggered by a user action, and marketing mail as one-to-many promotional content. Pick the one that matches the majority of what you send. A mismatch between your answer and your website is an easy reason for a reviewer to ask questions.

Request it with the AWS CLI

The CLI is handy if you script account setup or need several regions. The put-account-details reference lists --mail-type and --website-url as required. It also accepts an optional --use-case-description of up to 5,000 characters, which the console form no longer asks for:

aws sesv2 put-account-details \
  --region us-east-1 \
  --production-access-enabled \
  --mail-type TRANSACTIONAL \
  --website-url "https://example.com" \
  --contact-language EN \
  --additional-contact-email-addresses ops@example.com \
  --use-case-description "$(cat ses-use-case.txt)"

Run it once per region, changing --region each time.

A use case description you can adapt

Reviewers want to know what you send, to whom, how those people opted in, and what happens when an address bounces or complains. Here is a worked example for a typical SaaS app. Replace the placeholders with your real details; do not submit claims you can't back up.

[App name] (https://example.com) is a [what it does] for [who uses it].
We send transactional email only: account verification, password resets,
receipts, and alerts the user configures. Every recipient is a registered
user who created an account and verified their address.

Expected volume: about [N] emails per day in this region.

Sending domain: mail.example.com, verified in SES with DKIM. SPF and DMARC
are published.

Bounces and complaints: SES notifications go to an SNS topic. A worker
suppresses hard-bounced and complaining addresses immediately so we never
send to them again. Users can turn off non-essential notifications in
their settings, and marketing email is not sent from this account.

Check the review status from code

The console shows a banner, but the API tells you more. GetAccount returns whether production access is on, the open review's status and case ID, your quota, and your reputation status. With the AWS SDK for JavaScript v3:

import { SESv2Client, GetAccountCommand } from "@aws-sdk/client-sesv2";

// Sandbox status is per region, so check every region you send from.
const regions = ["us-east-1", "eu-west-1"];

for (const region of regions) {
  const ses = new SESv2Client({ region });
  const account = await ses.send(new GetAccountCommand({}));

  console.log(region, {
    production: account.ProductionAccessEnabled,
    review: account.Details?.ReviewDetails?.Status, // PENDING | GRANTED | DENIED | FAILED
    caseId: account.Details?.ReviewDetails?.CaseId,
    max24h: account.SendQuota?.Max24HourSend,
    perSecond: account.SendQuota?.MaxSendRate,
    reputation: account.EnforcementStatus, // HEALTHY | PROBATION | SHUTDOWN
  });
}

Or from a shell: aws sesv2 get-account --region us-east-1.

Mailmark's bring-your-own-AWS connection runs the same GetAccount check when you connect an account and shows an SES sandbox badge until production access is on.

The ReviewDetails status values mean:

StatusMeaningWhat to do
PENDINGUnder reviewWait, and watch the case for questions
GRANTEDApprovedConfirm ProductionAccessEnabled is true in that region
DENIEDNot approvedReply on the case with the missing details (see troubleshooting)
FAILEDAWS didn't receive the requestSubmit it again

While you wait, you can still test your full pipeline. The SES mailbox simulator works in the sandbox, and mail to success@simulator.amazonses.com, bounce@simulator.amazonses.com, or complaint@simulator.amazonses.com doesn't count against your daily quota or your reputation metrics. It's a good way to prove your bounce and complaint handling works before a reviewer asks.

Troubleshooting

SymptomLikely causeFix
MessageRejected: Email address is not verified. The following identities failed the check in region ...The account is still sandboxed in that region, or a From or Return-Path address isn't verified thereCheck ProductionAccessEnabled in that exact region, and verify the sending identity in that region
Approval email arrived, sends still failYour app sends from a different region than the one approvedMatch the SDK or SMTP region to the approved one, or request access in the other region
No answer after 96 hoursReviewers asked a follow-up question on the caseOpen Support Center, find the case from ReviewDetails.CaseId, and reply
Status is FAILEDAWS never received the requestSubmit the request again
Status is DENIEDThe request didn't show a clear opt-in, content, or bounce handling storyReply on the case with specifics: how recipients sign up, sample content, volume, and how bounces, complaints, and unsubscribes are handled
Throttling or quota errors after approvalYou're above your new daily quota or send rateRead SendQuota from GetAccount, then request an increase
Sending from EC2 over port 25 times outEC2 throttles port 25 by defaultUse port 587 or 465 for SMTP, or ask AWS to lift the throttle

Keeping production access once you have it

Approval isn't permanent if your metrics slip. From the SES sending review FAQ:

  • Bounces: keep the rate below 2%. At 5% AWS places the account under review, and at 10% it may pause sending.
  • Complaints: keep the rate below 0.1%. At 0.1% the account goes under review, and at 0.5% sending may be paused.

Only hard bounces to addresses on domains you haven't verified count toward the bounce rate. The cheapest ways to stay under those numbers are to remove hard-bounced addresses immediately and to check addresses before the first send. If you're switching providers to SES and want to see the cost difference first, the SES savings calculator compares your volume across providers.

Frequently asked questions

How long does SES production access take?

AWS says it gives an initial response within 96 hours of your request. If the reviewers need more information from you, it takes longer, so answer their follow-up on the Support Center case quickly.

Is SES production access per region?

Yes. Sandbox status, sending quotas, and verified identities are all separate per AWS Region. Request production access in every region you send from; one Support Center case can cover several regions.

Do I still need to verify my domain after I get production access?

Yes. Production access lets you send to unverified recipients, but every address or domain you use as From, Source, Sender, or Return-Path must still be a verified identity in that region.

Does production access raise my sending quota?

It removes the sandbox cap of 200 messages per 24 hours and 1 per second. The new quota and rate depend on your use case, and you can ask for a higher quota in the same request or later through AWS Support.

What should I do if my SES production access request is denied?

Reply on the Support Center case for the request (its ID is in GetAccount under Details.ReviewDetails.CaseId) with the specifics a reviewer needs: how recipients opt in, what you send, and how you handle bounces, complaints, and unsubscribes.