Why Reputation Problems Are Always Visible in Hindsight
Every Amazon SES account suspension follows the same pattern in retrospect. The bounce rate climbed gradually over two weeks. The complaint spike on a particular configuration set appeared three days before the account went under review. The Microsoft SNDS dashboard turned amber the morning after a list import. The signals were there. Nobody was watching them.
The AWS enforcement thresholds are well documented: a bounce rate above 5% triggers a review and above 10% can pause sending; a complaint rate above 0.1% triggers a review and above 0.5% can pause the account entirely. Knowing those numbers is not the same as having an early-warning system. By the time a metric crosses an enforcement line, the deliverability damage is already done. ISPs have already begun filtering or blocking, and the AWS support queue becomes your only path back to normal sending.
This guide works through the three tiers of reputation data available to SES senders, explains how to set alarms well ahead of enforcement thresholds, and shows how to wire ISP-level signals into a workflow that lets you act days before AWS does.
The Three Tiers of SES Reputation Data
Amazon SES reputation monitoring draws on three distinct layers of data, each with different latency, granularity, and diagnostic value. Tier 1 is the AWS-native layer: the SES Reputation Dashboard and CloudWatch metrics. Tier 2 is ISP-level feedback: Yahoo ARF complaints surfaced through SNS, the Gmail complaint signal via Google Postmaster Tools, and Microsoft SNDS and JMRP. Tier 3 is cross-signal analysis, where you correlate data across sources to identify patterns that none of them surfaces alone. A robust early-warning system requires all three.
Tier 1: The SES Reputation Dashboard
What the dashboard actually measures
The SES Reputation Metrics page in the AWS console shows two primary rates: your bounce rate and your complaint rate. These are the same numbers the AWS enforcement team watches, which makes the dashboard a genuinely useful signal rather than a cosmetic reporting tool. The account status indicator reflects the combined health of both metrics and can show states including Healthy, Under Review, and Paused.
The dashboard does not calculate rates based on a fixed time window. Because each SES account sends different volumes at different cadences, AWS uses a representative volume of recent sends rather than a rolling seven-day or thirty-day window. This means a quiet period followed by a burst campaign can shift the denominator quickly, making a small absolute number of bounces look worse or better than a simple daily rate would suggest. A sender who fires five emails and receives one bounce does not suddenly show a 20% bounce rate in the dashboard, because the representative volume smooths out that kind of noise.
Why the console number lags reality
The dashboard reflects account-level reputation, aggregated across all sending identities and configuration sets in your region. It does not tell you which configuration set, which campaign, or which list segment is responsible for a deteriorating rate. More importantly, it does not send notifications when rates approach dangerous levels. You have to go and look. That passive model is precisely why reputation problems go undetected until it is too late.
Setting CloudWatch Alarms at Pre-Enforcement Thresholds
Amazon SES automatically publishes reputation metrics to Amazon CloudWatch, including Reputation.BounceRate and Reputation.ComplaintRate under the AWS/SES namespace. These metrics form the basis for automated alerting that can notify you well before AWS enforcement begins.
Recommended alarm thresholds
For a genuine early warning, set a first CloudWatch alarm at 0.03 for bounce rate (3%) and 0.0008 for complaint rate (0.08%). These pre-enforcement thresholds give you meaningful reaction time before the account review process begins. Set a second alarm at the enforcement boundary: 0.05 for bounce rate (5%) and 0.001 for complaint rate (0.1%). Crossing that second alarm means you are already in territory AWS considers elevated and action must be immediate.
To create a bounce rate alarm in the CloudWatch console, navigate to Alarms, choose Create Alarm, then select the metric by navigating to SES, then Account Metrics, then Reputation.BounceRate. Set the period to one hour, the statistic to Average, and the threshold to your chosen value. Under Actions, attach an SNS topic that sends notifications to your on-call channel. Repeat the process for Reputation.ComplaintRate. Running separate alarms for the early-warning threshold and the enforcement-boundary threshold lets you distinguish an amber situation from a red one without opening the console.
Per-configuration-set metrics
Account-level metrics are useful but coarse. If you have separate configuration sets for transactional email, marketing campaigns, and automated notifications, you can enable reputation metrics publishing on each configuration set individually and create per-set CloudWatch alarms. A complaint spike on your marketing configuration set becomes immediately separable from your transactional stream, which makes the root cause obvious and prevents unnecessary alarm fatigue. Enable this via the UpdateConfigurationSetReputationMetricsEnabled API call or through the SES console for each configuration set.
Use the SES mailbox simulator to verify that your alarms fire correctly before relying on them in production. Sending to the simulator bounce and complaint addresses generates the appropriate events without affecting real recipient addresses or your live reputation metrics.
Tier 2: ISP Feedback Loops for SES Senders
Yahoo ARF complaints via SNS
Yahoo operates a traditional complaint feedback loop that forwards Abuse Reporting Format (ARF) complaint messages to enrolled senders. Amazon SES participates in this loop on behalf of its customers. When a Yahoo Mail user marks one of your SES emails as spam, Yahoo generates an ARF report and routes it to AWS, which then forwards the notification to the SNS topic configured for your sending identity's complaint notifications.
Yahoo complaint data is already flowing into your SES SNS notification pipeline if you have configured complaint notifications correctly. The key point on granularity: the SNS notification tells you a complaint occurred and includes sending metadata, but does not surface the original recipient's address. You receive enough data to identify the configuration set, the approximate send time, and the message ID, which is sufficient to tie the complaint back to a campaign or list segment.
What you do not see via SNS are complaint signals from Gmail. Google does not operate a traditional ARF-based feedback loop. Gmail complaints reach you only through Google Postmaster Tools, which is why the Feedback-ID header matters so much for SES senders.
The Gmail Feedback-ID header
Google Postmaster Tools provides aggregate spam rate and reputation data for your sending domain, but by default it shows complaint rates at the domain level only. Without campaign-level granularity, you know your domain had a high complaint rate on a given day but have no way to determine from within Postmaster Tools alone which send caused it.
The Feedback-ID header solves this. It is a standard email header that tells Gmail how to bucket your sends for aggregated complaint reporting. The format is a:b:c:SenderID, where the SenderID is a stable identifier for the sending entity and the optional fields to its left can represent campaign ID, customer ID, mail type, or any grouping meaningful to your operation.
Amazon SES automatically embeds a Feedback-ID header on every outbound message, using internal AWS identifiers in the first three positions and AmazonSES as the SenderID field. This means your domain is already registered in Postmaster Tools complaint data, but all your sends appear as a single undifferentiated bucket. To get campaign-level breakdown, SES allows you to inject two custom values into the Feedback-ID header using the message tags ses:feedback-id-a and ses:feedback-id-b. SES places these custom values in the first and second fields of the header automatically, producing a header in the format your-campaign-id:your-stream-id:region.accountId:AmazonSES.
You can pass these tags when calling the SES API via SendEmail or SendRawEmail, or through the SMTP interface as message tags. A practical tagging convention is to use the campaign or batch ID in ses:feedback-id-a and the mail stream type (for example, promo, transactional, or digest) in ses:feedback-id-b. Once the tags are in place and your domain is verified in Google Postmaster Tools, Gmail will surface complaint rates broken down by each identifier independently, once it has accumulated sufficient aggregate volume to report on them.
Without this setup, a complaint spike in Postmaster Tools requires you to cross-reference send timestamps with the complaint trend manually. With it, the answer is directly visible in the Postmaster Tools spam rate chart. Note that Postmaster Tools data applies only to messages delivered to personal Gmail accounts ending in @gmail.com or @googlemail.com, so it does not represent Google Workspace deliverability. For consumer-facing senders, however, it covers a significant proportion of the complaint signal.
Microsoft SNDS and JMRP
Microsoft operates two complementary tools for senders using dedicated IP addresses: Smart Network Data Services (SNDS) and the Junk Mail Reporting Program (JMRP). These are relevant to SES senders who have been allocated dedicated IPs. Senders on SES shared IP pools do not control those IPs and cannot register them directly.
SNDS is Microsoft's IP reputation dashboard. It provides a daily view of sending volume and a filter result indicator for each registered IP range, using a traffic-light system: green indicates normal filtering, yellow indicates heightened filtering, and red indicates severe filtering that is likely causing significant blocking at Outlook.com and Hotmail. SNDS data is not real-time; it is daily-aggregated, so use broad trends rather than single-day fluctuations to guide decisions. Note that following Microsoft's SNDS portal migration in June 2026, spam trap hit data has been removed from the dashboard; filter status and sending volume data remain.
JMRP is the corresponding complaint feedback loop. When an Outlook.com or Hotmail user marks one of your emails as junk, JMRP forwards an ARF report to the notification address you register. As part of Microsoft's 2026 overhaul of its postmaster services, JMRP reports now contain only the original message headers and selected authentication headers, with the sender address redacted and the full email body removed. Any complaint attribution workflow that relied on parsing body content is now broken. You need your own send-time tracking, using campaign IDs in headers or message UUIDs, to map the message ID back to the campaign and segment. The required action remains the same: suppress the complainant immediately and investigate the list segment that generated the report.
Following the same migration, any JMRP feeds not linked to an SNDS account have been removed. If your existing setup was registered separately, you must recreate it from within your SNDS account and keep the network access current to continue receiving reports. Automated report links now expire after 30 days, so any tooling that fetches JMRP or SNDS data programmatically requires a planned refresh process. Registration for both services goes through the Microsoft Sender Support portal using a Microsoft account, with IP ownership verified via WHOIS or DNS abuse contact records.
Tier 3: Reading the Signals Together
A green, amber, red escalation ladder
Individual signals are useful. Combined signals are diagnostic. The following escalation model gives a practical framework for deciding what action to take and when.
Green: Bounce rate below 2%, complaint rate below 0.05%, SNDS showing green on all dedicated IPs, Postmaster Tools domain reputation at High or Medium, no CloudWatch alarms in ALARM state. No action required beyond routine monitoring. Review dashboards weekly.
Amber: Any one of the following: bounce rate between 2% and 4%, complaint rate between 0.05% and 0.08%, SNDS showing yellow on one or more IPs, Postmaster Tools domain reputation dropping to Low, or a CloudWatch early-warning alarm firing. At amber, pause any new list imports, audit the most recent campaign or send for list quality issues, check whether a specific configuration set is the source of the deterioration, and confirm that bounces are being suppressed correctly.
Red: Bounce rate above 4%, complaint rate above 0.08%, SNDS showing red, Postmaster Tools domain reputation at Bad, or a CloudWatch enforcement-boundary alarm firing. At red, pause non-essential sending immediately, open an AWS Support case proactively rather than waiting for an account review notice, perform a full list audit, and quarantine the sending stream responsible.
Common early-warning patterns and their diagnoses
A complaint spike isolated to one configuration set, with other sets remaining stable, almost always points to a specific campaign or audience segment rather than a systemic list quality problem. Pull the sending history for that configuration set and look for a recent batch sent to an older or re-engaged segment.
A bounce rate that rises sharply immediately after a list import indicates the imported list contains stale or invalid addresses. Hard bounces from non-existent domains or addresses are the primary cause. Halt sending from the new segment, run the addresses through a validation service, and resume only with the clean subset.
SNDS showing a red filter result on a specific dedicated IP while other IPs remain green suggests that IP has a sending pattern or content characteristic that Microsoft's filters are responding to differently. Compare the volume, send frequency, and recipient domains served by that IP against your other IPs to isolate the cause.
A rising complaint rate in Postmaster Tools that is not reflected in your SES SNS complaint notifications is a signal that Gmail users are generating complaints that are not being forwarded via ARF. This is expected, because Gmail does not operate a traditional ARF loop; those complaints surface only in Postmaster Tools. If the Postmaster Tools spam rate is rising while your SNS-reported complaint rate looks flat, the SNS number is giving you a false sense of comfort.
Building a Proactive Monitoring Workflow
The components for a proactive SES reputation monitoring system are all available without custom development. CloudWatch alarms on Reputation.BounceRate and Reputation.ComplaintRate, routed through SNS to a Slack channel or PagerDuty, give you immediate notification of account-level deterioration. Per-configuration-set alarms add the granularity needed to diagnose which stream is responsible. An SNS topic subscribed to SES complaint and bounce notifications feeds your suppression list processor and gives you raw event data for trend analysis. Google Postmaster Tools, checked at least weekly, surfaces the Gmail-specific complaint signal that does not appear anywhere in AWS. SNDS, for dedicated IP senders, provides the Microsoft-specific IP reputation view that completes the picture.
The monitoring checklist that ties this together is straightforward. Check CloudWatch alarm states daily. Review the SES Reputation Dashboard weekly. Open Postmaster Tools and check domain reputation and spam rate trends weekly. If you have dedicated IPs, check SNDS weekly and after any significant volume change, and ensure your automated access links are refreshed before the 30-day expiry. After every significant list import or new campaign, review per-configuration-set bounce and complaint rates for the first 24 hours of sending.
Tools such as SES Monitor can automate much of this workflow, surfacing bounce rate and complaint rate trends, alerting on threshold breaches, and consolidating signals that would otherwise require manual dashboard checks across multiple platforms. The goal is to reduce the time between a signal appearing and a human acting on it, because in SES reputation management, days matter.
Conclusion
Amazon SES does not suspend accounts without warning. It enforces thresholds that were visible as trends before they became problems. The senders who avoid account pauses are not those with perfect lists; they are the ones who see the signals early enough to act. CloudWatch alarms set at pre-enforcement thresholds, Feedback-ID tags that unlock campaign-level complaint data in Postmaster Tools, Yahoo ARF complaints processed through SNS, and SNDS checked regularly for dedicated IP senders form a complete early-warning system. Build it before you need it.