Why Bounce Rate Is Your Sending Reputation's Weakest Link
Of all the metrics that govern your Amazon SES sending reputation, bounce rate is the one most capable of ending your sending overnight. AWS is explicit: a bounce rate above 5% triggers a warning review, and once you cross 10%, SES can pause your account's ability to send email entirely. Complaint rate thresholds are tighter still, with a warning at 0.1% and a potential pause at 0.5%. These are rolling metrics, which means a single poorly managed import or re-engagement campaign can push an account over the threshold before you have time to react.
Historically, the only way to manage this risk was reactive. You would send to a list, receive bounce notifications via Amazon SNS or event publishing, suppress the failing addresses, and hope the damage to your reputation was limited. List hygiene meant cleaning up after the fact. With the launch of Amazon SES email validation in December 2025, AWS introduced a meaningful shift in that dynamic: the ability to identify and suppress invalid addresses before a message is ever sent.
What Amazon SES Email Validation Is
Announced on 18 December 2025, Amazon SES email validation is a native capability within SES that helps senders reduce bounce rates and protect their sending reputation by validating email addresses before sending. There are two distinct modes.
The first is the on-demand Email Validation API. This allows you to validate individual addresses at any point in your workflow by calling the GetEmailAddressInsights operation in the SES API v2. It returns a structured set of confidence verdicts about the address, giving you the information to decide whether to send, flag, or suppress it.
The second is Auto Validation. When enabled, SES automatically reviews every outbound email address before delivery, silently suppressing any message whose recipient address fails to meet the confidence threshold you have configured. Crucially, Auto Validation requires no code changes to your existing sending workflows. It operates as a layer beneath your application, intercepting sends that would otherwise become hard bounces.
Both modes are available in all AWS Regions where SES is available, and both can be configured either at the account level or scoped to individual configuration sets.
What the Validation Checks
The SES email validation API performs several distinct evaluations on each address, each returning a confidence verdict of HIGH, MEDIUM, or LOW.
Syntax validation (HasValidSyntax)
This checks that the email address follows proper RFC standards and contains valid characters in the correct format. It is the most basic layer but an important one: a malformed address will always bounce, so there is no reason to attempt delivery.
DNS record verification (HasValidDnsRecords)
This checks that the domain exists, has valid DNS records, and is configured to receive email. A domain with no MX records cannot accept mail, so a HIGH confidence verdict here confirms the domain is live and reachable.
Mailbox existence (MailboxExists)
SES checks whether the mailbox exists and can receive messages without actually sending an email. This is a server-level probe that goes beyond DNS and attempts to confirm that the specific local part of the address resolves to a real mailbox.
Disposable and temporary address detection (IsDisposable)
The API flags addresses associated with disposable or temporary email services. These addresses are typically short-lived and, while they may not bounce immediately, they inflate your list with low-quality contacts that damage engagement metrics over time.
Random string detection (IsRandomInput)
This evaluation checks whether the address appears to be randomly generated, a common pattern in bot signups and form spam.
Role address identification (IsRoleAddress)
The API identifies role-based addresses such as admin@, support@, or info@. These are flagged because they tend to have lower engagement rates and are more likely to trigger spam complaints when used in marketing sends.
The overall IsValid field, returned inside the MailboxValidation response object, aggregates these individual checks into a single delivery-likelihood verdict: HIGH for strong delivery likelihood, MEDIUM for moderate, and LOW for poor. It is this overall verdict that Auto Validation uses when deciding whether to suppress a send.
How to Enable Auto Validation
Via the AWS Console
To enable Auto Validation at account level, sign in to the AWS Management Console, open the Amazon SES console, and navigate to Auto Validation under Email Validation in the left navigation pane. Select the Enabled checkbox, choose your threshold (SES managed, High, or Medium), and save your changes. Configuration-set level overrides follow the same pattern: open the configuration set, select the Suppression options tab, and enable Auto Validation with your chosen threshold for that set. If you do not override a configuration set's settings, it inherits the account-level configuration.
Via the API at Account Level (Python)
Use the PutAccountSuppressionAttributes operation with the ValidationAttributes field. The following Python example using Boto3 enables Auto Validation at account level with a HIGH threshold:
import boto3
client = boto3.client('sesv2', region_name='eu-west-1')
client.put_account_suppression_attributes(
SuppressedReasons=['BOUNCE', 'COMPLAINT'],
ValidationAttributes={
'ConditionThreshold': {
'Enabled': True,
'OverallConfidenceThreshold': {
'ConfidenceVerdictThreshold': 'HIGH'
}
}
}
)
Via the API at Configuration-Set Level (Node.js)
To scope validation to a specific configuration set, use PutConfigurationSetSuppressionOptions with a ValidationOptions field. The following Node.js example uses the AWS SDK v3:
import { SESv2Client, PutConfigurationSetSuppressionOptionsCommand } from '@aws-sdk/client-sesv2';
const client = new SESv2Client({ region: 'eu-west-1' });
await client.send(new PutConfigurationSetSuppressionOptionsCommand({
ConfigurationSetName: 'my-transactional-set',
SuppressedReasons: ['BOUNCE', 'COMPLAINT'],
ValidationOptions: {
ConditionThreshold: {
Enabled: true,
OverallConfidenceThreshold: {
ConfidenceVerdictThreshold: 'MEDIUM'
}
}
}
}));
The threshold field in the SDK is ConfidenceVerdictThreshold. The three valid values are HIGH, MEDIUM, and MANAGED, where MANAGED lets SES determine the threshold automatically.
You can also configure event destinations to track which outbound emails were suppressed by Auto Validation, giving you visibility into how often the feature is intercepting sends.
Using the On-Demand Validation API
The GetEmailAddressInsights endpoint accepts a POST request to /v2/email/email-address-insights/ with a JSON body containing a single EmailAddress string. The IAM policy for the calling identity must include the ses:GetEmailAddressInsights permission and iam:CreateServiceLinkedRole to enable CloudWatch metrics publishing for validation activity.
The response returns a MailboxValidation object containing an IsValid field with an overall confidence verdict of HIGH, MEDIUM, or LOW, plus an Evaluations object with individual verdicts for each check: HasValidSyntax, HasValidDnsRecords, MailboxExists, IsDisposable, IsRandomInput, and IsRoleAddress.
The right moments to call this API are at user registration or sign-up forms (validate before the address is stored), during bulk list imports (scan every address before it enters your sending queue), and ahead of re-engagement campaigns targeting contacts who have not engaged for an extended period. Validating at the point of collection is substantially cheaper than managing the downstream bounce events that result from skipping validation.
What Email Validation Does Not Catch
SES email validation is a significant improvement in pre-send hygiene, but it is not a complete solution. Understanding its limits is essential for building a durable reputation management strategy.
Role addresses such as sales@ or noreply@ are flagged with a confidence signal, but they are not automatically suppressed unless your threshold is set to exclude them. Whether to suppress them depends on your use case; a flagged role address may still be a legitimate recipient for a transactional message.
Spam traps are not detectable by any pre-send validation. A spam trap is a valid address on a live domain with functioning MX records. It will pass every DNS and syntax check and return a positive mailbox existence result. The only reliable way to avoid spam traps is through sound list acquisition practices and prompt processing of hard bounces.
Temporarily inactive mailboxes present a similar problem. An address may be perfectly valid today, pass all checks with a HIGH confidence verdict, and generate a hard bounce months later when the account is closed or abandoned. Validation is a snapshot in time, not a permanent guarantee of deliverability.
Some domains and providers also deliberately return positive SMTP responses during mailbox probing to defeat bulk verification tools, only to bounce the message after delivery is attempted. These addresses will appear valid to any validation system, including SES.
The practical implication is straightforward: validation removes the obviously invalid addresses, but a meaningful proportion of hard bounces will still originate from addresses that passed validation. You need a second layer of defence.
Bounce Rate Thresholds and the Risk of a Single Bad Import
It is worth being precise about the SES bounce thresholds, because many senders underestimate how quickly a single event can move the needle. AWS recommends maintaining a bounce rate under 5% and a complaint rate under 0.1%. If the bounce rate exceeds 10%, SES may pause your account's ability to send email. The complaint rate threshold for a pause is 0.5%.
These thresholds apply to your sending identity as a whole, not to individual campaigns. If you have been sending clean traffic at low volume and then import a large stale list, the spike in bounces from that single batch is measured against your recent sending history. If the import is large relative to your usual volume, you can breach the 10% threshold on a single send. Validation reduces this risk materially, but it does not eliminate it entirely, for the reasons described above.
High bounce rates are also used by mailbox providers such as Gmail and Microsoft to evaluate sender reputation independently of SES. A rate above 5 to 10% signals poor list hygiene to those providers, triggering inbox filtering, rate limiting, or outright rejection well before SES itself takes enforcement action.
Layering Validation with Real-Time Bounce Monitoring
Validation and monitoring are complementary, not interchangeable. Validation prevents sends to addresses that are demonstrably invalid before the fact. Monitoring catches the addresses that validation could not screen out: the spam traps, the recently closed mailboxes, the domains that misrepresent availability during SMTP probing.
AWS recommends using Amazon SNS notifications or SES event publishing to receive bounce and complaint events in real time. When a hard bounce event arrives, the failing address must be added to your suppression list immediately and must never be sent to again. Soft bounces warrant monitoring across multiple sends before suppression, but repeated soft bounces from the same address are a reliable indicator that the mailbox is unavailable.
CloudWatch alarms are the native mechanism for proactive alerting. AWS recommends setting a CloudWatch alarm at the 5% bounce rate threshold so you are notified before the account comes under formal review, and a second alarm at 3% gives you earlier warning still. For complaint rate, the recommended alarm threshold is 0.1%, well ahead of the 0.5% pause threshold.
The SES reputation dashboard in the console shows bounce and complaint metrics, but it does not send proactive alerts. You have to build the alerting layer yourself using CloudWatch, or use a purpose-built monitoring tool that surfaces these signals automatically.
How SES Monitor Complements Email Validation
SES email validation addresses the front end of the problem: stopping invalid addresses from reaching the send queue. SES Monitor addresses the back end: tracking what happens after messages are sent, surfacing trends before they become enforcement actions, and giving you a consolidated view of your sending reputation across all configuration sets and identities.
Where validation tells you an address should not receive mail, SES Monitor tells you whether your overall programme is healthy. Bounce and complaint rates can trend upward gradually, driven by list ageing, changing recipient behaviour, or declining acquisition quality, none of which would be caught by a single validation check. A dashboard that shows week-on-week changes in bounce rate, complaint rate, and delivery metrics makes these trends visible early. Alerts that fire before you breach the 5% warning threshold give you time to investigate and act without the pressure of an imminent account review.
The combination is more robust than either approach alone. Enable Auto Validation to eliminate the most obviously invalid addresses at send time. Validate on collection to stop bad addresses entering your list in the first place. Then use ongoing reputation monitoring to catch the residual risk that no validation system can fully remove.
Quick-Reference Checklist
Enable Auto Validation. Turn it on at account level as a baseline. Set the threshold to SES managed if you are unsure where to start, then tighten to HIGH or MEDIUM once you have reviewed the suppression data from your event destinations.
Validate at sign-up. Call GetEmailAddressInsights on every address collected through registration forms or import flows before storing it. Reject or flag LOW confidence addresses at the point of collection.
Process hard bounces immediately. Ensure your SNS or event publishing pipeline adds hard-bouncing addresses to your suppression list without delay. Never retry a hard-bounced address.
Monitor complaint rate closely. Complaint rate is harder to recover from than bounce rate. Set a CloudWatch alarm at 0.1% and treat any upward trend as urgent.
Review your reputation dashboard weekly. Trends matter more than snapshots. A bounce rate moving from 1% to 2% to 3% over three weeks is a warning sign even though each individual figure is below the threshold. Catch the trend, not just the breach.
Conclusion
Amazon SES email validation, launched in December 2025, is the most significant native list hygiene feature SES has added to date. The combination of on-demand API validation and zero-code-change Auto Validation makes it straightforward to eliminate clearly invalid addresses before they generate a bounce event. For developers, the configuration is simple: a single call to PutAccountSuppressionAttributes enables account-wide protection, and GetEmailAddressInsights integrates naturally into any registration or import flow.
Validation is a filter, not a guarantee. Spam traps, aged lists, and temporarily unavailable mailboxes will continue to produce bounces that no pre-send check can prevent. The senders who consistently stay well below SES's thresholds treat validation and real-time bounce monitoring as two parts of a single system, not as alternatives to each other. Enable Auto Validation today, instrument your bounce and complaint event pipeline, set your CloudWatch alarms at the 5% and 3% bounce rate marks and at 0.1% for complaint rate, and monitor your reputation trends continuously. That combination is what separates a healthy sending programme from an account review.