Stuck in the SES sandboxThe concrete path AWS actually reviews, not vague reassurance.

The sandbox is the default state of every new Amazon SES account, not a penalty. It exists so a fresh account cannot immediately blast unverified inboxes and damage a shared reputation before AWS knows anything about the sender. Inside it, three limits apply at once: a ceiling of 200 emails in a rolling 24-hour period, a rate of one message per second, and a hard requirement that both the sending identity and every recipient address are individually verified in the SES console.

That last restriction is the one that actually blocks a launch. You can verify your own inbox and your co-founder's, but you cannot mail a signup list, a customer base, or anyone who has not clicked a verification link you sent them. Production access removes the recipient restriction and raises your sending limits to whatever AWS assigns based on your account history and request. It does not remove the 24-hour or per-second limits entirely; those become account-specific quotas you can request increases on later, through the mailbox simulator and the same support-case channel (Test your sending quota, SES Developer Guide, fetched 1 September 2026).

Do this first, not as a follow-up. AWS reviewers weigh domain authentication heavily because it is the one signal that separates a considered sender from a drive-by account: publish SPF, add the DKIM CNAME records SES generates for your identity, and set a DMARC record even at the permissive p=none policy so you can see alignment reports before you tighten it.

1. Add and verify your sending domain in the SES console, not a free mailbox address. A domain identity is what a reviewer expects from a real sender.
2. Publish the DKIM CNAME records SES generates for that identity in your DNS provider, or apply them in one click if your DNS runs on Route 53 in the same account.
3. Add an SPF include for Amazon SES to your domain's TXT record alongside any existing senders.
4. Publish a DMARC record, p=none to start, so you get visibility into pass and fail rates without rejecting mail outright.

None of this requires production access. All four steps work inside the sandbox, and having them live before you file the request means the request describes a domain AWS can already verify is authenticated, rather than a promise to get to it later.

Verify a handful of your own addresses and run the actual sends you plan to make in production: the welcome email, the newsletter template, the transactional receipt. Confirm unsubscribe links resolve, merge fields render, and nothing lands in spam on the inboxes you control. The mailbox simulator's dedicated test addresses also let you generate bounce, complaint, and out-of-office events on demand, so you can confirm your bounce and complaint handling actually fires before real recipients ever trigger it (Test your sending quota using the mailbox simulator, SES Developer Guide, fetched 1 September 2026).

This step does double duty. It catches template and configuration mistakes while the blast radius is just your own inbox, and it means the production access request can describe a setup you have actually run, not one you are describing from a spec.

Open the request from the SES console's account dashboard. AWS's form asks open questions, and the generic answers are exactly what gets a request declined without a stated reason. Be specific on four points.

As of the July 2026 check, AWS reviews these requests manually rather than by an automated score, often inside a business day or two, sometimes longer depending on volume and how complete the answers are. There is no published guarantee on timing, and a thin or evasive answer on any of the four points is the most common reason a request stalls.

The recipient-verification restriction lifts, and you can send to any address SES accepts, at the sending limits AWS assigns your account. Those limits are not unlimited from day one; they start conservative and rise as your account builds a sending history, which is a separate, ongoing process usually called warm-up rather than a second approval gate.

SendBunny installs into your own AWS account in one click and shows your sandbox status on screen instead of leaving it buried in the console, alongside the same production-access form AWS requires you to submit yourself. It gives you a real platform to run those pre-application tests in: templates, lists, a domain authentication screen with one-click Route 53 DNS, and automatic suppression on hard bounces and complaints, so the request you write describes a setup that is actually running. It is $199 once, and it does not submit the request for you; AWS requires that to come from your own console.