// how to fix
Amazon SES "Throttling: Maximum sending rate exceeded" (454): fix it
Amazon SES returns "Maximum sending rate exceeded" or "Daily message quota exceeded". Check your quotas, slow down sending and request an increase.
What it means
Every Amazon SES account has two sending quotas per AWS Region: a sending rate (emails per second) and a sending quota (emails per rolling 24 hours). When you go over one of them, SES refuses the message. Through SMTP the replies are:
454 Throttling failure: Maximum sending rate exceeded 454 Throttling failure: Daily message quota exceeded
Through the API or an SDK you get a Throttling error with the message "Maximum sending rate exceeded" or "Daily message quota exceeded". A 4xx code is temporary: the message was not sent, but it can be sent later. A refused message is not billed.
Why it happens
- Still in the sandbox. Sandbox accounts are limited by default to 1 message per second and 200 messages per 24 hours. See how to leave the sandbox.
- Bursts. Your app sends a whole list in a loop with many parallel workers. SES tolerates short bursts, not sustained excess.
- Quotas count recipients, not messages. One email with 10 recipients counts as 10.
- Wrong Region. Quotas are per Region. A higher quota granted in
us-east-1does not apply toeu-west-1. - Old SMTP credentials. "Maximum SigV2 SMTP sending rate exceeded" means your SMTP credentials were created before January 10, 2019. Replace them with new ones.
- If the throttling text matches neither quota, AWS suggests checking the AWS Health Dashboard for a service issue.
How to check
See your current quotas and usage with the CLI (or on the console's Account dashboard):
aws sesv2 get-account --region eu-west-1
"SendQuota": {
"Max24HourSend": 50000.0,
"MaxSendRate": 14.0,
"SentLast24Hours": 48211.0
}Compare MaxSendRate with how many messages your code really sends per second, and SentLast24Hours with Max24HourSend. Your logs show the times of the 454 errors: spikes at the start of a campaign point to a rate problem; errors late in the day point to the daily quota.
How to fix it
Slow down and retry
Send at or below your MaxSendRate, and retry 454 errors with growing waits (AWS suggests for example 5 s, 10 s, 30 s, then a longer pause). AWS SDKs retry API calls automatically, but your own queue should still respect the rate. With nodemailer, a pooled transport can limit the rate:
const transporter = nodemailer.createTransport({
host: 'email-smtp.eu-west-1.amazonaws.com', port: 587,
auth: { user: process.env.SES_SMTP_USER, pass: process.env.SES_SMTP_PASS },
pool: true,
maxConnections: 2,
rateDelta: 1000, // per second
rateLimit: 10, // at most 10 messages per rateDelta
});With Postfix relaying to SES, reduce parallel deliveries to the relay, for example smtp_destination_concurrency_limit = 2 and smtp_destination_rate_delay = 1s in main.cf (the delay applies per destination, here the SES relay). Postfix keeps 4xx messages in its queue and retries them automatically.
Daily quota reached
Wait: the quota is a rolling 24-hour window, so capacity comes back as older sends drop out. Spread big campaigns over several days, and send one recipient per API call rather than long recipient lists.
Request higher quotas
Open the Service Quotas console, select the right Region, choose AWS services, then Amazon Simple Email Service (SES), and request an increase of Sending quota or Sending rate. AWS says it handles these requests within about 24 hours, and it can also raise quotas automatically when you send good-quality mail close to your limit with low bounce and complaint rates.
Even with high quotas, do not jump from a few hundred to tens of thousands of emails a day: mailbox providers react to sudden spikes with their own throttling (see SMTP 421 too many connections). Ramp up gradually as explained in warm up a new domain or IP.
Check that it is fixed
Run your sending job again and watch your logs: there should be no more 454 errors, and SentLast24Hours should stay under Max24HourSend. Send one message to your unique address on the Delivmail home page to confirm the content and authentication are still clean after your changes, then resend the messages that were refused.
Check that it is fixed
DNS changes can take from a few minutes to a few hours. Then send a new test email or scan your domain again.
Related guides
- Amazon SES "Email address is not verified": sandbox and identities fixedAmazon SES rejects your email because a sender or recipient identity is not verified. Verify identities, leave the sandbox and send safely.
- Amazon SES DKIM verification pending or failed: how to fix itYour Amazon SES domain stays "Pending" or shows DKIM "Failed". Check the three CNAME records, common DNS mistakes and how to restart verification.
- Amazon SES custom MAIL FROM domain: SPF alignment for DMARCAmazon SES uses an amazonses.com bounce domain, so SPF does not align with DMARC. Set up a custom MAIL FROM subdomain with the right MX and SPF.
- Amazon SES account under review or paused: bounce and complaint rateYour Amazon SES account is under review or sending is paused because of bounces or complaints. Learn the thresholds, find the cause and reply to AWS.
- Amazon SES SMTP "535 Authentication Credentials Invalid": fix itAmazon SES rejects your SMTP login with 535 Authentication Credentials Invalid. Use real SMTP credentials, the right Region and endpoint, and test them.