Why SES limits catch senders off guard
Amazon SES is one of the most cost-effective ways to send email at scale, but almost every developer who uses it for the first time hits a wall. They build an integration, verify a domain, write the code, and then discover they cannot send to real recipients, or that their account is capped at a rate that makes their campaign impossible. The limits are not arbitrary bureaucracy. AWS shares sending infrastructure across thousands of customers, and a single poorly behaved account can damage the IP reputation that every other sender depends on. Understanding exactly what those limits are, why they exist, and how to move through them in a controlled way is one of the most practical things you can do before your first production send.
The SES sandbox: what it is and what it blocks
Every new Amazon SES account starts in the sandbox, and sandbox status is applied per AWS Region independently. While in the sandbox, you can use all SES features, but three hard restrictions apply. First, you can only send mail to email addresses and domains that you have explicitly verified in your account, or to the SES mailbox simulator. Second, your daily sending quota is capped at 200 messages per 24-hour period. Third, your sending rate is limited to one message per second. These figures are fixed and cannot be adjusted while you remain in the sandbox.
The practical effect is that the sandbox is useful for verifying your integration, confirming that bounce and complaint notifications reach your SNS topics, and checking that your authentication records are correct, but it is completely unsuitable for any real-world sending. You cannot email a new customer, a newsletter subscriber, or a support ticket requester unless their address is pre-verified in your account. AWS designed this deliberately: the barrier forces senders to demonstrate intent and basic competence before they gain access to a shared IP pool that serves millions of customers.
Getting out of the sandbox
Moving from sandbox to production requires submitting a request through the AWS console via the Account dashboard. AWS expects SPF, DKIM, and DMARC DNS records to be in place for your sending domain before production access is granted. This is not just a checkbox. Reviewers treat authentication as a signal of sending maturity, and requests that arrive without proper DNS configuration are far more likely to be declined.
The request form asks you to classify your email as marketing or transactional, provide your website URL, and describe your use case in a free-text field. This description is where most requests succeed or fail. Be specific. State the types of email you plan to send, such as order confirmations, password resets, or weekly newsletters. Explain how you collect consent, including whether you use confirmed opt-in. Describe how you handle bounces and complaints, for example by noting that you have SNS topics configured and that hard bounces are immediately suppressed. Include a realistic sending volume for now and for six months from now. A vague request such as "I need to send marketing email" is far more likely to be questioned or refused than one that demonstrates you understand the obligations that come with production access.
Approvals typically take around 24 hours when the request is well documented. If your request is denied, AWS will not always explain why, which makes a thorough first submission even more important. Accounts that are brand new with no AWS activity beyond SES domain verification face additional scrutiny, so where possible submit the request once you have some broader AWS usage on the account.
Your sending quota: daily limit and sending rate
Once you are in production, SES enforces two separate quotas that apply independently. The sending quota is the maximum number of emails you can send in a rolling 24-hour period. It is not a midnight reset. Every time you attempt to send, SES calculates how many messages you have sent in the preceding 24 hours and compares that against your quota. If sending the new message would push you over the limit, the API call is rejected. The sending rate is the maximum number of emails SES will accept from your account per second. You can exceed this quota briefly in short bursts, but you cannot sustain a rate above your limit.
When you first receive production access, the starting quotas assigned to your account vary depending on your use case and the information provided in your request. AWS does not publish a guaranteed starter figure, so check your actual limits in the SES console or via the GetSendQuota API call as soon as production access is granted. Quotas are set per AWS Region, so if you use SES in multiple Regions your account has a separate quota in each one. The maximum message size is 10 MB after MIME encoding, which is worth bearing in mind if you send emails with attachments: encoding overhead can inflate a 5 MB attachment to approximately 6.85 MB, roughly 37 per cent larger than the original file.
How AWS adjusts your quota automatically
AWS can increase your quotas automatically without you needing to raise a support case, but only if your sending behaviour meets a specific set of conditions. You must be sending real production content to real external recipients, because sending only to internal addresses or fabricated addresses makes it impossible for AWS to assess your sending quality. Your daily volume must regularly approach your current quota without exceeding it. And your bounce and complaint rates must remain low. High bounce or complaint rates actively work against automatic increases and can result in your quota being reduced. Sending high-quality content to recipients who want it, and suppressing disengaged or invalid addresses promptly, is the behaviour that earns automatic quota growth over time.
Requesting a manual quota increase
If you need more headroom quickly, or if your growth trajectory outpaces the automatic increase mechanism, you can request a manual quota increase through AWS Service Quotas. Navigate to Service Quotas in the AWS console, search for SES, and submit separate requests for your daily sending quota and your sending rate. Requests are typically reviewed within 24 to 48 hours, depending on your account's sending history and reputation.
A well-prepared request should include your current average daily volume, your anticipated volume over the next 30 and 90 days, your current bounce and complaint rates, a brief description of your list acquisition methods, and confirmation that you have suppression handling in place. If you are migrating from another email service provider and have historical sending data showing clean metrics, include that too. AWS is more willing to approve large jumps in quota when you can demonstrate responsible sending history. Be aware that very large increases may require multiple sequential requests, as AWS applies internal thresholds to each step.
Throttling errors: handling 454 and ThrottlingException
When your application sends faster than your per-second rate allows, SES does not silently discard the message. Via the SMTP interface, your client receives a 454 error with the message "Throttling failure: Maximum sending rate exceeded" or "Daily message quota exceeded". Via the API or an AWS SDK, you receive a ThrottlingException with an equivalent message. These are retryable errors, not permanent failures, and your code must handle them gracefully.
The correct pattern is to implement exponential backoff with jitter on any ThrottlingException or 454 response. Rather than retrying immediately, your sender should wait an increasing interval before each subsequent attempt, adding a small random offset to prevent a fleet of workers from all retrying in synchrony. Beyond error handling, the better long-term fix is to throttle client-side before SES throttles you. Use a token bucket or leaky bucket algorithm to cap your outgoing rate to just below your quota. This keeps your send queue stable, avoids wasted API calls, and prevents the kind of burst behaviour that erodes your standing with SES. You can query your current quota at any time using the GetSendQuota API call to build dynamic rate limiting into your sending pipeline.
Designing a volume ramp schedule
Even after production access is granted and quotas are in place, sending a large volume of email from a new domain or IP address without a deliberate ramp-up is a serious mistake. Mailbox providers track the sending history of IP addresses and domains. A new sender that suddenly emits tens of thousands of emails looks indistinguishable from a spam operation, and inbox providers will route that traffic to junk or block it entirely.
If you use SES shared IP pools, AWS manages some of the IP-level warm-up automatically by routing your traffic through pools appropriate for your volume. If you use standard dedicated IPs, you are fully responsible for the warm-up schedule. Managed dedicated IPs handle warm-up automatically as volume grows. Regardless of your IP type, domain reputation still needs to be built, and that requires a gradual, consistent ramp on your part.
A practical week-by-week framework for a sender targeting 100,000 emails per day looks roughly as follows. In week one, send only to your most engaged subscribers, those who have opened or clicked within the last 30 days, and keep daily volume to around 1,000 to 3,000 emails. In week two, widen slightly to include recent converters and active users, and increase daily volume to around 5,000 to 10,000 emails. In weeks three and four, expand to the broader confirmed opt-in list and increase by 20 to 30 per cent each week. By weeks five to eight, you can begin including your full list, continuing to increase at 20 to 30 per cent per week and watching metrics closely at each step. Avoid sudden, significant changes in sending volume, content, or frequency at any stage. If bounce or complaint rates spike, reduce volume immediately and hold at the previous level until metrics stabilise before continuing.
Start every ramp with the freshest, most engaged segment of your list. Positive engagement signals, including opens, clicks, replies, and additions to the address book, tell mailbox providers that your mail is wanted and accelerate the process of building domain reputation.
Metrics to watch during a ramp
Three metrics determine whether your ramp is safe or heading towards an account review. The first is bounce rate. AWS publishes two thresholds: a recommended ceiling of 5 per cent and a danger zone above 10 per cent, at which point account probation or suspension becomes likely. Hard bounces above 5 per cent indicate a serious list quality problem and those addresses must be suppressed immediately. The second is complaint rate. The recommended threshold is below 0.1 per cent, with anything above 0.5 per cent risking enforcement action. Complaint rates rise when you send to people who did not genuinely opt in, when you send too frequently, or when your unsubscribe mechanism is hard to find or broken. The third metric is engagement. SES and mailbox providers both use engagement as a signal of sender quality. Chronically low open rates on a large send indicate that a portion of your list is disengaged, which increases the relative weight of any complaints you receive.
AWS surfaces bounce and complaint rates through the Reputation Metrics section of the SES console and publishes these figures to Amazon CloudWatch automatically. You can configure CloudWatch alarms to notify you when either metric crosses a threshold you define, giving you an automated early warning system. Acting on a rising bounce rate within hours rather than days can be the difference between a successful ramp and an account review.
Real-time visibility during a ramp
CloudWatch alarms are useful but they require setup, and the native SES console gives you aggregate figures rather than a live view tied to specific campaigns or sending patterns. SES Monitor addresses this by pulling your bounce, complaint, delivery, and engagement data into a single dashboard with real-time alerts. During a volume ramp, when metrics can move quickly, that immediacy matters. A bounce spike on an active campaign does not need to reach your CloudWatch alarm threshold before you know about it. SES Monitor surfaces the change as it happens, giving you time to pause the send, investigate the list segment, and suppress bad addresses before the overall account-level rate climbs into territory that triggers AWS enforcement. The same visibility applies to complaint rates: a small cluster of complaints from a single import source can be spotted and isolated early, rather than accumulating quietly until AWS contacts you.
Mistakes that stall quota increases or trigger enforcement
Sending to purchased or scraped lists is the fastest route to account suspension. Bounce rates from unvetted lists routinely exceed 10 per cent, and the complaint rate from recipients who never opted in can push well above 0.5 per cent within a single campaign. Both outcomes trigger enforcement, and AWS blocks on domain as well as on account, making recovery difficult.
Sending test messages to fabricated addresses during development inflates your bounce rate and counts against your reputation metrics. Always use the SES mailbox simulator for integration testing. Failing to process bounce and complaint notifications from SNS means that invalid and complaining addresses remain on your list and continue to receive mail, compounding the problem with every subsequent send. Requesting a quota increase before your sending history is established, for example before you have been consistently sending near your current quota for at least a couple of weeks, is likely to result in a smaller increase than you need, or a delay while AWS waits for more data. And continuing to send to addresses that have not interacted with your mail in over a year keeps dead weight on your list that adds no positive signal and increases the statistical impact of any complaints you do receive.
Summary checklist
Sandbox exit: Verify SPF, DKIM, and DMARC DNS records before submitting. Write a detailed use case description covering email types, consent method, bounce handling, and expected volume. Expect a decision within 24 hours for a well-prepared request.
Quota increase request: Submit via Service Quotas with current metrics, projected growth, and list acquisition details. Request both daily quota and sending rate separately. Time the request for when you are consistently approaching but not exceeding your current limits.
Volume ramp: Start with your most engaged subscribers at low volume. Increase by no more than 20 to 30 per cent per week. Monitor bounce rate, complaint rate, and engagement at every step. Hold or reduce volume the moment metrics deteriorate. Use real-time monitoring, whether through CloudWatch alarms or a dedicated tool such as SES Monitor, so that a spike in any metric prompts action within minutes, not days.