skip to content

SES

4 roadmaps10 questions

SES is the managed way to send transactional and bulk email from AWS: domain verification, DKIM signing, sending limits, and bounce and complaint handling. Interviewers ask about deliverability rather than the API, because reputation management is what actually breaks in production.

part ofAWSoverview, primer and where to startread it →
on this pageshow

explore

questions

10

A brand-new AWS account cannot email arbitrary recipients through Amazon SES. What is the SES sandbox, exactly what does it restrict, and how do you get production access?

level: juniorimportance: must knowfreq 76%

answer

  1. default state of a new account
  2. per Region, not per account
  3. recipients must be verified too
  4. 200 per day, 1 per second
  5. request production access for that Region

basics

~20 s

The SES sandbox is the default restricted state of every new SES account, per Region. In it you may only send to identities you have verified (plus the SES mailbox simulator), at a low daily cap and send rate. You leave it by requesting production access for that Region.

solid answer

~50 s

Every AWS account starts in the Amazon SES sandbox, and the sandbox is **per Region**, not per account. While sandboxed you can only send *to* addresses or domains you have verified yourself, plus the SES mailbox simulator addresses such as `[email protected]`; your daily cap and per-second send rate are also tiny (200 messages per 24 hours and 1 message per second as of 2025). Sending to an unverified recipient fails at the API call, not silently at delivery. To get out you request production access for that Region from the SES console (SESv2 exposes it as `PutAccountDetails`), describing your use case, how recipients opted in, and how you will process bounces and complaints. The classic production incident is a team that escaped the sandbox in `us-east-1` months ago, deploys to a second Region, and discovers that Region is still sandboxed.

code

bash · 9 lines
bash
# Where do we actually stand: sandbox status and current quota, per Region
aws sesv2 get-account --region eu-west-1 \
  --query '{Sandbox:ProductionAccessEnabled,Quota:SendQuota}'

# Safe smoke test that works even inside the sandbox
aws sesv2 send-email --region eu-west-1 \
  --from-email-address [email protected] \
  --destination [email protected] \
  --content '{"Simple":{"Subject":{"Data":"ping"},"Body":{"Text":{"Data":"hello"}}}}'

go deeper

for a junior

Be able to say plainly that a new SES account is sandboxed: you can only send to addresses you verified, at a very small daily cap, and you must request production access to email real customers.

for a middle

Explain that the sandbox, identity verification and quotas are all per Region, that an unverified recipient fails the API call rather than bouncing later, and that the mailbox simulator lets you test without real recipients.

for a senior

Show that you treat production access and quota headroom as a pre-launch checklist item across every Region you send from, and that you can answer AWS's consent and bounce-handling questions with a real automated suppression path.

for a principal

Own the policy: which Regions send mail at all, whether marketing and transactional mail share an account, and how sending reputation is governed so one team's campaign cannot put another team's password-reset mail at risk.

## What the sandbox is Amazon SES is a shared sending platform: mail leaving it carries the reputation of AWS IP space, so AWS does not let an unvetted account start blasting strangers. Every new account therefore begins in the **SES sandbox**, a deliberately crippled mode that lets you build and test end to end without being able to reach anyone who has not agreed to hear from you. The sandbox is scoped to **one account in one Region**. SES identities, quotas, suppression state and sandbox status all live per Region, which is the single most commonly missed fact about it. ## The three restrictions 1. **Recipients must be verified.** In the sandbox, the *destination* must itself be a verified identity — a verified email address, or an address inside a verified domain. Outside the sandbox only the *sender* identity has to be verified. Sending to anything else returns an error from the `SendEmail` call itself (`MessageRejected` with a message about the address not being verified); it is a synchronous API failure, not a delivery failure you find later in a bounce feed. 2. **A small 24-hour cap.** As of 2025 the sandbox allows 200 messages per rolling 24-hour period. This is `Max24HourSend` in the quota returned by the SESv2 `GetAccount` call. 3. **A low maximum send rate.** As of 2025, 1 message per second (`MaxSendRate`). Exceed it and calls are throttled rather than queued. The **mailbox simulator** is the escape hatch for testing: addresses at `simulator.amazonses.com` — `success@`, `bounce@`, `complaint@`, `ooto@`, `suppressionlist@` — are always accepted, even in the sandbox, and never leave AWS. They still count against your quota, and they let you exercise your bounce and complaint handling before you have any real recipients. ## Getting production access You request production access from the SES console for the Region you want (the SESv2 API models the same thing as `PutAccountDetails`). AWS asks a small number of pointed questions, and the quality of your answers decides the outcome: - **What kind of mail is this?** Transactional (password resets, receipts) is approved far more readily than marketing. - **How did recipients consent?** "We bought a list" is a rejection. - **How do you handle bounces and complaints?** You are expected to have an automated path that stops sending to a hard-bounced or complaining address, not a human reading a mailbox. - **How do people unsubscribe?** Approval is usually quick (commonly within a day), and it comes with a starting quota — production access does not mean unlimited sending. SES raises `Max24HourSend` and `MaxSendRate` over time as you send clean volume, and you can request a specific increase through Service Quotas or a support case when you know a launch is coming. ## Why interviewers ask this Because it is the classic launch-day outage, and it is entirely predictable. The pattern is always the same: everything works in staging because the five test addresses are verified; the feature ships; every real signup email is rejected at the API. Or: the service is deployed to a new Region for latency or DR and mail stops, because identities and sandbox status did not travel with the deployment. The correct habit is to treat "production access + verified sending identity + a quota that covers projected volume, in every Region we send from" as a launch checklist item that is done weeks early, not on the day. ## Practical notes - Identity verification is also per Region. A domain verified in `eu-west-1` is not verified in `us-east-1`; you publish the DNS records once but complete verification in each Region you send from. - Reading your live position is one call: the SESv2 `GetAccount` operation returns `SendQuota` with `Max24HourSend`, `MaxSendRate` and `SentLast24Hours`, plus whether the account is in the sandbox. Alarm on `SentLast24Hours` approaching the cap rather than discovering it during a campaign. - Leaving the sandbox does not relax anything about *sender* verification: you must still send from a verified identity, always.

  • You escaped the sandbox six months ago, but a new deployment in another Region cannot email customers. What happened?
    Sandbox status, identity verification and sending quotas are all per Region. The new Region is still sandboxed and probably has no verified sending identity, so sends to real recipients are rejected at the API. Fix it by verifying the identity there and requesting production access for that Region — and add both to the deployment checklist for every Region you send from.
  • How would you test bounce and complaint handling before you have any real recipients?
    Use the SES mailbox simulator: send to `[email protected]`, `[email protected]` or `[email protected]`. They are accepted even in the sandbox, never deliver to a real person, and generate genuine bounce and complaint events so you can prove your handling path works end to end.
  • Does production access mean you can send as much as you want?
    No. Production access only removes the verified-recipient restriction and raises you off the sandbox floor; you still have a `Max24HourSend` cap and a `MaxSendRate`. SES raises them over time as you send clean traffic, and you can request a specific increase ahead of a known launch rather than discovering the ceiling mid-campaign.

saying these in an interview costs you the question

  • Thinks the sandbox is account-wide, not per Region
  • Believes only the sender needs verifying in the sandbox
  • Assumes production access means unlimited sending
  • Plans to request production access on launch day
  • Cannot name the mailbox simulator for safe testing

context

resolving links…

open as a page

How do you get Amazon SES bounce and complaint notifications into a system you can act on, and why is email feedback forwarding not enough at scale?

level: middleimportance: must knowfreq 62%

basics

~20 s

Attach an SES configuration set with an event destination — SNS, Kinesis Data Firehose, CloudWatch or EventBridge — and subscribe to the Bounce and Complaint event types. Email feedback forwarding just drops human-readable mail into a mailbox nobody parses or monitors.

open as a page

What is the Amazon SES account-level suppression list, and what happens when you send to an address that is on it?

level: juniorimportance: should knowfreq 48%

basics

~20 s

It is a per-account list of addresses SES refuses to deliver to, populated automatically after a hard bounce or a complaint. A send to a suppressed address is still accepted and returns a message ID, but SES never delivers it and reports a bounce event instead.

open as a page

In Amazon SES, what is the difference between Easy DKIM and BYODKIM, and when would you choose BYODKIM?

level: middleimportance: should knowfreq 50%

basics

~20 s

Easy DKIM has SES generate and rotate the signing key pair — you publish three CNAME records and forget it. BYODKIM means you supply your own private key and publish the public-key TXT record yourself, keeping key custody and rotation.

open as a page

In Amazon SES, what is the difference between verifying a domain identity and verifying an email address identity, and which should a production service use?

level: middleimportance: should knowfreq 61%

basics

~20 s

An email identity verifies one exact address by emailing a confirmation link to it. A domain identity is verified by publishing DNS records, and then any address at that domain may be the From. Production services verify the domain, because addresses like no-reply@ have no mailbox to click a link.

open as a page

An application can reach Amazon SES either through the SESv2 API or through the SES SMTP endpoint. What decides which one you use, and how do SES SMTP credentials relate to IAM credentials?

level: middleimportance: should knowfreq 48%

basics

~20 s

Use the SESv2 API when you control the code: the SDK signs with the IAM role's temporary credentials, so no secret is stored. Use the SMTP endpoint for off-the-shelf software that only speaks SMTP. SES SMTP credentials are derived from an IAM secret key and are Region-specific — they are not the IAM secret itself.

open as a page

If you never configure a custom MAIL FROM domain in Amazon SES, which domain does SPF authenticate for your outbound mail, and why does that matter for DMARC alignment?

level: seniorimportance: should knowfreq 45%

basics

~20 s

SES uses a subdomain of amazonses.com as the envelope MAIL FROM, so SPF authenticates amazonses.com rather than your From domain. That leaves DKIM as the only mechanism that can align with your domain, until you configure a custom MAIL FROM subdomain.

open as a page

Your service must push a 400,000-message nightly campaign through Amazon SES, but the account's maximum send rate is 50 messages per second. How do you design the sender?

level: seniorimportance: should knowfreq 44%

basics

~20 s

Treat the two SES limits as separate constraints: a rolling 24-hour cap on volume and a per-second send rate. Get the daily quota raised ahead of time, buffer the work in a queue, and have workers self-throttle below the send rate with backoff and jitter on throttling errors.

open as a page

In Amazon SES, when would you use SendBulkEmail with a stored email template instead of calling SendEmail in a loop, and what does the bulk response tell you?

level: middleimportance: nice to knowfreq 33%

basics

~20 s

Use SendBulkEmail when one templated message goes to many recipients with per-recipient substitutions: one call covers a batch of destinations instead of one call each. Its response reports a status per destination, so a successful call can still contain individually failed entries.

open as a page

When would you move an Amazon SES workload from the shared IP pool onto dedicated IPs, and what does that commit you to?

level: principalimportance: nice to knowfreq 32%

basics

~20 s

Move only at consistent high volume, when isolating your reputation from other senders is worth owning it. Dedicated IPs cost a fixed monthly fee per address, must be warmed up gradually, and decay if your sending volume is not steady.

open as a page