Why Thresholds Matter More Than Ever in 2026
For years, exceeding a mailbox provider's spam or bounce tolerance meant your messages were deferred or routed to the junk folder. That era is over. Gmail escalated enforcement in November 2025, moving from temporary deferrals to permanent rejections for non-compliant traffic. Microsoft followed on 5 May 2025 with outright SMTP-level rejection for domains that fail authentication, surfacing error 550 5.7.515 rather than a quiet junk-folder placement. Yahoo mirrors Gmail's enforcement stance at comparable thresholds. The consequence is immediate and measurable: non-compliant senders bounce at the gateway, and those bounces feed back into your Amazon SES reputation score in real time.
If you run email through Amazon SES you are therefore managing two overlapping sets of rules simultaneously. SES has its own internal thresholds that govern whether your account continues to send at all. The major mailbox providers have independent thresholds that govern whether your messages arrive. Neither set waits for the other. Understanding exactly where each line sits, and what happens when you cross it, is now table-stakes infrastructure knowledge rather than an optional deliverability concern.
The Two Metrics SES Watches
Bounce rate
SES defines your bounce rate as the proportion of sent messages that result in a hard bounce, expressed as a percentage. Only hard bounces count against your reputation metric. Soft bounces, which are temporary failures such as a full mailbox or an overloaded receiving server, are retried by SES automatically and do not directly move the bounce-rate needle. SES calculates the rate against a representative sample of recent sending volume rather than a fixed time window. This means that if you send a large batch one week and only a handful of messages the next, a few bounces in the smaller batch can produce a disproportionately high rate. The dashboard and the corresponding CloudWatch metric are recalculated every time you send.
Complaint rate
Your complaint rate is the percentage of recipients who mark a message as spam, as reported via feedback loops that SES maintains with the major mailbox providers. SES receives these signals automatically; you do not need to register separately with each provider's feedback loop programme. The complaint rate is computed from the same representative sample logic as the bounce rate. One important nuance: Gmail does not participate in the traditional feedback loop model. Gmail complaint signals flow through Google Postmaster Tools, which in October 2025 moved to a new version that replaced the old High/Medium/Low domain reputation scores with a binary compliance status. Your true complaint exposure at Gmail is therefore visible only through Postmaster Tools, not through the SES console alone.
The Actual Numbers: A Reference Table
The table below maps the thresholds that matter most to SES senders in 2026. Read them together, not in isolation. SES's account-level limits are the floor; mailbox provider limits often bite first.
| Metric | SES recommended limit | SES review trigger | SES account pause | Gmail enforcement | Yahoo enforcement | Microsoft enforcement |
|---|---|---|---|---|---|---|
| Bounce rate | Below 5% | Exceeds maximum rate | Above 10% | No published hard limit; high rates damage domain reputation | Similar to Gmail | High bounce rates weigh against IP and domain reputation |
| Spam complaint rate | Below 0.10% | Exceeds maximum rate | Above 0.50% | Warning above 0.10%; delivery support withdrawn at 0.30% | Stay below 0.30%; mirrors Gmail guidance | Authentication-based rejection from May 2025; no separately published complaint-rate figure |
A few things this table cannot convey. First, the SES recommended figures are not aspirational targets; they are the operating zone in which SES considers your account healthy. AWS guidance explicitly recommends setting a CloudWatch alarm at a 5% bounce rate and a 0.10% complaint rate so that you receive an alert before SES acts, not after. Second, Gmail's 0.10% complaint figure is, in practice, the real ceiling for any sender who cares about inbox placement. The 0.30% figure is where Gmail stops offering any delivery mitigation, not where it starts penalising you. Third, Microsoft's May 2025 enforcement is triggered by authentication failure rather than a published complaint-rate figure, so shared-IP senders on SES can be caught by Microsoft rejection even when their own list hygiene is sound, if authentication alignment is imperfect.
What Happens at Each Stage
SES operates a graduated enforcement ladder. Understanding the rungs matters because each one has different remediation paths.
Healthy. Bounce rate below 5%, complaint rate below 0.10%. Your account sends normally with no restrictions.
Under review. A metric has exceeded the maximum rate. SES places the account under review. If the issue is not resolved by the end of the review period, SES may pause sending. The reputation dashboard shows an "Under review" status against the relevant metric.
Pending sending pause. The review period has elapsed without resolution. A member of the SES team must review the account manually before further action is taken. Sending may or may not continue during this window depending on account history and the severity of the issue.
Sending paused. SES has suspended the account's ability to send email entirely. You cannot send via SES until you submit a sending review request, demonstrate remediation, and receive approval. This is not an automated reinstatement. Note that in serious cases, or where the same issue has recurred, SES may skip straight to a sending pause without first placing the account under review.
At the mailbox provider level, failure modes arrive as SMTP error codes in your bounce notifications. Gmail issues temporary deferral codes during a transitional phase and permanent 550-class rejection codes once enforcement fully applies. Microsoft issues 550 5.7.515 for domains that fail its authentication requirements. These codes appear in the SES event destination payload and in raw bounce notification JSON from SNS, which makes automated triage straightforward if the pipeline is wired correctly.
Hard vs. Soft Bounces Inside SES
SES classifies bounces into two top-level types. A hard bounce, reported as bounceType: "Permanent" in the SNS notification payload, means permanent delivery failure: the address does not exist, the domain does not exist, or the receiving server has permanently rejected the message. These count against your bounce rate immediately and must be suppressed from all future sends without exception.
A soft bounce, reported as bounceType: "Transient", is a temporary failure. Common sub-types include MailboxFull, where the recipient's inbox is over quota, and General, where the receiving server was temporarily unavailable. SES retries soft bounces automatically and they do not count toward your headline bounce rate. However, a persistent pattern of soft bounces against the same address, particularly General sub-types with no resolution over time, is worth monitoring because it can indicate addresses that are gradually becoming invalid.
The most dangerous bounce category is the asynchronous, or out-of-band, hard bounce. This occurs when the receiving mail server initially accepts the message with a 250 OK response and then generates a bounce notification after the SMTP session has closed. From SES's perspective the message was delivered. The bounce arrives later as a separate notification event. If your pipeline only monitors delivery events and not subsequent bounce events, these asynchronous bounces accumulate silently against your reputation. They are particularly common at certain corporate mail gateways and at providers that perform deferred content filtering.
SES maintains a global suppression list populated by hard bounces from across all SES customers. If an address on this list is in your database and you attempt to send to it, SES accepts the API call but treats the message as a hard bounce internally, and that bounce counts against your rate. You can override global suppression behaviour using an account-level suppression list, which gives you per-address control and prevents global-list hits from silently eroding your metrics.
Complaint Rate Specifics
Every spam complaint processed through a feedback loop reduces your complaint rate headroom. SES collects feedback loop data from participating mailbox providers and surfaces it through the reputation dashboard and CloudWatch metrics. When a complaint is received, the recipient address is automatically added to your account-level suppression list if you have suppression enabled for complaints, preventing you from sending to that address again.
What the SES complaint metric does not capture is equally important. Because Gmail routes complaint signals through Postmaster Tools rather than a traditional feedback loop, Gmail spam reports are largely invisible in the SES console. A sender whose SES complaint rate reads 0.05% could simultaneously be registering a 0.25% complaint rate at Gmail, well inside the zone where inbox placement begins to deteriorate. Monitoring your SES complaint metric alone is therefore an incomplete picture for any programme that sends to Gmail addresses.
Bounce rate and complaint rate also compound each other's effect on sender reputation. A list that generates high bounces is by definition a poorly maintained list, and poorly maintained lists tend to include disengaged addresses whose owners are more likely to reach for the spam button. Letting bounce rate creep towards the 5% warning level is therefore a leading indicator that complaint rate will follow.
Wiring Up Real-Time Alerts
SES can deliver bounce and complaint notifications through three mechanisms: email feedback forwarding, SNS topic notifications configured per sending identity, and event destinations attached to a configuration set. For production systems, event destinations via configuration sets are the most capable option. They deliver structured JSON payloads covering bounces, complaints, deliveries, opens, clicks, and delivery delays, and they can fan out to SNS, Amazon Data Firehose, or CloudWatch simultaneously.
The recommended architecture for automated suppression is straightforward. First, create an SNS topic for bounce and complaint events and attach it as an event destination in your configuration set. Second, subscribe an SQS queue to the SNS topic so that notifications survive brief processing outages without being dropped. Third, deploy a Lambda function triggered by the SQS queue. The Lambda reads the notification payload, inspects the notificationType field, and for any Permanent bounce or any complaint calls the SES v2 API CreateSuppressedDestination to add the address to your account-level suppression list before any further messages can be dispatched to it. Suppression should happen within seconds of the notification arriving.
CloudWatch alarms provide the second layer of alerting. AWS guidance recommends setting a warning alarm at a 5% bounce rate threshold and a 0.10% complaint rate threshold so that a human or an automated runbook is notified before SES's own enforcement triggers. A second set of alarms at, say, 3% bounce rate and 0.08% complaint rate gives you an earlier signal to investigate list quality before the numbers become critical. Alarm actions can trigger SNS notifications to an on-call channel, or invoke a Lambda that automatically pauses a specific configuration set's sending until investigation is complete.
One important operational note: event destinations only fire for messages sent with a configuration set attached. If any part of your codebase sends via SES without specifying a configuration set, those sends produce no event data whatsoever. Auditing your sending code paths for missing configuration set references is a prerequisite for reliable monitoring.
Proactive List Hygiene
Technical alerting catches problems as they emerge, but proactive hygiene prevents them from forming in the first place.
Validate at the point of collection. Syntax validation and MX record lookup at sign-up eliminates a large proportion of typo addresses before they ever reach SES. For B2C programmes, a confirmed opt-in flow, where the address must respond to a confirmation message before receiving any other email, is the single most effective list-quality mechanism available. It simultaneously validates deliverability and establishes explicit consent.
Re-verify B2B lists regularly. Corporate email addresses churn at a significantly higher rate than consumer addresses. Role changes, company departures, and domain consolidations produce invalid addresses that accumulate silently in databases. A re-verification pass every three to six months, using an email verification service that checks SMTP reachability without sending live messages, prevents stale B2B data from generating hard bounces at scale.
Sunset disengaged subscribers. Recipients who have not opened or clicked in six to twelve months are not just a wasted sending cost; they are a complaint risk. Sunset policies that automatically suppress or remove non-engaged addresses reduce bounce rate exposure, because disengaged addresses are more likely to have lapsed, and complaint rate exposure, because recipients who have ignored email for months are more likely to report it as spam when they do notice it. A re-engagement campaign before sunsetting gives these addresses a last opportunity to confirm interest.
Separate transactional and marketing traffic. Using distinct configuration sets, and ideally distinct sending domains, for transactional and marketing email means that a spike in complaint rate from a marketing campaign cannot contaminate the reputation of your transactional stream. Account-level metrics in SES aggregate across all sending, so a single configuration set provides no isolation between traffic types.
Where SES Monitor Fits In
Amazon's own reputation dashboard shows your current bounce and complaint rates, and CloudWatch can raise alarms against those metrics. What neither tool provides out of the box is continuous, cross-configuration-set visibility with pre-threshold alerting calibrated to the provider-level danger zones described above, not just to SES's own account-pause triggers.
SES Monitor sits between your sending activity and an account-level problem. It aggregates bounce and complaint data across all your configuration sets and sending identities, presents trend lines that make rate acceleration visible before the numbers become critical, and fires alerts calibrated to the thresholds that actually matter, including the 0.10% complaint warning level and the 5% bounce warning level. Per-configuration-set breakdowns show immediately whether a problem is isolated to one sending stream or systemic across the account. Webhook-to-suppression integration closes the loop between a detected bounce and removal from your active sending list without requiring you to build and maintain a bespoke Lambda pipeline.
The practical value lies in the gap between "SES has not yet acted" and "a mailbox provider is already penalising you." That gap can be days or weeks at modest sending volumes, and it is precisely the window in which reactive monitoring fails and continuous monitoring succeeds.
Aim for Half the Distance to Every Threshold
The thresholds published by SES and by mailbox providers are limits, not targets. Operating at 4.9% bounce rate is not good list hygiene that happens to avoid an account pause; it is a system under stress with almost no margin. The practical operating goal for any serious SES sender is to run at least half the distance from zero to each relevant threshold: hard bounce rate below 2%, spam complaint rate below 0.05%, with any upward trend treated as a signal worth investigating immediately rather than watching to see whether it stabilises.
Email reputation, once damaged, recovers slowly. A domain that spends a week above Gmail's 0.30% complaint threshold can remain outside normal delivery support for an extended period after the rate drops back below the line. An SES account that enters the sending-paused state requires a manual review process that takes days and offers no guarantee of reinstatement without remediation evidence. The cost of prevention is orders of magnitude lower than the cost of recovery. A well-wired SNS pipeline, calibrated CloudWatch alarms, a current suppression list, and a monitoring layer that alerts before thresholds are reached are not optional infrastructure. They are what separates programmes that scale reliably from those that periodically stop sending entirely.