Skip to content
YourMail

Deliverability guide

Getting out of the AWS SES sandbox

Why use this

Every new SES account starts in a sandbox that will only send to addresses you have already verified. That is fine while you are testing and fatal the moment a real user signs up. Leaving it is a request to AWS, reviewed by a person, and the difference between a same-day approval and a week of back-and-forth is almost entirely what you write in the box.

For example

Your signup flow works perfectly in staging, then in production every welcome email to a real customer fails with 'Email address is not verified'.

What the sandbox actually restricts

Three limits, and only the first is the one people mean:

You can send only to verified addresses or domains. Not just from — to. Every recipient must be an identity you own and have confirmed, which makes sending to a customer impossible by construction.

You get 200 messages per 24 hours and one message per second. Both rise substantially on approval — the usual production starting point is 50,000 a day at 14 a second, which is a floor rather than a special grant.

Check where you are

Before writing a request, confirm the sandbox is actually your problem. A send can fail for identity reasons that have nothing to do with it.

aws sesv2 get-account --region eu-west-2 \
  --query '{Production:ProductionAccessEnabled,Sending:SendingEnabled,Enforcement:EnforcementStatus,Quota:SendQuota}'

ProductionAccessEnabled: false is the sandbox. EnforcementStatus is a different axis entirely — it reports whether AWS has paused you for bounce or complaint rates, and SendingEnabled: false means sending is off regardless of sandbox status. Fixing the wrong one wastes a day.

What to put in the request

Request production access from the SES console's Account dashboard (or aws sesv2 put-account-details). This is not the same request as raising your send quota — that is a separate Service Quotas increase, filed afterwards and only when you approach the cap. The form asks how you will use it, and the reviewer is answering one question: if we let this account send to strangers, will it generate complaints?

Answer that question directly rather than describing your product. Four things carry almost all the weight:

Where the addresses come from. "Users who have signed up to our own application and confirmed their address" is a good answer. "A list we acquired" is a refusal. If you are sending only transactional mail — receipts, password resets, verification codes — say exactly that, because it is the lowest-risk category there is and reviewers know it.

How someone stops receiving it. Name the mechanism. If it is one-click unsubscribe in the headers, say so; if the mail is purely transactional and has no unsubscribe by design, say that instead and explain why, because a reviewer who sees no answer assumes there is none.

How you handle bounces and complaints. The answer AWS wants is that they are processed automatically and the address is suppressed, not that you will review them. If you are sending through this API, that is already true — hard bounces and complaints are written to a suppression list and enforced on the next send without you doing anything.

Realistic volume. Ask for what you need. An early-stage app asking for a million a day invites scrutiny it does not need, and the default production grant is generous enough that most applications never approach it.

Why requests get rejected

Almost always one of three things. The description is generic enough to describe a spammer as easily as a business. The bounce-handling answer is a plan rather than a mechanism. Or the account has already accumulated bounces during testing — sending to made-up addresses to check your integration is the single most common self-inflicted wound here, which is why SES publishes simulator addresses that produce a bounce without counting against you.

A rejection is not final and is usually specific. Answer the specific thing and resubmit rather than rewriting from scratch.

If you would rather not do this at all

This is the step this product exists to remove. Sending through YourMail means the SES account, its production access and its reputation are ours to hold — you verify your own domain, which proves you control it, and send. There is no sandbox request and no quota ticket.

Whether that is worth it depends on the rest of the trade, which is set out honestly on the SES comparison page, including the cases where using SES directly is the better call.