Amazon SES Sandbox to Production: A Practical Checklist

Amazon SES sandbox access is a restricted test state, not a smaller version of production. Before requesting production access, verify the right Region and identity, prove that your application can handle delivery events, and explain a legitimate sending program. AWS decides whether to approve the request; no checklist can guarantee approval.

Start with the Region and sending identity

Amazon SES is Region-aware. A domain verified in one Region may need to be verified again in another, and an account's sending status and quotas are not something to infer from a different Region. Start by finding the Region in the SES console, SDK client, or SMTP endpoint used by the application. Record it in the deployment runbook.

Then verify the identity that will appear in the message. A domain identity is usually the durable choice for an application because it lets you authenticate the domain and manage authorized From addresses together. An individual email identity can be useful for a narrow test, but it is not a substitute for domain authentication. Review email infrastructure explained and the DNS records for email before treating verification as complete.

In the sandbox, SES limits who you can send to. AWS documents a restriction to verified recipients, apart from SES mailbox simulator addresses, while the account remains in the sandbox. That means a successful test to a verified address demonstrates that the request path works; it does not demonstrate that an arbitrary recipient can receive mail before production access.

Prepare the request with operational detail

The production-access request should answer the questions a reviewer needs to understand risk. Describe what the messages are, how recipients enter the list, how often you expect to send, and what happens when a recipient opts out. Be specific about authentication and the system that receives bounces and complaints. Do not describe a cold list as opted in, and do not imply that approval makes every campaign acceptable.

AWS may set or retain account-specific sending limits. The request is therefore not a promise of a particular daily volume. Treat the limits shown for the account as the source of truth and monitor them after approval. If a program grows, request a quota increase through the current AWS process rather than designing around a number copied from an old guide.

Before submitting, test the whole failure path. Send a controlled message, receive the event, record the message identifier, and verify that your application can classify a hard bounce, a temporary failure, and a complaint. Reconcile the event with your contact record and suppress the recipient before another campaign can use the address. The companion guide on SES bounce and complaint notifications covers the event boundary in more detail.

What production access does—and does not—mean

Production access changes the sandbox recipient restriction. It does not remove authentication requirements, reputation risk, account review, or recipient expectations. A production account can still be throttled, blocked, or investigated if its traffic produces poor signals or violates AWS policies. It also does not turn a purchased, scraped, or irrelevant list into a defensible audience.

A useful launch gate is narrower than “SES says production.” Ask five questions: are the correct identities verified in the sending Region; are DNS records published; can the sender handle throttling and retries; are bounce and complaint events connected to suppression; and can a human explain why each recipient is receiving the message? If any answer is no, keep testing rather than using approval as the finish line.

Where RepMail fits

RepMail’s infrastructure content is organized around the same separation of concerns: domain setup, sending transport, and delivery-event handling are different jobs. If you use RepMail or another SES-backed application, confirm which AWS Region and identity it uses, then verify the resulting events in the application’s own activity and suppression workflow. The safe assumption is that the tool can only act on the signals it receives; your AWS configuration and recipient policy still determine the boundaries.

Sources

• AWS: Request production access (move out of the SES sandbox)
• AWS: Creating and verifying identities
• AWS: Managing SES sending limits
• AWS: Using the Amazon SES mailbox simulator