Amazon SES Deliverability: Stay Inside the Thresholds

Amazon SES publishes the exact numbers at which it stops trusting your account, which makes SES deliverability more tractable than most platforms. A bounce rate of 5 percent puts the account under review automatically. A complaint rate of 0.1 percent does the same. Those consequences land at account level, so one careless import can suspend every program running on the account. The work is to hold both numbers well clear of the line, to know which lever moves which number, and to have a named person watching before AWS opens the case on your behalf.

Know the published thresholds exactly

The Amazon SES reputation metrics messages documentation states the numbers directly. For bounces, AWS advises maintaining a rate below 5 percent, automatically places an account under review at 5 percent or greater, and may pause the account's ability to send at 10 percent or greater. For complaints, AWS advises staying below 0.1 percent, places the account under review at 0.1 percent or greater, and may pause sending at 0.5 percent or greater.

The documentation also describes the review mechanics. At the end of a review period, if the bounce rate remains above 10 percent or the complaint rate remains above 0.5 percent, AWS may pause sending until the issue is resolved. If you implement changes and describe them in the support case AWS opened, and AWS agrees the changes will reduce the rate, AWS adjusts its calculation to consider only the bounces or complaints received after the changes were implemented.

That last clause is operationally important. Documenting a fix and its date gives you a concrete remedy. Fixing quietly and hoping the average recovers does not.

Our view: treat 2 percent bounces and 0.05 percent complaints as your internal ceiling, not the published thresholds. By the time a number touches the AWS line, the campaign that caused it has been running for days and the average is slow to recover.

Understand how the rate is actually calculated

AWS states that it calculates the complaint rate over a representative volume of email, that the representative volume differs for each account, and that it changes as the account's sending patterns change. The same representative-volume approach applies to bounces. Complaints generated by mail sent to the SES mailbox simulator are excluded from the calculation.

The practical consequence catches low-volume senders out. A rate is a ratio, and at small volumes a handful of bad addresses produces a percentage that a high-volume account would absorb without noticing. An account sending 2,000 messages a month is more exposed to a single bad import than one sending two million, which is the opposite of the intuition most teams bring.

New programs should therefore start slower and verify harder than the volume alone suggests. The protection against a threshold breach at low volume is list quality on the way in, because there is no denominator large enough to dilute the mistake.

Isolate programs with configuration sets before you need to

Configuration sets group sending rules and publish events, and SES supports viewing reputation metrics at configuration-set level. Set them up per sending program before the first production send.

Account-level metrics tell you that something is wrong. Configuration-set metrics tell you which program caused it, which is the difference between pausing one campaign and pausing everything while you investigate. Retrofitting the split during an active review is not possible, because the historical events were never tagged.

SES also supports pausing sending for an individual configuration set. That capability only helps if the programs were separated in advance, which is why this belongs in the setup checklist rather than the incident runbook.

Separate transactional mail from outbound prospecting at minimum. Those two streams have entirely different bounce and complaint profiles, and mixing them into one undifferentiated account metric removes your ability to diagnose either.

Build the alarm and name the responder

SES publishes reputation metrics through its reputation dashboard, and nobody is watching them for you.

Set a CloudWatch alarm on the account bounce rate and the account complaint rate, with thresholds below the AWS review lines so the alert arrives while you still have room. Route the alarm to a person, not to a shared inbox, and write down what that person is authorised to do when it fires.

The authority matters more than the alert. An alarm that reaches someone who must escalate before pausing a campaign will produce a delay measured in hours, during which the rate keeps climbing. Give the responder standing permission to pause a configuration set and reconcile afterwards.

1. Set alarms at your internal ceiling, below the AWS thresholds.
2. Name a primary and a secondary responder with the authority to pause.
3. Document the pause procedure, including which configuration set maps to which program.
4. Record every fix with a date, so a support case can reference it.
5. Review the metrics on a fixed weekly cadence rather than only on alert.

Move the bounce rate with list quality, not with sending changes

A bounce rate is a list problem presenting as a sending problem, and adjusting send volume or timing will not fix it.

Verify addresses before they reach SES, not after. Hard bounces are the category AWS counts against you, and a hard bounce means the address did not exist at the moment of sending, which verification would have caught. Our email verification API guide covers the policy layer that decides which records are permitted to send.

Age is the second driver. A list built eight months ago has decayed through job changes and domain consolidation, and re-verifying before a re-engagement send is cheaper than the account review it prevents.

Source quality is the third. A list acquired from a broker carries bounce characteristics you cannot predict and did not choose, and it will reach the threshold faster than any other input. This is the input worth refusing outright.

Move the complaint rate with targeting and relevance

Complaints are a different problem with a different fix. A complaint means the message arrived, the recipient read enough to react, and the reaction was to mark it as spam. Verification does nothing for this.

Three things move the number. Targeting precision reduces the share of recipients for whom the message is irrelevant by construction. Visible, working opt-out handling gives the annoyed recipient an alternative to the spam button. Sending frequency against the same contact changes how quickly mild irritation becomes a complaint.

The 0.1 percent review threshold is tighter than it sounds. One complaint per thousand delivered messages reaches it, which means a 10,000 message campaign has ten complaints of headroom before the account goes under review.

Warm dedicated IPs on a written schedule

If the account uses dedicated IPs, the warm-up is a deliverability control rather than a formality. Amazon's dedicated IP warm-up documentation states that establishing a positive reputation takes around two weeks with some email providers and can take up to six weeks with others, and advises sending to your most active recipients during the ramp while watching bounce messages and reducing volume if blocking or throttling notifications appear.

SES enables automatic warm-up for standard dedicated IPs by default, distributing sending between your dedicated addresses and the shared pool while gradually increasing the dedicated share. The documentation notes that disabling the automatic feature makes you responsible for warming the addresses yourself.

Decide deliberately which of those you are running, and record the decision. An IP that gets full production volume on day one performs worse than the shared pool would have, and the reputation damage takes longer to repair than the ramp would have taken.

Run the account like infrastructure you own

SES deliverability is a monitoring and list-quality discipline wrapped around a platform that publishes its rules clearly. Hold an internal ceiling below the AWS thresholds, isolate programs with configuration sets so a single bad import cannot take down the account, route alarms to a person with authority to act, and fix bounce problems at the list rather than in the sending schedule.

LeadHaste orchestrates 35+ tools for client programs and builds the sending layer so the client owns the domains, the warm-up history and the evidence. LeadHaste can set up the configuration-set isolation, the reputation alarms and the verification policy that keeps an SES account clear of a review. Book your free ICP and campaign-fit discovery call →