# Sending quota: Definition and How It Works

Source: https://wraps.dev/glossary/sending-quota

InfrastructureSES send quotasending limits

SES enforces two independent sending caps — a rolling 24-hour maximum message count and a per-second maximum rate — and hitting either returns a different exception with a different fix.

## Two separate limits, easy to conflate

The daily quota is a total-messages-per-rolling-24-hour-window cap; the sending rate is a maximum-per-second cap. An account can be well under its daily quota and still get throttled on rate if it tries to send a large batch too quickly, and conversely can send at a perfectly acceptable rate all day and still eventually hit the daily ceiling. They're diagnosed and fixed differently, which is exactly why AWS returns different exceptions for each.

## Different exceptions, different fixes

Exceeding the daily quota returns \`LimitExceededException\` or \`ServiceQuotaExceededException\`, fixed by waiting for the rolling window to free up capacity or by requesting a higher quota. Exceeding the per-second rate returns \`Throttling\`, fixed by retrying with exponential backoff and jitter, and by bounding your own concurrency below the account's actual rate rather than letting every worker send independently. Both have dedicated \`/ses/errors\` pages precisely because the correct response to each is different enough that conflating them wastes time.

## Quotas rise automatically, and can be requested to rise faster

AWS raises both the daily quota and the per-second rate over time as an account's sending reputation builds — consistently low bounce and complaint rates are the main input to that. To ask for more directly: request increased quotas in the same submission that asks to leave the SES sandbox, or once the account is already out of the sandbox, open a new case in the AWS Support Center — that's the actual mechanism, not a generic "Service Quotas" self-service form.

## The quota is shared across everything sending from that account

Both limits apply to the AWS account as a whole, not to a single application or process — parallel workers, background jobs, and any other application sharing the account all draw from the same daily and per-second budget. A rate limiter or a queue that respects the limit inside one process does nothing to prevent a second, uncoordinated process from pushing the shared total over the line.

## The daily quota counts recipients, not messages

A single SendEmail call to 10 recipients spends 10 units of the daily quota, not one — a detail that catches people right when a batch send unexpectedly exhausts the day's budget faster than the message count suggested it would. AWS's own guidance is one SendEmail call per recipient rather than a multi-recipient call, partly for this reason and partly because a multi-recipient call fails as a whole if any part of it is rejected.

## Why it matters

Confusing the daily quota with the per-second rate leads directly to the wrong fix — retrying a daily-quota exhaustion with backoff does nothing but waste attempts until the rolling window frees capacity, and requesting a quota increase for what's actually a rate-throttling problem doesn't address the burst behavior causing it.

## How to check it

```
aws sesv2 get-account --query 'SendQuota'
```

## Common questions

### What's the difference between the SES daily quota and the sending rate?

The daily quota is a total message count allowed in a rolling 24-hour window. The sending rate is a maximum number of messages per second. You can be well within one and still hit the other, since they're independent limits with different failure exceptions.

### Does the SES daily quota reset at midnight?

No, it's a rolling 24-hour window, not a fixed calendar-day reset. Capacity frees up gradually as older sends age out of the window rather than resetting all at once.

### Why am I getting throttled even though my app respects the rate limit?

The limit is shared across the whole AWS account, not scoped to a single process. Any other application, background job, or worker sending from the same account draws from the identical per-second budget, and an uncoordinated second sender can push the shared total over the line.