The Moment You Discover Your SES Account Has Been Paused
You open your inbox, or worse, you notice your application has stopped delivering email entirely, and there it is: a notification from AWS informing you that your Amazon SES account's ability to send has been paused. Password resets are failing silently. Order confirmations are vanishing. Every second counts.
Take a breath. A paused SES account is recoverable, but only if you approach the process correctly. AWS has a defined review and appeal workflow, and understanding it, along with knowing precisely what caused the pause and what remediation AWS expects to see, is the difference between a swift reinstatement and weeks of back-and-forth in a support case.
This guide covers everything: the enforcement ladder, the three most common triggers, how to triage the root cause, how to write an appeal that AWS will accept, and the monitoring practices that prevent you from ever ending up here again.
The SES Enforcement Ladder Explained
AWS does not jump straight to a full sending pause in most cases. There is a graduated enforcement process, and understanding each stage helps you act at the right moment rather than after the damage is done.
The Reputation Metrics dashboard in the SES console shows one of five account-level statuses. When everything is working normally, the status is Healthy. If a metric crosses a warning threshold, the account moves to Under Review. At this stage you can still send, but AWS has opened a case and is watching closely. If the issue is not corrected before the review period ends, the status moves to Pending Sending Pause, which indicates that the underlying problems have not been resolved and a pause is likely, but a member of the Amazon SES team must review the account before any further action is taken. Once a pause is applied, the status becomes Sending Paused and all outbound sending stops. A fifth status, Pending End of Review Decision, appears when the nature of the issues that triggered the review requires AWS to carry out a manual assessment before deciding on next steps.
It is worth noting that AWS can skip the Under Review stage entirely and pause an account immediately. This happens when the issue is very serious or when the account has been placed under review for the same problem multiple times before. The lesson is straightforward: address root causes properly the first time, not just the immediate incident that triggered the review.
The Three Most Common Triggers
Bounce Rate Exceeding 10%
Amazon SES calculates your bounce rate based on hard bounces only, measured against a representative volume of email rather than a fixed time window. This means the calculation reflects your typical sending behaviour and adjusts as your patterns change. AWS recommends keeping your bounce rate below 5% for best results. A rate at or above 5% triggers an automatic review. A rate at or above 10% can result in your account being paused until you resolve the underlying cause. Emails sent to the SES mailbox simulator and to verified addresses within your own account are excluded from the calculation.
Complaint Rate Exceeding 0.5%
A complaint is registered when a recipient marks one of your emails as spam using their email client's reporting feature. AWS recommends keeping your complaint rate below 0.1%. A rate at or above 0.1% places your account under review. A rate at or above 0.5% can trigger a sending pause. Complaints are a more serious signal than bounces because they represent a recipient actively telling their mailbox provider that your mail is unwanted, which has a direct and immediate effect on your sender reputation beyond the SES platform itself.
AWS Acceptable Use Policy Violations
The third category covers content and behaviour violations: sending unsolicited bulk email, using SES to distribute malware or phishing content, harvesting addresses without consent, or sending to lists that were purchased or scraped rather than collected through genuine opt-in. Violations of this kind can result in an immediate pause without a preceding review period. They are also the most difficult to appeal, because AWS needs to be satisfied not only that the problematic sending has stopped but that your account and infrastructure cannot be used to repeat it.
Immediate Triage: Finding Out Exactly What Happened
Before you write a single word of your appeal, you need to understand precisely what caused the pause. Submitting a vague or inaccurate appeal is one of the most common reasons reinstatement requests are rejected.
Start with the notification email AWS sent to the root email address associated with your AWS account. This email contains a summary of the issue, including the metric that was flagged and, in many cases, the approximate date range and volume involved. If you have not already done so, ensure the root account email address is one you actively monitor.
Next, open the SES console and navigate to the Reputation Metrics page. This shows you the current status of your bounce rate and complaint rate, including which metric triggered the enforcement action. The dashboard will indicate whether the status is Sending Pause for the bounce rate, the complaint rate, or both.
For more granular data, review your SNS bounce and complaint notification topics. If you have a configuration set attached to your sending identities with SNS event destinations configured, you will have a record of every bounce and complaint event. Querying these logs lets you identify which sending campaigns, which domains or subdomains, and which recipient segments drove the problem. If you do not have SNS event destinations configured, note this carefully: you will need to explain how you will put that infrastructure in place going forward.
Finally, review the relevant CloudWatch metrics under the AWS/SES namespace, specifically Reputation.BounceRate and Reputation.ComplaintRate. These give you a time-series view of how the metrics moved, which is useful for pinpointing whether the problem was caused by a single campaign, a batch of bad addresses added to your list, or a gradual accumulation of unmanaged bounces over time.
Fixing the Root Cause Before You Appeal
AWS will not reinstate your account simply because you have asked. The review team expects to see concrete remediation steps already implemented before the appeal is submitted. An appeal that only promises future changes, rather than documenting work already completed, is a common mistake that leads to rejection.
If your bounce rate was the trigger, the immediate priority is your suppression list. Every hard-bounce address must be added to your SES account-level suppression list so that SES will reject any future send attempts to those addresses before they are dispatched. Remove these addresses from all mailing lists and marketing automation sequences. If your application does not currently process bounce notifications automatically, build that pipeline now using SNS and a Lambda function or your own webhook endpoint, and document it in your appeal.
If your complaint rate was the trigger, you need to honour every complaint suppression immediately. When a recipient reports an email as spam, their address must be removed from all future sends. Review your list acquisition practices: are all recipients genuinely opted in? Is there a clear, one-click unsubscribe mechanism in every email you send? If you are not already processing SES complaint notifications through SNS, configure this before you submit your appeal and describe the implementation in your response.
In both cases, consider running your entire active list through a reputable email validation service to identify invalid, inactive, or risky addresses before you resume sending. This demonstrates to AWS that you are taking a systematic approach rather than treating the symptom in isolation.
If your pause was triggered by a policy violation, review the AWS Acceptable Use Policy in full, identify every aspect of your sending that could be considered non-compliant, and make changes that make a recurrence structurally impossible, not merely procedurally unlikely.
How to Submit Your Sending Review Request
AWS automatically opens a support case when an account is placed under review or paused. You do not need to open a new case. Sign in to the AWS Management Console, navigate to Support Centre, and reply to the case that was opened on your behalf.
Your reply must cover four things clearly and specifically. First, explain what you believe caused the high bounce or complaint rate, based on your investigation. Be precise: name the campaign, the list segment, the date, and the estimated number of affected sends. Second, describe in detail the steps you have already taken to resolve the issue. These must be concrete actions already completed, such as suppressing hard-bounce addresses, removing complaint addresses, updating your bounce-handling pipeline, or re-validating your list. Third, explain the processes you have put in place to prevent recurrence. Fourth, be aware that if AWS agrees your changes will reduce the rate, they can adjust their calculations to consider only messages sent after your changes were implemented, which can accelerate the return to Healthy status.
The most common reasons appeals are rejected are: vague descriptions of the problem, promises of future action rather than documentation of completed work, failure to acknowledge the root cause, and submitting the same appeal multiple times without incorporating feedback. Submit one thorough, well-evidenced appeal and wait for AWS to respond before resubmitting.
If you have AWS Premium Support, contact that team for additional guidance. If you have a dedicated AWS account representative, they may be able to advise on what the review team needs to see.
What Happens After You Submit Your Appeal
After AWS receives your review request, the team evaluates the information provided and decides whether to restore sending or to request further information. Response times vary depending on the complexity of the case and current queue volume. For straightforward cases with well-documented remediation, you can typically expect an initial response within a few business days, though situations involving policy violations or repeat reviews take longer.
If your appeal is successful, AWS will lift the sending pause and may reset your reputation metrics to consider only email sent after your changes were implemented, giving you a clean starting point. If AWS needs more information, they will reply to the support case with specific follow-up questions. Respond promptly and with the same level of specificity as your original appeal. Slow or vague responses at this stage extend the downtime significantly.
If your initial appeal is rejected, review the feedback carefully, identify what was not adequately demonstrated, and submit a revised response that addresses those gaps directly. Do not submit a slightly rephrased version of the same appeal.
Preventing a Recurrence: The Monitoring Stack You Need
Getting your account reinstated is only half the job. The other half is detecting problems early enough to correct them before AWS takes action.
CloudWatch Alarms Set at Safe Thresholds
AWS recommends using CloudWatch alarms to receive early warning of factors that could cause a sending pause. The key is to set your alarm thresholds well below the enforcement thresholds. For bounce rate, configure a first alarm at 5% using the Reputation.BounceRate metric in the AWS/SES namespace, and a second earlier-warning alarm at 3%. This gives you a meaningful buffer before the review threshold and a substantial margin before the 10% pause threshold. For complaint rate, a threshold of 0.1% is the review trigger, so configuring an alarm at 0.08% gives you time to investigate before AWS takes notice.
SES Configuration Sets to Isolate Traffic
One of the most effective structural changes you can make is to separate your transactional and marketing email streams using different SES configuration sets. By associating dedicated IP pools with separate configuration sets, your transactional email reputation is isolated from your marketing campaigns. If a promotional campaign drives up your complaint rate, it will not drag your transactional sends into the same enforcement action. Create one configuration set for transactional emails such as password resets and order confirmations, and a separate configuration set for marketing and newsletter traffic. Apply the appropriate configuration set to every send request from your application.
Automated Bounce and Complaint Processing
Every SES account should have SNS topics configured to receive bounce and complaint notifications, with an automated pipeline to process them. When a hard-bounce notification arrives, the recipient address should be added to your SES account-level suppression list and removed from all active sending lists immediately, without human intervention. When a complaint notification arrives, the same suppression and removal process should apply. This pipeline should be tested using the SES mailbox simulator, which lets you trigger bounce and complaint events without affecting your live reputation metrics.
How SES Monitor Fits Into Your Prevention Stack
Building and maintaining the CloudWatch alarm configuration, SNS pipelines, and suppression list automation described above is entirely achievable, but it requires ongoing engineering effort and careful calibration. SES Monitor is designed to fill the monitoring gap that exists between AWS's native tooling and the level of visibility you actually need to stay out of trouble.
SES Monitor connects directly to your SES account and provides continuous, real-time tracking of your bounce and complaint rates across all your sending identities and configuration sets. Rather than waiting for a CloudWatch alarm to fire or checking the Reputation Metrics dashboard manually, you receive webhook and email alerts as soon as your rates begin to trend towards unsafe levels, giving you time to investigate and act before you approach AWS enforcement thresholds.
Beyond real-time alerting, SES Monitor maintains an audit trail of your reputation metrics over time. This historical record is valuable in two situations. First, it helps you pinpoint exactly when and why a rate spike occurred, making your root cause analysis faster and more accurate. Second, if AWS ever opens a review, you can present a documented history of your monitoring practices and your responses to previous anomalies, which strengthens your appeal considerably. Demonstrating to AWS that you have a functioning monitoring and alerting system in place, and that you respond to signals before they become enforcement events, is one of the most persuasive things you can include in a reinstatement request.
Recovery Checklist: Twelve Steps from Pause to Long-Term Protection
Work through the following steps from the moment your account is paused through to the monitoring infrastructure that keeps it healthy.
1. Read the AWS notification email in full and note the specific metric and reason cited.
2. Open the SES Reputation Metrics dashboard and confirm which metric triggered the enforcement action.
3. Review SNS bounce and complaint logs and CloudWatch metrics to identify the source of the problem.
4. Add all hard-bounce addresses to your SES account-level suppression list immediately.
5. Suppress all complaint addresses from all future sends.
6. Validate your active mailing lists using a reputable third-party email verification service.
7. Implement or verify automated SNS bounce and complaint processing pipelines if not already in place.
8. Reply to the AWS support case with a specific, evidence-based appeal covering root cause, completed remediation, and prevention measures.
9. Respond promptly to any AWS follow-up questions with equally specific information.
10. Configure CloudWatch alarms for bounce rate at 5% and 3%, and for complaint rate at 0.08%, as ongoing early-warning indicators.
11. Create separate SES configuration sets for transactional and marketing email to isolate reputation signals.
12. Implement continuous reputation monitoring with alerting, such as SES Monitor, to catch rate movements in real time before they reach AWS enforcement thresholds.
A Paused Account Is a Warning, Not a Death Sentence
An Amazon SES sending pause is disruptive and stressful, but it is designed to be resolved. AWS provides a defined process, and they are willing to reinstate accounts where the sender demonstrates a genuine understanding of what went wrong and puts credible, verifiable controls in place to prevent a recurrence. The senders who struggle are those who appeal too quickly without completing the remediation, submit vague or template-like responses, or treat reinstatement as the finish line rather than the starting point for better practices.
The real finish line is a sending infrastructure where a pause becomes effectively impossible: your monitoring catches problems at 3% bounce and 0.08% complaint rates, your suppression lists are automatically maintained, your transactional and marketing traffic are isolated from each other, and you have an audit trail that demonstrates all of this to AWS if they ever ask. Build that stack, and the nightmare notification should never arrive again.