SES under review: incident playbook when the panel still says healthy

An Amazon SES account can be placed under review for complaint rate while the console still shows acceptable metrics and EnforcementStatus returns HEALTHY. This is not a contradiction. It means AWS has flagged your account for manual evaluation based on direct recipient complaints from feedback loops, even though you have not yet crossed the automated suspension thresholds for bounces or complaints.

The confusion is understandable: “under review” sounds like “on probation,” but SES distinguishes between review status (AWS is watching you and wants proof you fixed the issue) and enforcement status (AWS has restricted or shut down your sending). You can be under review while enforcement is still healthy, or under review while already on probation. The review is the process. Enforcement is the penalty.

This playbook covers what to do when your SES account enters review for direct complaints, how to diagnose what triggered it, what actions make it worse, and how to build the evidence AWS Support needs to clear the review without escalating to probation or shutdown.

What “under review” means vs EnforcementStatus

Amazon SES monitors accounts for bounce rate, complaint rate, and sender behavior that indicates list quality problems or abuse. When AWS’s automated systems or manual reviewers flag an account, they can place it into review status — a holding state where the account is under evaluation but may still be sending.

Review status is separate from enforcement status, which is what most operators check first. The enforcement statuses you see in the console or via the SES API are:

HEALTHY — No active penalties; account is in good standing.
PROBATION — Warning state; sending is throttled or restricted, and further violations can lead to shutdown.
SHUTDOWN — Sending is disabled; production access is revoked pending resolution.

Being “under review” does not map 1:1 to these statuses. An account under review can have enforcement status HEALTHY if AWS wants documentation and proof of fixes before deciding whether to impose penalties. It can also be PROBATION if AWS already restricted sending and is reviewing whether to lift the restriction or escalate to shutdown.

The practical result: checking the SES console dashboard or calling GetAccount to read EnforcementStatus is not enough. You also need to check ReviewDetails, which tracks the review itself.

Checking review status via the SES API

The AWS CLI command to retrieve full account status, including review state, is:

aws sesv2 get-account

The response includes several fields most operators do not check until they hit a problem:

SendingEnabled — Boolean; false means sending is disabled entirely.
ProductionAccessEnabled — Boolean; false means the account is in sandbox mode or production access was revoked.
EnforcementStatus — String; HEALTHY, PROBATION, or SHUTDOWN.
MailType — String; TRANSACTIONAL, MARKETING, or SUBSCRIPTION. This is the use case you filed when you requested production access.
ReviewDetails — Object; includes Status (PENDING, GRANTED, DENIED) and CaseId if a support case exists.

If ReviewDetails.Status is PENDING and EnforcementStatus is HEALTHY, your account is under review but not yet penalized. AWS is waiting to see if the issue resolves or escalates. If EnforcementStatus is PROBATION, the review is active and penalties are already in place.

The distinction matters because the playbook for “under review, still healthy” is different from “under review, already on probation.” In the first case, you have time to document fixes and reopen your support case with evidence. In the second, you are already in damage control and AWS may impose further restrictions if the metrics do not improve quickly.

Why complaint-rate reviews happen and how they differ from bounce reviews

SES places accounts under review for two primary reasons: hard bounce rate and complaint rate. The mechanics and remediation are different.

A hard bounce is a permanent delivery failure — the recipient address does not exist, the domain is invalid, or the mailbox is disabled. Hard bounces are technical failures. They indicate poor list hygiene, but they do not necessarily indicate abuse. A high bounce rate (above 5%) triggers automated warnings and eventually probation, but the fix is straightforward: stop mailing invalid addresses, clean your list, verify addresses before sending.

A complaint is a recipient clicking “report spam” or “mark as junk” in their mail client. Complaints come through feedback loops — agreements between mailbox providers (Gmail, Outlook, Yahoo, Apple Mail) and sending platforms that report when recipients flag a message as spam. Complaints are not technical failures. They are user intent. The recipient is telling you (and their mailbox provider) that they did not want the email.

AWS’s acceptable complaint rate threshold is 0.1% — one complaint per 1,000 sends. That sounds high until you realize that it is cumulative over a rolling window (typically 7–14 days) and that feedback loops report complaints from sends that happened days or weeks ago. A batch of 10,000 emails sent last Tuesday can generate complaints on Friday, and those complaints count toward your current rolling rate even if you stopped sending to that list.

Complaint-rate reviews are distinct from bounce-rate reviews because they indicate sender behavior problems, not just data quality problems. AWS interprets high complaint rates as evidence that you are:

Mailing recipients who did not opt in or no longer want your mail.
Sending content that looks like spam even if the recipients technically consented.
Ignoring unsubscribe requests or making unsubscription difficult.
Mismatching your stated use case — filing for TRANSACTIONAL access but sending MARKETING email.

The last point is not hypothetical. SES evaluates your sends against the MailType you declared when you requested production access. If you told AWS you send password resets and receipts, and AWS sees complaint patterns consistent with cold email or bulk newsletters, the review will include questions about use case alignment. List hygiene alone will not resolve it.

Incident playbook: what to do when your account enters review for complaints

When your SES account is placed under review for complaint rate, the immediate goal is to stop making the problem worse. The second goal is to gather evidence that you identified the source of the complaints and fixed it. The third goal is to generate a clean track record so AWS Support can clear the review.

Step 1: Freeze the segment that triggered complaints

Complaints do not arrive instantly. Feedback loops report them hours or days after the send. By the time AWS places you under review, the emails that caused the complaints are already delivered, and you cannot unsend them. But you can prevent further damage by stopping sends to the same segment.

Identify which batch or audience segment generated the complaints. Check your send logs for the time period AWS cited (usually visible in the support case or in CloudWatch if you are logging all sends). Isolate the segment — the list, the suppression state, the acquisition source — and freeze it. Do not send to it again until you have cleaned it and verified the cleanup.

The common mistake: assuming the complaints came from a small subset of the segment and continuing to mail the rest. Feedback loops only report complaints from mailbox providers that participate in the loop. Gmail reports complaints. Custom-domain recipients on small hosting providers do not. If you got 10 complaints from 5,000 sends, there may be 40 more recipients who marked you as spam but their mailbox provider does not report it to AWS. Treat the entire segment as suspect until proven otherwise.

Step 2: Separate transactional from marketing sends

If you are using SES to send both transactional email (password resets, receipts, order confirmations) and marketing email (newsletters, promotions, announcements), separate them into different configuration sets immediately. Do not wait for AWS to ask you to do this. It is the first thing they will check.

SES allows multiple configuration sets per account. Each set can have its own dedicated IP pool (if you have dedicated IPs), its own suppression list settings, and its own event destinations. Create one configuration set for transactional sends and another for marketing. Route each send to the appropriate set based on the email type.

Why this matters: AWS’s threshold for complaint rate is stricter for accounts that claimed TRANSACTIONAL use when requesting production access. If you filed as transactional but you are sending newsletters that generate complaints, AWS will ask why your transactional emails are triggering spam reports. The answer “we are also sending marketing” is not acceptable unless you amend your production access case to declare both use cases. Separating the sends now makes it easier to demonstrate that your transactional emails are not the problem.

Step 3: Suppress complainers and stale addresses immediately

Every address that generated a complaint must be suppressed permanently. Do not send to them again. This is not optional. AWS monitors whether you continue to mail addresses that previously complained, and continuing to do so is interpreted as ignoring feedback.

If you are processing bounce and complaint notifications via SNS (required for production access), verify that your suppression handler is writing complaint events to your database or suppression table. Check that the suppression table is queried before every send. If there is a delay or a logic gap between “complaint reported” and “address suppressed,” fix it now.

Also suppress addresses that have not engaged in months. An address that has not opened or clicked in six months is functionally dead, even if it does not bounce. Mailbox providers treat consistent non-engagement as a signal that the recipient does not want the mail, and they are more likely to route your sends to spam or promotions. Continuing to mail unengaged addresses increases your risk of complaints from recipients who forgot they subscribed or who no longer recognize your sender name.

The suppression logic should be:

Hard bounce → suppress immediately (required by AWS).
Complaint → suppress immediately (required by AWS).
Unsubscribe → suppress immediately (required by law and AWS policy).
No engagement (opens or clicks) in 90–180 days → suppress or re-confirm opt-in.

Step 4: Document acquisition source and timeline

AWS Support will ask how the addresses that generated complaints were acquired. The answer must be specific: “collected via web signup form on [date range],” “imported from [previous platform] on [date],” “purchased from [list vendor]” (do not do this), “scraped from [public source]” (definitely do not do this).

If you cannot document where the addresses came from or when they opted in, that is a problem. AWS interprets lack of documentation as evidence that the list was acquired improperly. If you collected the addresses yourself via double opt-in, you should be able to point to the signup timestamp, the confirmation email, and the IP address of the opt-in. If you imported them from a previous platform, you should have export records from that platform showing when each address was added.

Build a timeline:

When did you acquire the addresses?
When did you send the email that triggered complaints?
How many complaints did you receive, and over what time window?
What suppression or validation steps have you added since the incident?

AWS does not require a formal report, but having this written down in your support case response makes it clear that you know what happened and that you have a plan to prevent recurrence.

Step 5: Send clean volume to engaged recipients while under review

One counterintuitive aspect of complaint-rate reviews: going completely silent can make your rolling complaint rate worse.

Complaint rate is calculated as complaints divided by sends over a rolling window (typically 7–14 days). If you sent 10,000 emails last week and received 15 complaints (0.15% — above AWS’s 0.1% threshold), and you stop sending entirely this week, the denominator stays at 10,000 while late-arriving complaints continue to trickle in from feedback loops. Your rate can climb to 0.20% or 0.25% even though you stopped sending, because the window has not yet cleared the bad batch.

The correct response is to send clean, engaged volume to recipients who recently opened or clicked, who have not complained, and who are still actively using your product or service. This adds legitimate sends to the denominator and dilutes the rolling rate without risking new complaints from cold or stale addresses.

The clean segment criteria:

Opened or clicked within the last 30 days.
Never complained or bounced.
Explicit opt-in or recent transaction (for transactional sends).

Send only to this segment while under review. Do not try to “fix” the rate by blasting high volume to random addresses just to increase the denominator. AWS monitors for unusual send patterns, and a sudden spike in volume during a review is a red flag. Send normal volume to your best recipients and let the rolling window clear the bad batch naturally.

Step 6: Make unsubscribe visible and frictionless

One reason recipients click “report spam” instead of “unsubscribe” is that the unsubscribe link is invisible, buried, or does not work. AWS wants to see that you are making it easy for recipients to opt out without reporting you.

Every marketing email must have a visible unsubscribe link in the footer. The link must work — clicking it should immediately suppress the address, not require a login, not require a confirmation step, and not take more than one click.

In addition to the footer link, implement List-Unsubscribe headers:

List-Unsubscribe: <mailto:unsub@yourdomain.com>, <https://yourdomain.com/unsubscribe?id=xyz>
List-Unsubscribe-Post: List-Unsubscribe=One-Click

The List-Unsubscribe-Post header enables one-click unsubscribe in Gmail and other mailbox providers that support it. When the recipient clicks the unsubscribe button in their mail client UI, the client sends a POST request to your endpoint and the address is suppressed instantly, without the recipient ever seeing your website.

Supporting one-click unsubscribe reduces complaints because recipients who want to stop receiving your mail have a faster, easier path than “mark as spam.”

Step 7: Build a 14-day clean record before reopening the support case

AWS does not publish explicit timelines for how long you must maintain clean metrics before a review is cleared, but operators report that 7–14 days of sends with no new complaints and bounce rate under 5% is typically enough to reopen the support case with evidence.

During this period:

Send only to clean, engaged segments (as described in Step 5).
Monitor complaint rate and bounce rate daily via CloudWatch or the SES console.
Verify that your suppression handler is working (no re-sends to previously bounced or complained addresses).
Document the changes you made: which segments you froze, how you amended your suppression logic, how you improved unsubscribe visibility.

After 14 days of clean sending, respond to the AWS support case with:

A summary of what triggered the complaints (acquisition source, send date, segment characteristics).
The steps you took to fix it (frozen segments, updated suppression logic, separated transactional from marketing, added one-click unsubscribe).
The current metrics (complaint rate under 0.1%, bounce rate under 5%, evidence from CloudWatch or SES console screenshots).
A statement of your plan to prevent recurrence (ongoing suppression of unengaged addresses, validation of new acquisitions, monitoring of rolling complaint rate).

AWS Support uses this information to decide whether to clear the review. The response is typically 1–3 business days. If the metrics are clean and the documentation is clear, the review is lifted. If AWS has follow-up questions (use case alignment, list acquisition practices, suppression logic gaps), they will ask. Answer specifically. Do not be vague.

What not to do: actions that make the review worse

Several common responses to an SES complaint-rate review make the situation worse instead of better. AWS monitors for these, and doing them extends the review or escalates enforcement.

Do not blast volume to dilute the percentage

The math looks tempting: if your complaint rate is 0.15% because you received 15 complaints from 10,000 sends, sending 100,000 more emails would drop the rate to 0.015% if none of the new sends complain. This is called “dilution,” and AWS flags it as abuse.

Why it does not work: AWS tracks complaint volume and complaint rate over time, and a sudden 10× spike in send volume during a review is not normal sender behavior. It looks like an attempt to game the metric. AWS’s review process includes manual evaluation, and reviewers can see your send history. A volume spike during a review is evidence that you are trying to manipulate the rate instead of fixing the underlying issue.

Even if the spike does not trigger additional penalties, it is wasted cost and reputation risk. Every send exposes your domain and IP to mailbox provider filters. If the new sends generate even a small number of complaints, you have made the problem worse.

Do not re-send to the same list with minor changes

“We cleaned up the subject line and the unsubscribe link; it should be fine now” is not a fix if you are re-mailing the same segment that generated complaints the first time. The problem is not the subject line. The problem is that the recipients do not want the email.

Feedback loops do not report complaints instantly. Some mailbox providers batch reports daily. Re-sending to the same segment before the feedback loop clears means you are layering new complaints on top of old complaints, and the rolling rate climbs instead of falling.

If the segment generated complaints, freeze it. Do not mail it again until you have re-confirmed opt-in or removed unengaged addresses. “We made the email better” does not change the fact that the recipients already told you they did not want it.

Do not ignore MailType mismatches

If you filed for TRANSACTIONAL production access but you are sending newsletters, promotional campaigns, or cold outreach, AWS will eventually flag the mismatch. It may not happen on day one, but when your complaint rate climbs and AWS reviews your account, they check whether your sends align with your declared use case.

The fix is not to stop sending marketing email. The fix is to amend your production access case to declare both TRANSACTIONAL and MARKETING use cases, and to separate the two into different configuration sets. AWS allows both. They do not allow you to claim one and send the other without disclosure.

If your current MailType is TRANSACTIONAL and you are under review for complaints from marketing sends, respond to the support case with a use case amendment. Explain that you send both transactional (password resets, receipts) and marketing (newsletters, product updates), describe how you are separating them into different configuration sets, and request that your account be updated to reflect both use cases.

AWS will ask for proof that you have list hygiene and suppression logic for marketing sends. Provide it. Do not try to redefine marketing email as transactional just to avoid the amendment.

Do not go silent if it starves the rolling window incorrectly

As noted in Step 5, stopping all sends during a review can cause the rolling complaint rate to climb, because the denominator stops increasing while late complaints continue to arrive. This is less common than the reverse problem (blasting volume to dilute the rate), but it happens.

The correct approach: send low, clean volume to your most engaged segment. Do not stop entirely unless AWS explicitly tells you to. Verify that the rolling window is clearing by checking CloudWatch metrics daily. If the complaint rate is rising even though you stopped sending, that is evidence the window is still processing complaints from the old batch. Wait for it to clear, then resume clean sends.

How MailType alignment and use case filing affect review outcomes

One detail that operators miss until they are under review: AWS evaluates your sends against the MailType you declared when you requested production access. If you filed as TRANSACTIONAL, AWS expects transactional sends. If you filed as MARKETING, AWS expects marketing sends and will enforce stricter list hygiene requirements.

The distinction is not cosmetic. Transactional sends have different legal and deliverability requirements than marketing sends:

Transactional emails are expected sends: password resets, order confirmations, account notifications. Recipients should never complain about them because they triggered the send themselves. A high complaint rate on transactional email is a signal that something is wrong — either the emails are not actually transactional, or they look enough like spam that recipients do not recognize them.
Marketing emails are promotional: newsletters, product updates, sales campaigns. Recipients may have opted in at signup but may no longer want them. A moderate complaint rate (under 0.1%) is expected. Higher rates indicate list decay, poor segmentation, or unclear unsubscribe paths.

If your MailType is TRANSACTIONAL but your complaint patterns look like marketing sends (high volume, low engagement, complaints from recipients who signed up months ago and forgot about you), AWS will ask whether you are actually sending transactional email or whether you misclassified your use case to get easier production access approval.

The fix: amend your use case. Open the original production access support case (or create a new one if you cannot find it) and add a use case description for marketing sends. Describe your list acquisition process, your suppression logic, and your unsubscribe flow. AWS will evaluate it and update your MailType to MARKETING or to a combined TRANSACTIONAL,MARKETING state.

Once your use case is amended, AWS will evaluate your complaint rate against marketing email standards, which are slightly more forgiving than transactional standards. But you still have to stay under 0.1%, and you still have to demonstrate list hygiene.

When to reopen the support case and what evidence AWS needs

AWS typically contacts you when your account is placed under review, either via email or via a support case created on your behalf. If you were not contacted but you notice ReviewDetails.Status is PENDING in the API response, you can open a support case yourself.

The initial response from AWS is often generic: “Your account has been placed under review due to elevated complaint rate. Please review your sending practices and ensure you are following AWS’s email policies.” This is not useful, but it is the starting point.

Your response should include:

What triggered the review — Specific send batch, date range, segment characteristics. “On [date], we sent a newsletter to [N] recipients acquired via [source] between [date range]. This batch generated [N] complaints over [time window], bringing our rolling complaint rate to [X]%.”
What you have changed — Frozen segments, updated suppression logic, separated transactional from marketing, added one-click unsubscribe. Be specific. “We have frozen the segment that generated complaints and will not mail it again. We have updated our suppression handler to check the suppression table before every send, not just before bulk sends. We have separated transactional and marketing sends into different configuration sets. We have added List-Unsubscribe-Post headers to all marketing emails.”
Current metrics — Complaint rate, bounce rate, send volume, time period. Include screenshots from CloudWatch or the SES console if possible. “Since [date], we have sent [N] emails to engaged recipients (opened or clicked in the last 30 days). Our complaint rate over the last 14 days is [X]%, and our bounce rate is [Y]%.”
Prevention plan — Ongoing suppression of unengaged addresses, validation of new acquisitions, monitoring of rolling complaint rate. “We have implemented a monthly suppression job that removes addresses with no engagement in the last 90 days. We are validating all new acquisitions via double opt-in. We are monitoring complaint rate daily via CloudWatch alarms set to alert if the rate exceeds 0.08%.”

AWS Support will review the case and either clear the review, ask follow-up questions, or (if metrics are still poor) leave the review in place and ask you to continue monitoring. If the review is cleared, ReviewDetails.Status will change to GRANTED and EnforcementStatus will remain HEALTHY (or return to HEALTHY if it was elevated to PROBATION).

If AWS asks follow-up questions, answer them specifically. Do not be defensive. The review is not a punishment; it is a process to verify that the issue is resolved. AWS wants to clear the review as much as you do, but they need evidence that you know what went wrong and that it will not happen again.

Complaint-rate reviews often overlap with other SES operational issues — tracking pixel consent, cost modeling for high-volume sends, and the choice between managed APIs and running SES in your own AWS account.

The pixel is not the email: SES per-send tracking, and why a leaked SaaS key is not your AWS covers how to handle per-send tracking overrides for GDPR/CNIL compliance and the distinction between customer credential leaks and provider breaches.

Resend vs Amazon SES: cost, lock-in, and when to send from your own AWS compares the cost and operational surface area of managed email APIs vs SES at 10k, 500k, and 2M email volumes.

How to choose a transactional email API covers the full decision tree for deliverability, cost, and lock-in when evaluating transactional email platforms.

AWS SES production access is the guide to requesting production access, including what AWS wants to see in your bounce and complaint handling plan.

The common thread: SES complaint-rate reviews are not random. They are triggered by sender behavior that AWS interprets as poor list hygiene, use case mismatches, or insufficient suppression. The resolution is not just “wait it out.” It is to document what went wrong, demonstrate that you fixed it, and build a clean track record that proves the fix worked.

If you are under review, you have time to fix it before enforcement escalates. Use the time. Freeze bad segments, separate transactional from marketing, suppress complainers and unengaged addresses, document your changes, and reopen the support case with evidence. The review is not permanent, but ignoring it or trying to game the metrics will make it permanent.

Selva Mail is a licensed email platform that runs on your AWS account and sends through your SES. It handles suppression, bounce processing, and event webhooks, with built-in configuration set management for separating transactional and marketing sends. One-time license, $497. See what’s included.