If you send through Amazon SES, two numbers determine how fast you can move: the send rate (messages per second) and the sending quota (messages per 24 hours). New accounts begin in the SES sandbox at 1 message per second and 200 messages per day. Production accounts typically start near 14 messages per second with a 50,000-per-day quota and grow from there as AWS observes healthy sending. Get either limit wrong and SES returns a Throttling error - the same error code, two different causes, two different fixes.
Send rate vs sending quota: the two limits that throttle you
Amazon SES enforces two independent caps. The send rate is the maximum messages per second SES will accept from your account; short bursts above it are tolerated, sustained bursts are rejected. The sending quota is a rolling 24-hour ceiling on recipients. Per the AWS sending limits docs, both are tracked per AWS Region.
The mental model that matters: send rate protects SES infrastructure from spikes, the daily quota protects deliverability by forcing gradual warm-up. They throttle for different reasons and you need to handle them differently in code. Hitting the send rate means slow your loop down. Hitting the daily quota means you are out of budget until the rolling window advances.
| Limit | What it measures | Window | Error when exceeded |
|---|---|---|---|
| Send rate | Messages SES accepts from your account each second | Per second (short bursts tolerated) | Throttling - Maximum sending rate exceeded |
| Sending quota | Recipients sent in the last 24 hours | Rolling 24-hour window | Throttling - Daily message quota exceeded |
| Max message size | MIME-encoded size of a single message | Per message (40 MB) | MessageRejected |
One more rule that catches developers off guard: quotas count recipients, not API calls. A SendEmail call with 10 To/Cc/Bcc recipients consumes 10 units of your daily quota. AWS recommends calling SendEmail once per recipient so a single bounce does not fail the batch.
Sandbox limits: what you get by default
Every new SES account starts in the sandbox with a 1 message per second send rate and 200 messages per 24 hours. You can only send to verified identities - both From and To addresses must be confirmed in the SES console. Per the AWS docs, sandbox limits exist to prevent abuse and force you to prove deliverability hygiene before AWS opens the firehose.
In practical terms the sandbox is a dev environment. 200 messages a day covers internal testing, transactional flows for a handful of beta users, and SDK integration work. It is not enough for production. You cannot serve real signups, real password resets, or any campaign send from a sandbox account. The recipient-verification requirement also blocks any flow where users self-register, because their addresses are not pre-verified.
Sandbox quotas do not auto-grow. The only way out is the production access request described in our SES sandbox-to-production guide.
Production access and its starting limits
Once AWS approves production access, your account leaves the sandbox and receives a real starting allocation. AWS grants 14 messages per second and 50,000 messages per 24 hours as the typical defaults in most regions (AWS, 2026). The exact starting numbers depend on the region and the justification you submit; vague use-case descriptions can land a lower rate, while detailed volume plans can land a higher one.
What changes immediately on approval:
- You can send to any address, verified or not (subject to the SES suppression list).
- The send rate and daily quota jump to your production starting values.
- AWS begins monitoring bounce and complaint rates against the thresholds - 5% bounce and 0.1% complaint trigger automatic review.
You still need to warm up gradually. Hitting your account with 50,000 messages on day one to an aged list will produce bounces, complaints, and a quick reputation downgrade. Our SES IP warm-up guide covers the ramp schedule.
How AWS grows quotas
AWS automatically increases your sending quota and rate as you build a track record of healthy sending. There is no public formula, but the inputs are well-documented: sustained sending close to your current cap, bounce rate well under 5%, complaint rate well under 0.1%, and no spam-trap hits. Accounts that send 10% of their quota for weeks rarely get auto-increased; accounts that hit 70-90% with clean metrics typically see increases inside a few days.
Manual quota increases through the AWS Support Center are also available. Those are usually decided in under 24 hours and require: list source, opt-in mechanism, unsubscribe handling, expected daily volume, and current bounce/complaint metrics. AWS will refuse increases for accounts with bounce > 5% or complaint > 0.1% until you fix the underlying issue.
What happens when you hit a rate limit
SES returns a Throttling error with one of two messages: Maximum sending rate exceeded (per-second cap) or Daily message quota exceeded (24-hour cap). Per the AWS quota errors docs, both are HTTP 400-class responses on the API and return SMTP code 454 over the SMTP interface.
The two errors need different handling:
Maximum sending rate exceededis transient. Implement exponential backoff with jitter - 1s, 2s, 4s, 8s with randomization - and retry. The AWS SDKs do this automatically forThrottlingerrors up to a configurable max attempts.Daily message quota exceededis not transient within the next hour. Retrying tighter loops just burns CPU. Queue the message, set a delivery time later in the rolling window, or shed load (drop non-critical sends, prioritize transactional).
A naive retry loop with no backoff turns a 200ms hiccup into a self-inflicted DDoS. Make sure your retry strategy caps total attempts (5-10) and uses jitter so concurrent workers do not all retry at the same millisecond.
Requesting a quota increase
The quota increase request lives under AWS Support Center. AWS wants concrete answers, not marketing language. Have these ready:
- Region the request applies to.
- Desired send rate and daily quota with specific numbers (not "as much as possible").
- Mail type - transactional, marketing, system notifications.
- Website URL and a sample of the actual emails you send.
- Address acquisition - how subscribers opted in, with timestamp/IP capture if you have it.
- Bounce handling - how you process bounces from SNS/event destinations and remove bad addresses.
- Unsubscribe mechanism - one-click List-Unsubscribe is now expected.
- Current metrics - bounce rate, complaint rate, and recent sending volume.
Requests with vague answers get a templated reply asking for the same details. Requests with specific volume justification, clean metrics, and named bounce-handling infrastructure usually get approved or counter-offered (AWS may grant half what you asked for and re-evaluate in 30 days).
Common pitfalls
Four patterns burn through SES quotas faster than they should:
- Synchronous batch sends. A
forloop over 10,000 contacts callingSendEmailwith no concurrency control will hit your per-second cap in the first second and throttle for the rest. Use a queue and a worker pool sized to your send rate minus a safety margin. - Retry storms after a regional outage. When SES recovers from a brief hiccup, every queued message retries at once. Add jitter (50-200ms randomization) to spread the herd.
- Unwarmed dedicated IPs against a hot quota. A new dedicated IP starts with zero reputation. If your account quota is 1M/day, do not send 1M from a fresh dedicated IP on day one - mailbox providers throttle by IP independent of SES. See our SES warm-up guide.
- Counting messages instead of recipients. A campaign to 50,000 subscribers using
Bccof 10 per call is 500 API calls but 500,000 quota units. Always count by recipient.
How Mailblast handles SES rate limiting for you
Mailblast sits on top of your Amazon SES account as a management layer - your AWS credentials, your quotas, your sender reputation. The rate-limiting work happens in the queue: Mailblast paces sends to stay under your account's current per-second cap with headroom for safety, applies exponential backoff with jitter on Throttling errors, and respects your rolling 24-hour quota by spreading large campaigns over the available window.
You see your live SES limits in the Mailblast dashboard pulled from the GetSendQuota API, so you can plan a campaign without guessing whether you have room. Bounces and complaints from SNS flow back into list hygiene automatically, which keeps your bounce rate below the 5% threshold AWS uses for auto-throttle review.
Because you keep your own SES account, every quota increase AWS grants you - automatic or via Support ticket - applies immediately. Mailblast does not aggregate sends across customers, so your reputation moves on your sending, not on someone else's marketing list.
FAQ
What is the default Amazon SES rate limit?
In the SES sandbox, the default rate limit is 1 message per second and 200 messages per 24 hours. Once you move to production, AWS typically grants a starting send rate of 14 messages per second and a daily quota of 50,000 messages (AWS, 2026). Both grow with sustained healthy sending and clean bounce and complaint metrics.
Are SES quotas per account or per region?
Amazon SES sending quotas are tracked separately for each AWS Region (AWS, 2026). If you send from us-east-1 and eu-west-1, each region has its own daily quota and send rate. Verified identities and reputation are also region-scoped, so warm-up work in one region does not transfer to another.
What error does SES return when I hit the rate limit?
When you exceed the per-second send rate, SES returns a Throttling error with the message Maximum sending rate exceeded. When you exceed the 24-hour quota, you get a Throttling error with Daily message quota exceeded (AWS, 2026). Retry both with exponential backoff and jitter, not tight loops.
How fast does AWS increase my SES quota?
AWS reviews your account automatically and grants larger quotas as you build a record of low bounce, low complaint sending. Manual increases through Support are typically reviewed within 24 hours and decided on volume justification, list hygiene, bounce rate under 5 percent, and complaint rate under 0.1 percent (AWS, 2026).
Does the SES quota count messages or recipients?
Quotas are counted by recipient, not by API call (AWS, 2026). A single SendEmail request with ten To/Cc/Bcc recipients consumes ten units of your daily quota. AWS recommends one SendEmail call per recipient so a single bad address does not fail the whole batch.
Disclosure: Mailblast is a hosted management layer for your own Amazon SES account. You bring the AWS credentials; Mailblast handles list management, sending, automation, and rate-aware queueing on top of your existing SES quotas.