AWS SES Sandbox Mode: Why You Can't Email Customers Yet (And How to Fix It)

You've wired up AWS SES, sent a test email to your own verified address, and everything looks perfect — then you try to email a real customer and hit a wall. This is the SES Sandbox, and understanding why it exists is the first step to getting out of it.

TL;DR

AspectSandbox ModeProduction Mode
RecipientsVerified identities onlyAny valid email address
Sending LimitsLow default quota (check AWS docs for current values)Higher default quota; can be increased further
Use CaseDevelopment & testingLive application traffic
How to ExitSubmit a production access requestN/A — you are already here
Bounce/Complaint Handling RequiredRecommendedMandatory for account health

Why Does the SES Sandbox Exist?

AWS places every new SES account in the Sandbox by default. This is a deliberate trust-building mechanism. Email deliverability is a shared resource — if AWS allowed any new account to immediately blast millions of emails, spammers would abuse the service, damaging IP reputation for every legitimate sender on the platform.

Real-World Analogy: Think of the SES Sandbox like a new driver's learner permit. You can drive, but only under controlled conditions (supervised, restricted routes). Once you demonstrate responsible behavior and pass the test, you get a full license to drive anywhere. AWS needs to see that you understand bounce handling, complaint rates, and responsible sending before granting unrestricted access.

How the Sandbox Restricts You: The Data Flow

The diagram below illustrates exactly where the Sandbox enforcement happens in the SES sending pipeline.

graph TD App["Your Application"] --> API["SES SendEmail API"] API --> ModeCheck{"Account Mode Check"} ModeCheck -- "Sandbox" --> RecipientCheck{"Is recipient a
verified identity?"} ModeCheck -- "Production" --> QuotaCheck{"Sending Quota
Available?"} RecipientCheck -- "YES" --> QuotaCheck RecipientCheck -- "NO" --> Rejected["❌ MessageRejected Error
Send Blocked"] QuotaCheck -- "YES" --> Delivery["✅ Email Delivered
to Recipient"] QuotaCheck -- "NO" --> Throttled["⏸️ Throttled /
Daily Limit Exceeded"] style Rejected fill:#ffcccc,stroke:#cc0000 style Delivery fill:#ccffcc,stroke:#006600 style Throttled fill:#fff3cc,stroke:#cc8800
  1. Your Application calls the SES API (SendEmail or SendRawEmail) with a recipient address.
  2. SES Account Mode Check: SES first checks whether your account is in Sandbox or Production mode.
  3. Sandbox Path: If in Sandbox, SES checks whether the recipient address is a verified identity in your account. If it is NOT verified, the send is rejected immediately with a MessageRejected error.
  4. Production Path: If in Production, SES skips the recipient verification check and proceeds directly to sending.
  5. Sending Quota Check: Both paths are subject to your account's sending rate and daily sending quota limits.
  6. Delivery: Email is handed off to the recipient's mail server.

Checking Your Current Account Status via CLI

Before submitting a production access request, confirm your current sandbox status and sending limits using the SES v2 API.

Required IAM Permission

Grant only the minimum permission needed to read account-level SES data:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "SESReadQuota",
      "Effect": "Allow",
      "Action": "ses:GetAccount",
      "Resource": "*"
    }
  ]
}

CLI Command

aws sesv2 get-account --region us-east-1

Key fields to inspect in the response:

🔽 [Click to expand] Example get-account response (annotated) 
{
  "DedicatedIpAutoWarmupEnabled": false,
  "EnforcementStatus": "HEALTHY",
  "ProductionAccessEnabled": false,   // <-- false = you are in Sandbox
  "SendQuota": {
    "Max24HourSend": 200.0,            // Daily sending quota (Sandbox default)
    "MaxSendRate": 1.0,               // Emails per second
    "SentLast24Hours": 3.0            // Emails sent in the last 24 hours
  },
  "SendingEnabled": true,
  "SuppressionAttributes": {
    "SuppressedReasons": [
      "BOUNCE",
      "COMPLAINT"
    ]
  }
}

The critical field is ProductionAccessEnabled. When this is false, your account is in Sandbox mode. Note that exact quota values shown above are illustrative — always check the official AWS SES quotas documentation for current defaults.

How to Request Production Access (Exit the Sandbox)

Exiting the Sandbox is done through the SES console's dedicated production access request workflow. This is not a generic Service Quotas increase — it is a specific AWS review process for your SES account's sending practices.

graph LR Start(["Start"]) --> Console["Open SES Console
Account Dashboard"] Console --> Form["Click: Request
Production Access"] Form --> Fill["Fill Form:
Use case, bounce handling,
opt-in process, website URL"] Fill --> Submit["Submit Request"] Submit --> Review["AWS Reviews Request
(up to 24 hours)"] Review -- "Approved" --> Production["✅ Production Access Enabled
ProductionAccessEnabled: true"] Review -- "More Info Needed" --> SupportCase["AWS Opens
Support Case"] SupportCase --> Clarify["You Provide
Clarification"] Clarify --> Review style Production fill:#ccffcc,stroke:#006600 style SupportCase fill:#fff3cc,stroke:#cc8800
  1. Navigate to SES Console: Open the AWS SES console in the region where your sending identity is configured.
  2. Find the Request: In the left navigation, go to Account dashboard. You will see a banner or section indicating your account is in the Sandbox, with a "Request production access" button.
  3. Complete the Request Form: Fill in the required details (see below). AWS uses this information to assess your sending legitimacy.
  4. AWS Review: AWS reviews your request. This is not instant — it typically takes up to 24 hours, though timing is not guaranteed.
  5. Outcome: You receive an email notification. If approved, ProductionAccessEnabled becomes true. If more information is needed, AWS may open a support case for clarification.

What to Include in Your Production Access Request

A weak or vague request is the most common reason for delays or rejections. Be specific and complete:

FieldWhat AWS Wants to KnowStrong Example
Mail Type Category of email you will send Transactional (order confirmations, password resets)
Website URL Your application or company URL https://www.yourapp.com
Use Case Description Detailed explanation of your sending scenario "We send transactional emails (order confirmations, shipping notifications) to customers who have explicitly registered on our e-commerce platform. All recipients have opted in."
Bounce & Complaint Handling How you process bounces and complaints "We have configured SNS topics for SES bounce and complaint notifications. Our application processes these events to suppress invalid addresses and unsubscribe complainants automatically."
Opt-in Process How recipients consented to receive email "Users provide their email during account registration and confirm via a double opt-in verification email."

Pre-Flight Checklist Before Submitting

Submitting a production access request without these in place is a common mistake that leads to rejection or, worse, account suspension after approval.

  • ✅ Verified sending domain with DKIM configured (not just a single email address)
  • ✅ SPF and DMARC records published in your domain's DNS
  • ✅ Bounce notification handling: SNS topic subscribed to SES bounce notifications, with application logic to suppress bounced addresses
  • ✅ Complaint notification handling: SNS topic subscribed to SES complaint notifications, with application logic to unsubscribe complainants
  • ✅ Suppression list awareness: Understand the account-level suppression list and how it interacts with your sending
  • ✅ Unsubscribe mechanism: All marketing or bulk emails include a functional unsubscribe link

What Happens After Production Access is Granted

Getting out of the Sandbox is not the end of quota management — it is the beginning. Your account starts with a default production sending quota. If your application requires higher throughput, you can request a sending limit increase separately through the SES console (Account dashboard > Request increase) after you are in production mode.

Monitor your sending reputation continuously using the SES Reputation Dashboard in the console. AWS can place your account under review or pause sending if your bounce rate or complaint rate exceeds acceptable thresholds, regardless of whether you are in production mode.

Glossary

TermDefinition
SES SandboxThe default restricted mode for new SES accounts where emails can only be sent to verified identities.
Verified IdentityAn email address or domain that has been confirmed as owned/controlled by you in SES, via a verification process.
Bounce RateThe percentage of sent emails that could not be delivered. A high bounce rate signals poor list hygiene and can trigger account review.
Complaint RateThe percentage of recipients who mark your email as spam. Monitored by AWS; high rates can result in sending suspension.
Sending QuotaThe maximum number of emails your SES account can send per 24-hour period and per second (sending rate). Separate from Sandbox status.

Next Steps

Comments

Post a Comment

Popular posts from this blog

EC2 No Internet Access in Custom VPC: Attaching an Internet Gateway and Fixing Route Tables

Launching an EC2 instance in a custom VPC only to find it cannot reach the internet is one of the most common networking pitfalls in AWS — and it almost always comes down to two missing pieces: an Internet Gateway (IGW) and a correctly configured Route Table. This post walks you through the exact architecture, the root cause, and the precise steps to fix it. TL;DR Step Action Why It Matters 1 Create and attach an Internet Gateway to your VPC Without an IGW, there is no path between your VPC and the public internet 2 Add a 0.0.0.0/0 route pointing to the IGW in your subnet's Route Table The route table is the traffic director — without this entry, outbound packets have nowhere to go 3 Assign a Public IP or Elastic IP to the EC2 instance The IGW performs NAT only for instances with a public IP address 4 Verify Security Group allows outbound traffic Security Groups are stateful firewalls; outbound rules...
Read more

IAM User vs. IAM Role: Why Your EC2 Instance Should Never Use a User

Choosing between an IAM User and an IAM Role is one of the most consequential security decisions in AWS — get it wrong and you either expose long-lived credentials or block your application entirely. This post cuts through the confusion and gives you a definitive answer for the EC2-to-S3 access pattern. TL;DR — Quick Comparison Dimension IAM User IAM Role Identity type A person or a static service account An assumable identity for AWS services, users, or external principals Credential type Long-lived Access Key ID + Secret Access Key Short-lived, auto-rotating STS tokens (max 12 h by default) Credential rotation Manual — you must rotate keys yourself Automatic — AWS rotates them transparently Stored on EC2? Yes — in ~/.aws/credentials or env vars (risky) No — delivered via the In...
Read more

Lambda Infinite Loop with S3: How to Prevent Recursive Triggers

Writing a processed file back to the same S3 bucket that triggered your Lambda function creates a recursive loop — each output file fires a new invocation, which writes another file, ad infinitum. Left unchecked, this silently drains your AWS budget and exhausts Lambda concurrency limits within minutes. TL;DR Strategy Mechanism Best For Complexity Separate Output Prefix/Bucket S3 event filter on prefix Simple pipelines Low Object Metadata Check Lambda reads S3 object metadata before processing Single-bucket requirement Medium Separate Output Bucket Trigger only on source bucket Clean architectural separation Low DynamoDB Idempotency Guard Track processed ETag/key in DynamoDB Exactly-once guarantees Medium-High Understanding the Recursive Loop Before fixing the problem, you need to understand exactly why it happens. The S3 → Lambda trigger is an event-driven subscription: S3 publishes an ObjectCreat...
Read more