# Amazon SES "Maximum sending rate exceeded": Causes and Fix

Source: https://wraps.dev/ses/errors/maximum-sending-rate-exceeded

Throughput and quotaThrottlingSMTP 454

Why SES throttles a send with “Maximum sending rate exceeded”, how the per-second rate differs from the daily quota, and how to retry without making it worse.

## The error

```
Throttling: Maximum sending rate exceeded
```

AWS exception `Throttling`. The Wraps CLI reports it as `AWS_THROTTLED`.

## Why this happens

SES enforces a maximum send rate per second on every account. Going over it does not queue the message, it rejects it. The same handling covers ThrottlingException and TooManyRequestsException from other AWS APIs in the same call path, so the throttled operation is not always SendEmail.

-   The account went over its per-second SES send rate.
-   A burst of parallel senders shared one account quota without coordinating.
-   A non-send SES or AWS API in the same code path was rate limited.

## How to fix it

1.  ### 1. Retry with exponential backoff and jitter
    
    This error is retryable and often transient. Back off, add jitter so a fleet of workers does not retry in lockstep, and cap the number of attempts so a genuinely saturated account fails loudly instead of spinning.
    
2.  ### 2. Check the rate you are actually allowed
    
    Read the account's current send rate rather than assuming it. New production accounts start low and AWS raises the limit as sending reputation builds.
    
    ```
    aws sesv2 get-account --query 'SendQuota'
    ```
    
3.  ### 3. Bound your own concurrency below the SES rate
    
    One sender respecting the limit and ten senders each respecting it are different things. Put the rate limit in front of the pool, not inside each worker.
    
4.  ### 4. Request a quota increase if it is persistent
    
    If backoff is not enough at steady state, the limit is the problem rather than the burst. Raise it through Service Quotas in the AWS console.
    

## How to stop it recurring

### Treat the rate as a shared budget

The quota belongs to the AWS account, not to a process. Anything else sending through the same account, including other applications, is spending from the same budget.

### Alarm on throttles, not just on failures

A throttled send that a retry rescued still tells you the account is near its ceiling. That signal arrives well before the first send you actually lose.

## Common questions

### Is “Maximum sending rate exceeded” the same as the daily quota?

No. The rate is per second and the quota is per 24 hours. Both surface as throttling, but backoff fixes the rate limit and only waiting or a quota increase fixes the daily one.

### Should I retry a throttled SES send?

Yes, with exponential backoff and jitter. Retrying immediately in a tight loop makes the throttle worse and burns the rest of your budget on rejections.

### Why do I get throttled below my stated send rate?

The rate is per account, not per process. Parallel workers, background jobs and any other application on the same AWS account draw from the same per-second budget.

### What SMTP code does SES use for throttling?

The SES SMTP interface returns 454 for a throttling failure, with the same text the API returns under the Throttling code.

## What Wraps does about this

The Wraps CLI maps Throttling, ThrottlingException and TooManyRequestsException to AWS\_THROTTLED and says plainly that AWS is rate limiting the API rather than blaming credentials. Wraps cannot raise your SES send rate. That number is AWS's, adjusted on your sending reputation or by a quota request.