The Amazon SES sandbox is an account status, not the same thing as your sending quota. While in the sandbox, you can only send to verified addresses or the mailbox simulator, at a maximum of 200 messages per 24 hours and 1 message per second. Production access removes the recipient restriction and assigns a (usually higher) sending quota and rate, but those volume and rate limits still exist and are enforced per AWS Region.
Why the distinction matters
Developers often treat “out of the sandbox” as “unlimited sending.” That creates three common failure modes:
- A test to an unverified Gmail address fails even though the account has sent fewer than 200 messages. This is the sandbox recipient rule, not the quota.
- A production account hits its rolling 24-hour sending quota even though both the From identity and the recipient domain are verified. This is the sending quota.
- A short burst exceeds the per-second sending rate while the daily quota still has headroom. This is the sending rate.
Each failure needs a different fix. Confusing them wastes time on the wrong request form.
Sandbox status vs sending quota
| Aspect | Sandbox status | Sending quota (and rate) |
|---|---|---|
| What it is | Account status applied to new accounts, separately in each Region | Rolling 24-hour recipient ceiling + max messages accepted per second |
| Recipient restriction | Only verified addresses/domains or the mailbox simulator | None after production access (From/Source/Sender/Return-Path identities must still be verified) |
| Default limits | 200 messages / 24 h and 1 message / second | Assigned by AWS when production access is granted; can be increased later via Support case |
| How it ends | Request production access (console or sesv2 put-account-details) | Persists; further increases are separate Support cases |
| Scope | Per AWS Region | Per AWS Region |
How we analyzed this
We cross-checked the current AWS documentation for requesting production access and managing sending quotas against the behavior described in ArawaMail’s own SES-related guides. Key verified points:
- New accounts start in the sandbox. Restrictions include verified-recipient-only sending, 200 messages per 24-hour period, and 1 message per second.
- After production access, mail can go to any recipient, but identities used as From, Source, Sender, or Return-Path must still be verified.
- Sending quota is a rolling 24-hour count of recipients. Sending rate is the maximum SES will accept per second (short bursts can exceed it; sustained ones cannot). Both are separate per Region.
- A production-access request can also request a quota increase. Later increases use a Support case.
AWS does not publish a universal starting production quota; it assigns one per account and Region. ArawaMail plan limits (3,000 / 50,000 / 100,000 transactional emails per month) are unrelated to SES quotas.
Three failure examples
- Unverified recipient in the sandbox. You send a password-reset test to your personal Gmail. SES rejects it because the recipient is not verified, even if you are well under 200 messages. Fix: verify the address or request production access. See How to Move Amazon SES Out of the Sandbox.
- Rolling 24-hour quota reached in production. Both identities are verified, yet sends start failing. You have sent the maximum number of recipients in the preceding 24 hours. Fix: wait for the rolling window or request a quota increase. See Amazon SES Sending Limits and Quotas Explained.
- Sending rate exceeded. A burst of messages exceeds the per-second rate while the daily quota still has room. Fix: throttle the client or request a higher rate. The exact error strings (ThrottlingException and SMTP 454) are covered in Amazon SES Rate Limit Errors.
When to use which guide
- You need the request steps to leave the sandbox → How to Move Amazon SES Out of the Sandbox
- You need quota math, monitoring, or how to request increases → Amazon SES Sending Limits and Quotas Explained
- You need domain verification (Easy DKIM) → How to Verify a Domain in Amazon SES
- You are comparing ArawaMail (inboxes + transactional API on your domain) with SES → ArawaMail vs Amazon SES
ArawaMail is not SES. Enabling sending on ArawaMail (after receiving is active) adds DKIM CNAMEs and a custom MAIL FROM MX + SPF via Cloudflare. There is no SES-style sandbox; plan limits are monthly transactional caps documented on the pricing page.
FAQ
Is the sandbox the same as the daily sending quota?
No. The sandbox is an account status that also imposes the 200 / 1-per-second limits and a verified-recipient restriction. The sending quota is the rolling 24-hour ceiling that continues after you leave the sandbox.
What can a sandbox account send?
Only to verified email addresses or domains, or to the Amazon SES mailbox simulator, at most 200 messages per 24 hours and 1 message per second.
What stays limited after production access?
The From/Source/Sender/Return-Path identities must still be verified. The sending quota and sending rate remain in force (and are per Region).
Why can production mail still return a quota or rate error?
Because leaving the sandbox does not remove the volume and rate limits. Those are separate controls.
When should I use ArawaMail instead?
When you want both business inboxes and a transactional sending API on the same custom domain, without managing a separate SES account, sandbox requests, or per-Region quotas. Start with the free plan (3,000 transactional emails/month).