Amazon SES rate-limit errors mean the account already hit its maximum sending rate or its 24-hour sending quota. The API and SDK return ThrottlingException. SMTP returns 454 Throttling failure. In both cases SES drops the message and does not redeliver it. A retry is your job, and the wait only helps if you hit the rate, not the daily quota.
The two error strings, and why the surface changes
The same account limits produce different text depending on how you sent. Reviewed against the live AWS page Errors related to the sending quotas for your Amazon SES account on 7 October 2026, the names are still ThrottlingException for the API and 454 for SMTP.
| Surface | Error | Message | What it means |
|---|---|---|---|
| API or SDK | ThrottlingException | Maximum sending rate exceeded | More messages this second than the account rate in that Region |
| API or SDK | ThrottlingException | Daily message quota exceeded | The rolling 24-hour recipient quota is full |
| SMTP | 454 | Throttling failure: Maximum sending rate exceeded | Same rate cap, SMTP wording |
| SMTP | 454 | Throttling failure: Daily message quota exceeded | Same 24-hour quota, SMTP wording |
How those quotas are counted, and why they are per Region, lives in Amazon SES sending limits and quotas. This page owns the error text and the retry decision.
SES does not retry the dropped message
AWS is explicit: if you send after the daily quota or the maximum sending rate, SES drops the message and does not attempt to redeliver it. The SMTP client or the SDK call fails. A queue that marks the job complete on a 454 has lost the message. A queue that retries blindly can hammer the same limit.
AWS tells API callers to wait up to 10 minutes, then retry. That is a backoff hint, not a promise the quota has reset. A rate error can clear in seconds once the per-second window moves. A daily-quota error stays until the rolling 24-hour window frees capacity. Retrying a quota error every 10 minutes will fail again.
How we separated rate, quota, and sandbox
On 7 October 2026 we re-read the AWS sending-quota errors page and Arawa Mail's mailbox and API error docs. The AWS page still lists exactly two API messages and two SMTP 454 messages, and it still says SES drops the message. Arawa Mail's API errors page documents 401, 422, 403, and 429. It does not mention ThrottlingException or 454. The mailbox guide says mailbox sending is rate limited per account and that a user may need to wait, but it does not publish a number. So there is no published Arawa per-second cap to code against, and SES 454 handling does not apply to the Arawa HTTP API.
Sandbox rejection of unverified recipients is a different gate. It is covered in how to move Amazon SES out of the sandbox. A domain that never finished Easy DKIM is also a different failure. See verify a domain in Amazon SES.
Branch first: rate, quota, or something else
- Read the message, not just the exception name. ThrottlingException and 454 each cover two limits. The substring tells you which one.
- Maximum sending rate exceeded. The worker is faster than the account rate in that Region. Slow the sender. A burst of 100 SMTP handoffs can return 454 Maximum sending rate exceeded while the daily quota is fine. Do not open a quota-increase request for a rate problem. Pace to the published rate, and use the AWS backoff of up to 10 minutes only as the outer retry, not as the steady send interval.
- Daily message quota exceeded. The rolling 24-hour quota is full. Waiting 10 minutes will not help. Stop the campaign, check sent volume in that Region, and wait for the window to move. A quota increase is a separate request with its own evidence. Do not fold that procedure into this error handler.
- Confirm the Region. Limits are per Region. A send in eu-west-1 does not consume the us-east-1 quota, and a raise in one Region does not raise the other.
- Rule out sandbox and credentials. Unverified-recipient sandbox errors, and SMTP 535 or 530 authentication failures, are not these strings. Handle them in their own branches.
Other providers use HTTP 429 or their own SMTP codes. Do not paste those into an SES handler, and do not paste SES 454 handling into a non-SES client.
What Arawa Mail returns instead
Application sending on Arawa Mail is the HTTP API, not SES SMTP. Too many send attempts can return 429. Invalid keys return 401. A domain that is not registered, not allowed by the key, or not enabled for outbound returns 403. Mailbox users who send too quickly are told to wait. None of those responses is ThrottlingException or 454 Throttling failure.
If the application is still on SES, fix the SES branch above. If the goal is a mailbox plus an HTTP send API on the same custom domain, that is a different stack from an SES quota increase.
FAQ
Is this the per-second rate or the 24-hour quota?
Read the message. Maximum sending rate exceeded is the per-second cap. Daily message quota exceeded is the rolling 24-hour quota. Both can appear as ThrottlingException or as SMTP 454.
Why does the API say ThrottlingException while SMTP says 454?
They are two interfaces to the same account limits. The API and SDK raise ThrottlingException. The SMTP interface returns 454 Throttling failure with the same two underlying messages.
Will SES retry the dropped message?
No. AWS says SES drops the message and does not attempt to redeliver it. Your queue has to decide whether to retry.
How long should the client wait?
For a rate error, AWS says wait up to 10 minutes and retry. That is an upper bound, not the required gap. For a daily quota error, 10 minutes is not enough. Wait until the rolling 24-hour window frees capacity.
Is this the sandbox?
Not if the text is Maximum sending rate exceeded or Daily message quota exceeded. Sandbox accounts fail unverified recipients for a different reason. Check the sandbox article before you treat every SES rejection as a quota error.
Does Arawa Mail return this error?
No. Arawa Mail documents 429 for too many send attempts, and a per-account mailbox rate limit with no published number. It does not return ThrottlingException or 454.