Guide
Amazon SES sending limits, explained
Amazon SES enforces exactly two limits: a sending quota — the maximum number of messages you can send in any 24-hour period — and a sending rate — the maximum number of messages you can send per second. Both apply per AWS account, per region. This guide covers what they are, what happens when you hit them, and how to raise them.
The Two Limits
Sending quota and sending rate
SES tracks the two limits independently, and you can run into either one on its own. The sending quota is measured over a rolling 24-hour window — not a calendar day that resets at midnight. If you sent 30,000 messages between 9am and 11am yesterday, that capacity frees up between 9am and 11am today. The sending rate is an instantaneous ceiling: send faster than it allows, even for a second, and SES rejects the excess calls.
Both limits are scoped per AWS account, per region. Production access in us-east-1 does nothing for eu-west-1 — each region has its own sandbox status, its own quota, and its own rate.
| Limit | What it is | Sandbox | Typical production start |
|---|---|---|---|
| Sending quota | Maximum messages per rolling 24-hour period | 200 / 24h | ~50,000 / 24h |
| Sending rate | Maximum messages per second | 1 / sec | ~14 / sec |
Typical values as of July 2026. Production starting values are set by AWS case by case and vary by account and region — always check the Account dashboard in the SES console for your actual numbers.
The sandbox. Every new SES account starts in the sandbox: 200 messages per 24 hours, 1 message per second, and — the part that actually blocks you — recipients limited to email addresses and domains you've verified. The sandbox exists so spammers can't spin up throwaway AWS accounts; getting out requires a short production-access request. Our Amazon SES setup guide walks through the sandbox-exit request step by step, including what to write so it's approved on the first pass.
Note that limits cap volume, not cost — SES bills per message sent, regardless of your quota. See our Amazon SES pricing breakdown for what sending actually costs.
Hitting the Limits
What happens when you hit them
SES does not queue mail for you. When you exceed a limit, the API call fails — and if your application doesn't handle that failure, the email is simply gone.
Exceeding the sending rate
You get a Throttling error — "Maximum sending rate exceeded" (SMTP: a 454 throttling response). This is transient: back off briefly and retry, and the send goes through. SDKs retry a few times automatically, but sustained bursts above your rate will exhaust those retries.
Exceeding the sending quota
You get "Daily message quota exceeded". Retrying immediately is pointless — capacity only frees up as the rolling 24-hour window moves. Sends fail until it does.
The right architecture is the same for both: put a queue between your application and SES. Enqueue every send, drain the queue at a pace below your sending rate, and pause draining when the quota is exhausted. For rate errors specifically, retry with exponential backoff and jitter rather than hammering the API.
One trap worth knowing: batching with SendBulkEmail doesn't buy you headroom. A bulk call to 50 recipients counts as 50 messages against both the quota and the rate — batching reduces API round-trips, not consumption.
Increasing Limits
How limits increase
Automatic growth. SES continuously reviews accounts that send consistently and cleanly. Use a meaningful share of your quota, keep bounce and complaint rates low, and SES raises your limits on its own — many teams never file a request at all. The keyword is consistent: steady daily volume earns increases; sporadic spikes don't.
Requesting an increase. When you need more headroom sooner — a launch, a migration, seasonal volume — request it through Service Quotas in the AWS console (or a support case for the sending rate and anything that needs explanation). Approval hinges on convincing AWS you'll use the volume responsibly.
What to include in a quota increase request
- Current usage. Your present daily volume and how close you run to today's quota. Requests grounded in real usage get approved; speculative ones don't.
- Growth projection. The volume you need, when you need it, and why — a user-base milestone, a product launch, a migration from another provider.
- Bounce and complaint handling. How you process bounce and complaint notifications, and how quickly failing addresses are suppressed from future sends.
- Opt-in practices. Where your recipient list comes from, how people consent, and how they unsubscribe. Never say "purchased list" — that's an instant denial.
The classic mistake is winning a big increase and using it all at once. Jumping from 5,000 to 50,000 messages overnight looks like a compromised account to every mailbox provider on the receiving end, and the resulting bounce and spam-folder placement can undo the increase entirely. New capacity needs warm-up — which is the next section.
Warm-Up
Warming up: your account, and your IPs
Mailbox providers judge senders by history. A sender that has never delivered volume and suddenly does is indistinguishable from a spammer, so new capacity has to be earned gradually — over days and weeks, not hours.
Account warm-up
When your quota increases, ramp into it: start near your previous daily volume, then grow sends by roughly 30–50% per day while watching bounce and complaint rates. If either metric climbs, hold the current volume until it settles. Start the ramp with your most engaged recipients — their opens and low complaint rates build the reputation that carries the rest of the list.
Dedicated IP warm-up
Dedicated IPs start with zero reputation and need their own warm-up on top of your account's. Standard dedicated IPs must be warmed manually — a gradual per-IP ramp you plan and execute yourself. Managed dedicated IPs handle warm-up automatically, adjusting how traffic splits between the new IPs and shared ones as reputation builds. On shared IPs (the default), there's no IP warm-up to do — only the account-level ramp above.
Reputation
The quota is worthless if your reputation tanks
Sending limits are only half of what SES watches. The other half is reputation — your bounce and complaint rates — and it can take your sending away far faster than a quota ever will. A 100,000-message quota means nothing if your account is under review.
| Metric | Healthy | Risk of review or pause |
|---|---|---|
| Bounce rate | Below 2% | Above 5% |
| Complaint rate | Below 0.05% | Above 0.1% |
Cross the risk thresholds and SES can place your account under review or pause your sending outright — in every region, regardless of remaining quota. And note how tight the complaint threshold is: 0.1% means one complaint per thousand messages. A single broadcast to a stale list can cross it.
The practical takeaway: monitor quota usage and reputation together. Watch the reputation metrics in the SES account dashboard, suppress hard bounces immediately, honor unsubscribes instantly, and cut recipients who never engage. Alerting before the thresholds — not after — is exactly what deliverability alerts are for.
SendOps
Managing SES limits without babysitting them
Everything above is doable by hand — a queue, a rate limiter, dashboard checks, alarm math. SendOps does it for you, against your own SES account:
Quota tracking & alerts
SendOps tracks your quota usage in real time and alerts you before you hit the limit — not after sends start failing.
Automatic send pacing
Broadcasts and workflow sends are paced within your sending rate automatically — no throttling errors, no retry logic to write.
Reputation monitoring
Bounce and complaint rates are monitored continuously against the SES review thresholds, so a bad list can't quietly walk you into an account pause.
It all runs through your own SES account — your quota, your reputation, your infrastructure. There's a free plan, and setup takes a few minutes.
FAQ
Frequently asked questions
What are Amazon SES's default sending limits?
In the sandbox, every account starts at 200 messages per 24 hours and 1 message per second, and can only send to verified addresses. After moving to production, starting limits vary by account and region — commonly around 50,000 messages per day and 14 messages per second as of July 2026. Check the SES account dashboard for your actual values.
How do I increase my SES sending quota?
Two ways: send consistently high-quality mail and SES raises your limits automatically, or request an increase through AWS Service Quotas or a support case. In the request, include your current volume, your growth projection, how you handle bounces and complaints, and how recipients opted in. Ramp volume gradually — jumping 10x overnight is the classic mistake.
What is the SES sandbox limit?
200 messages per 24 hours, a maximum send rate of 1 message per second, and recipients restricted to verified email addresses and domains. These limits apply to every new SES account in every region until you request production access.
What error do I get when I exceed SES limits?
Exceeding the per-second sending rate returns a Throttling error with the message 'Maximum sending rate exceeded.' Exceeding the 24-hour quota returns 'Daily message quota exceeded.' Both are API errors — SES does not queue the mail for you, so your application must retry with backoff or queue the message and send it later.
Does SES rate-limit per second or per day?
Both. The sending rate caps how many messages you can send per second, and the sending quota caps how many you can send in any rolling 24-hour period. The two limits are independent — you can hit either one on its own — so your sending pipeline has to respect both at the same time.
Get Started
Never hit an SES limit by surprise again
Connect your SES account and SendOps handles the pacing, the quota alerts, and the reputation monitoring — free to start.