Why You Cannot Wait for AWS to Tell You First
Most Amazon SES senders discover a reputation problem in one of two ways: an AWS warning email arrives in the root account inbox, or sending suddenly stops. By either point, the damage is already done. Mailbox providers have been quietly routing messages to spam folders, complaint rates have been climbing, and your domain's long-term reputation has taken a hit that can take weeks to repair.
The gap between a metric crossing a dangerous threshold and an AWS account warning arriving is not a matter of seconds. It can be hours or days, and the lag is partly structural. AWS calculates bounce and complaint rates across a rolling representative sample of recent sending rather than a fixed window, which smooths out spikes but also means the dashboard lags behind what is actually happening to your mail stream. If you are relying on AWS to be the first to tell you something is wrong, you are already too late.
The right architecture inverts this. Proactive, threshold-based alerts at every layer of the sending stack mean your engineering or deliverability team catches a problem in minutes rather than days, and acts before any provider takes its own enforcement action. This article shows exactly how to build that system using CloudWatch alarms, SES configuration set event destinations, mailbox provider dashboards, and blocklist monitoring, and how a purpose-built tool such as SES Monitor can consolidate all of it without requiring you to build and maintain the infrastructure yourself.
The Four Reputation Signals That Matter in 2026
Before wiring up alerts, you need to know what you are alerting on and why each threshold matters now, not just historically.
Bounce rate. AWS places your account under review when your bounce rate exceeds 5%, and can pause sending entirely when it exceeds 10%. Best practice is to keep hard bounces well below 2% in normal operation. Hard bounces, those caused by invalid addresses or non-existent domains, count most heavily against your reputation and are the figures AWS weighs when deciding whether to act.
Complaint rate. AWS recommends staying below 0.1% and can pause your account if you exceed 0.5%. In 2026, the practical safe ceiling is lower than the AWS enforcement threshold alone suggests. Gmail and Yahoo both publish a hard ceiling of 0.3% measured in their own tooling, while recommending that senders stay below 0.1% for stable inbox placement. Industry practice treats 0.1% as the genuine working limit, because complaint spikes propagate quickly through mailbox provider reputation systems and recovery is slow. In concrete terms, a list of 10,000 recipients means just ten spam reports can push you past the recommended threshold.
Inbox placement rate. Bounce and complaint rates tell you about failures you can see. Inbox placement rate tells you about the failures you cannot: messages that are delivered but routed straight to the spam folder. In May 2026, AWS launched inbox placement metrics and blocklist monitoring inside Virtual Deliverability Manager, allowing senders to see what percentage of messages land in the inbox versus the spam folder based on representative industry sample data, broken down by sending domain and campaign.
Blocklist status. A blocklist listing for your sending IP or domain almost always precedes a broader deliverability collapse. Complaints drive blocklist listings, and blocklist listings drive further inbox-placement failures. Monitoring blocklist status gives you an early warning that sits upstream of the metrics AWS surfaces directly.
Layer 1: CloudWatch Alarms on Account-Level Metrics
Amazon SES automatically publishes two reputation metrics to CloudWatch: Reputation.BounceRate and Reputation.ComplaintRate. These are account-level figures, aggregated across all your sending identities and configuration sets in a given region. They are the right first layer of defence because they reflect exactly what AWS uses when deciding whether to review or pause your account.
Recommended threshold structure
Build two alarms for each metric: a warning alarm that fires early enough to investigate without panic, and a critical alarm that demands immediate action.
For bounce rate, set the warning alarm at 0.02 (2%) and the critical alarm at 0.04 (4%). The 2% warning gives you a generous runway before the AWS review threshold of 5%, and the 4% critical alarm means you have time to diagnose and suppress problematic addresses before a review is triggered. For complaint rate, set the warning alarm at 0.0005 (0.05%) and the critical alarm at 0.001 (0.1%). The 0.1% critical level corresponds to both the AWS recommended ceiling and the practical working limit enforced by Gmail and Yahoo, so firing at that level means you act before either AWS or the major mailbox providers take their own action.
Step-by-step CloudWatch alarm setup
In the CloudWatch console, navigate to Alarms and choose Create alarm. Click Select metric, navigate to SES, and select Reputation.BounceRate. Set the threshold to greater than or equal to 0.02, evaluate over one period of five minutes, and treat missing data as "ignore (maintain the alarm state)" rather than as a breach. This last setting matters: during low-volume periods, SES may not publish a metric datapoint, and treating that absence as a breach produces false-positive alerts that erode team trust in the system.
Under Configure actions, choose In Alarm as the trigger state and select an SNS topic as the notification target. That SNS topic can fan out to email, to a Slack channel via an SNS-to-Lambda integration, or directly to PagerDuty via its SNS endpoint. Repeat this process with a second alarm at 0.04 for the critical tier. Then create the equivalent pair for Reputation.ComplaintRate at 0.0005 and 0.001.
You can also provision these alarms as code. In AWS CloudFormation or Terraform, the resource is an AWS::CloudWatch::Alarm with Namespace: AWS/SES, MetricName: Reputation.BounceRate, and the thresholds described above. Keeping alarm configuration in version control means IAM permission changes or accidental console deletions cannot silently remove your monitoring without a code review catching it.
Layer 2: Per-Configuration-Set Alerts via Event Destinations
Account-level CloudWatch metrics are valuable, but they hide a critical problem: they blend all your sending streams together. If your transactional password-reset emails and your marketing newsletters share the same account-level signal, a complaint spike from a badly segmented campaign looks identical to a systemic deliverability problem. You can observe the effect but cannot diagnose the cause.
Configuration sets solve this by letting you tag sends by stream and capture granular events. The recommended pattern is to create separate configuration sets for transactional and marketing sends, each with an event destination that publishes bounce and complaint events to an SNS topic. You can then process those SNS messages in a Lambda function to suppress hard-bounced addresses, remove complainers, and feed per-stream metrics into your own dashboards.
Wiring up an event destination
Using the SES v2 API or the console, create a configuration set and add an event destination of type SNS. Set the matching event types to include at minimum BOUNCE and COMPLAINT. You can also include DELIVERY, OPEN, and CLICK if you want richer engagement signal, though for alerting purposes the bounce and complaint streams are what matter most.
Each bounce event payload includes the bounce type (hard or soft), the subtype, and the affected recipient addresses. Each complaint event includes the feedback type from the mailbox provider's feedback loop. A Lambda subscribed to this SNS topic can parse the JSON, add hard-bounced and complained addresses to the SES account-level suppression list automatically, and emit a custom CloudWatch metric per configuration set. That custom metric can then power its own CloudWatch alarm, giving you per-stream alerting rather than just account-level aggregation.
Every send made through SES must include the configuration set name in the API call or SMTP header for the event destination to fire. A common failure mode is deploying a new application service without adding the configuration set parameter, which means its bounces and complaints are invisible to your per-stream monitoring. An integration test that verifies the configuration set header is present on every sending code path is a worthwhile addition to your CI pipeline.
Layer 3: Mailbox Provider Dashboards as an Out-of-Band Signal
Google Postmaster Tools and Yahoo Sender Hub provide complaint rate data calculated independently of the feedback loops SES uses. This matters because SES complaint rates are derived from feedback loop reports that mailbox providers choose to share, which is not a complete picture. A provider can be increasing the spam classification rate of your mail without every individual spam report being forwarded through the feedback loop.
Google Postmaster Tools, available to any sender who has verified their domain, shows daily spam rate as measured by Gmail's own classifiers, domain reputation category (high, medium, low, or bad), IP reputation, and authentication pass rates. The spam rate shown in Postmaster Tools is the figure Gmail uses when enforcing its 0.1% recommendation and 0.3% hard ceiling, and it can diverge from the SES complaint rate visible in the CloudWatch dashboard. Building a scheduled job that polls the Postmaster Tools API and alerts when domain reputation drops from high to medium, or when the spam rate approaches 0.1%, gives you an out-of-band signal that AWS metrics alone cannot provide.
Yahoo Sender Hub provides similar domain-level reputation data and operates its spam threshold enforcement independently of Gmail. A sender can be within Gmail's thresholds while simultaneously approaching Yahoo's enforcement ceiling. Checking both dashboards is not redundant; it is necessary for a complete picture of your reputation across the major Western mailbox providers. Microsoft does not offer a public equivalent of Postmaster Tools, but its Smart Network Data Services programme provides aggregate complaint and reputation data for registered senders.
Layer 4: Blocklist Monitoring
A blocklist hit on your sending IP or domain almost always precedes a broader deliverability collapse, often appearing before complaint rates in SES metrics have climbed enough to trigger your CloudWatch alarms. IP-based blocklists affect all mail from a listed address regardless of domain reputation, while domain-based blocklists follow your sending domain wherever it goes. Either type causes immediate inbox-placement failures at the providers that consult those lists.
As of May 2026, AWS's Virtual Deliverability Manager includes blocklist monitoring as part of its global deliverability feature set. VDM checks your dedicated sending IPs and monitored domains against major blocklist operators hourly and surfaces recommendations through the VDM Advisor when a listing is detected, including the blocklist name, the listing reason, and delisting guidance.
If you use shared IPs rather than dedicated ones, you do not have direct control over the IP's blocklist status, which is one practical argument for dedicated IPs at higher sending volumes. For domain-level blocklist monitoring, VDM covers the major operators. Supplementing it with periodic checks against well-known domain-based lists via their query APIs adds further coverage and provides a secondary confirmation path that does not depend on a single AWS service being enabled.
Putting It Together: A Decision Tree for Each Alert
Having alerts fire is only useful if the team knows exactly what action each alert demands. The following covers the most common scenarios.
Warning-level bounce rate alarm fires (2% to 4%). Check the per-configuration-set event stream to identify which sending identity is contributing. Look for a recent list import, a segment that has not been mailed in more than six months, or a new acquisition source. Suppress the hard-bounced addresses immediately, pause sends from the affected segment, and run the remaining list through an email verification check before resuming.
Critical bounce rate alarm fires (above 4%). Pause sending from the affected configuration set immediately. Do not wait to diagnose first. Pull the bounce event logs from the SNS queue or Lambda output, categorise the bounce subtypes, and identify the source of the invalid addresses. Submit a review request to AWS if you believe the rate will drop quickly following suppression, and provide evidence of the root cause and the remediation steps taken.
Warning-level complaint rate alarm fires (0.05% to 0.1%). Review recent campaign content, subject lines, and sending frequency. Verify that an unsubscribe link is present, functioning, and prominent. Check Google Postmaster Tools domain reputation for any corresponding drop. Reduce sending frequency to the most engaged segments only until the rate stabilises.
Critical complaint rate alarm fires (at or above 0.1%). Pause all marketing sends. Transactional sends to recipients who have explicitly requested them can continue, but any broadcast or campaign traffic should stop. Identify whether a specific campaign drove the spike using per-configuration-set event data. Do not resume marketing volume until the complaint rate has been below 0.05% for at least three consecutive days as measured in both SES metrics and Google Postmaster Tools.
Blocklist hit detected. Identify whether the listing is on the sending IP or the domain. For an IP listing, check whether the listed IP is dedicated or shared. For a dedicated IP, open a delisting request with the blocklist operator and investigate the sending behaviour that triggered the listing. For a domain listing, treat it as a critical incident: domain reputation damage recovers more slowly than IP reputation damage, and some blocklist operators apply domain listings broadly across associated sending infrastructure.
Google Postmaster Tools domain reputation drops to medium or low. This is an early warning that Gmail's own classifiers have changed their view of your sending domain, independent of your SES metrics. It often precedes a rise in measured complaint rates by several days. Reduce volume, prioritise your highest-engagement segments, and verify that DMARC, DKIM, and SPF are all passing cleanly. Recovery from a domain reputation drop at Gmail typically takes two to four weeks of clean sending.
The Maintenance Burden You Need to Plan For
Alerting infrastructure decays. The failure modes are predictable enough that you can design against them explicitly.
SNS subscriptions expire or get accidentally unsubscribed. An email subscription to an SNS topic requires periodic re-confirmation. If the inbox receiving that confirmation changes or the confirmation is missed, the subscription silently drops. Periodically verify that all SNS subscriptions are active, and prefer HTTPS endpoints or Lambda integrations over email subscriptions in production alerting setups.
IAM permissions drift. The Lambda function or integration that processes SNS bounce and complaint events needs specific IAM permissions to write to the SES suppression list and publish custom CloudWatch metrics. When IAM policies are audited and tightened, these permissions are sometimes removed without considering the downstream effect on monitoring. Include IAM permission verification in your runbooks for periodic security reviews.
CloudWatch metric gaps during low-volume periods. If your account sends very few emails overnight or at weekends, the Reputation.BounceRate and Reputation.ComplaintRate metrics may not publish datapoints. Configuring alarms to treat missing data as "ignore" rather than as a breach prevents false alerts, but it also means a genuine problem that emerges during a low-volume window might not trigger an alarm until volume picks up again. Supplement CloudWatch alarms with a daily scheduled health check that actively queries the SES reputation dashboard via the API and compares the result against your thresholds.
Configuration set coverage gaps. As your application grows, new services or microservices may send email without being wired to the correct configuration set. An automated check that queries the SES API for sending identities and verifies that all active identities have a configuration set attached, and that the configuration set has an event destination for bounce and complaint events, is worth running on a scheduled basis.
How SES Monitor Consolidates All Four Layers
Building and maintaining the alerting architecture described above requires meaningful ongoing engineering effort. The CloudWatch alarm configuration, the per-configuration-set event destination wiring, the Google Postmaster Tools polling job, the blocklist monitoring integration, and the SNS subscription health checks all need to be built, tested, kept in version control, and kept working as AWS services evolve and your sending infrastructure changes.
SES Monitor is purpose-built to eliminate that maintenance burden. It connects to your Amazon SES account and provides a consolidated real-time dashboard covering bounce rate, complaint rate, inbox placement, and blocklist status without requiring you to configure CloudWatch alarms, manage SNS subscriptions, or build a Postmaster Tools polling pipeline. Pre-built alert thresholds aligned to the enforcement realities across AWS, Gmail, and Yahoo are included by default, and alerts can be delivered via email, webhook, or the SES Monitor API, making it straightforward to route signals into Slack, PagerDuty, or any incident management platform your team already uses.
For teams that want webhook delivery, SES Monitor pushes structured JSON payloads to your endpoint the moment a threshold is crossed. That means no polling, no CloudWatch alarm latency, and no SNS subscription management. For teams that want API access, the SES Monitor API exposes current and historical reputation metrics in a queryable format, so you can build your own dashboards on top of verified, normalised data rather than raw CloudWatch figures.
The gap between a reputation metric moving and your team knowing about it is where deliverability problems become deliverability crises. Closing that gap, whether by building the multi-layer CloudWatch architecture described in this article or by using a monitoring tool that has already built it, is one of the highest-value investments an SES sender can make.