Amazon SES Bounce & Complaint Handling with Configuration Sets for Cold Email (2026)

Owning Amazon SES is only half the job. The other half is catching bounces and complaints before they quietly push your account into review — or pause sending entirely. Most teams that set up SES for cold email stop at domain verification and SMTP credentials. Configuration sets, event destinations, and suppression options are what turn SES from a cheap pipe into infrastructure you can operate.

This guide walks through bounce vs complaint signals, why they matter for cold outreach, how to create configuration sets with SNS / CloudWatch / Firehose destinations, how account-level and config-set suppression differ, and what to do when rates spike — including how this fits BYO AWS SES on LeadSnipper.

Why bounces and complaints kill SES reputation

SES does not grade you on open rates. It grades you on whether recipients and mailbox providers reject or reject-as-spam what you send. High bounce volume usually means bad data, stale lists, or aggressive scraping. High complaint volume usually means relevance problems, weak opt-out paths, or volume that outran trust. Either signal can put the whole account under review — not just one campaign. That is the uncomfortable part of shared AWS accounts: one careless upload can freeze password resets and invoices alongside your outbound sequences.

AWS publishes clear floors: aim for bounce under roughly 2% and complaint under roughly 0.1%. Review often starts near 5% bounce / 0.1% complaint; pause risk climbs near 10% bounce / 0.5% complaint. Those are account-level reputation metrics computed over a representative volume of mail, not a cute daily average you can ignore after one good week.

Cold email teams feel this faster than newsletter senders because list quality varies and messages are unsolicited. That is why list verification and bounce/complaint plumbing belong in the same operating checklist as DNS and email warmup.

Hard bounce vs soft bounce vs complaint feedback

A hard bounce is a permanent rejection — address does not exist, domain invalid, mailbox deleted. Treat it as a terminal signal: suppress immediately and never retry. A soft bounce is temporary — mailbox full, greylisting, transient outage. SES may retry for a period; only after delivery ultimately fails does the event surface as a bounce worth suppressing. Do not invent your own retry loops on top of SES for addresses that already hard-bounced.

A complaint means the message was accepted by the recipient's server, then marked as spam (via a feedback loop SES receives). Complaints are rarer than bounces and more expensive: they tell mailbox providers your mail is unwanted. Easy unsubscribe (including List-Unsubscribe / one-click) reduces complaint pressure; suppression after a complaint is non-negotiable.

In SES event publishing, matching types include BOUNCE and COMPLAINT among others. Wire both. Delivery and reject events are useful extras; opens/clicks are optional and often noisy for cold outbound.

Note the nuance in SES docs: bounce events cover hard bounces, and soft bounces appear when SES eventually gives up after retries. Complaint events only arrive for providers that share feedback with SES. That is why a "low complaint rate" in SES is not proof Gmail loves you — you still need Postmaster spam rate and honest reply quality as parallel checks.

What configuration sets are for

A configuration set is a named bundle of rules you attach to sends: event destinations, IP pool selection (if you use dedicated IPs), and suppression preferences. Without one, you are flying on identity-level defaults and hope. With one, every cold campaign can publish the same bounce/complaint stream to the same SNS topic and CloudWatch alarms.

For agencies and multi-product companies, configuration sets are also the clean way to isolate cold vs transactional traffic. Password resets should not share the same reputation story as a 3-step outbound sequence — and when something spikes, you want to know which stream caused it.

Create a configuration set (console or CLI shape)

In the SES console (same region as your verified identities): Configuration → Configuration sets → Create. Name it something obvious, e.g. cold-outbound-2026. Leave IP pool blank unless you already lease dedicated IPs and want outbound on a separate pool from receipts or product mail.

Then add at least one event destination. AWS documents the SNS path clearly in Set up an Amazon SNS event destination and in the Messaging Blog walkthrough Set up notifications for bounces and complaints. Practical pattern for cold email:

• SNS — near-real-time bounce/complaint payloads to email, Slack via Lambda, or your suppression worker.
• CloudWatch — dimensions for campaign or domain so you can alarm on rate, not just raw counts.
• Kinesis Data Firehose — archive events to S3 for weekly hygiene audits and client reporting.

Enable the destination, select at minimum hard bounces and complaints, grant SES permission to publish to the SNS topic, and subscribe an endpoint you actually watch. A topic nobody reads is decoration.

For SNS access policies, follow the console validation step carefully — SES must be allowed to sns:Publish to that topic from your configuration set. If validation fails, events will not flow even though the destination looks "enabled." For CloudWatch destinations, pick dimensions you can filter later (for example message tags for campaign_id or client_id) so one noisy client does not hide inside a single account-wide graph.

Account-level vs configuration-set suppression

SES maintains an account-level suppression list. When enabled for bounce and/or complaint reasons, SES automatically adds addresses and refuses future sends to them — protecting you from yourself. For cold email, turning this off is almost never wise.

Configuration sets can override those preferences. The API operation is PutConfigurationSetSuppressionOptions. You can keep account defaults, override with config-set-level reasons (BOUNCE, COMPLAINT), or — dangerously — override in a way that disables suppression for that stream. AWS documents the override combinations in configuration set-level suppression.

Recommended default for outbound: account-level BOUNCE + COMPLAINT on, and either no override on the cold config set, or an explicit override that still enables both reasons. Use overrides to tighten a risky client stream — not to "keep retrying" dead addresses.

You must pass the configuration set on every send

Creating the set does nothing by itself. API / SDK sends need ConfigurationSetName. Raw SMTP / header-based paths need X-SES-CONFIGURATION-SET: cold-outbound-2026. You can also attach a default configuration set to a verified identity in the console so forgotten headers still inherit the right rules — useful when multiple tools send through the same domain.

After wiring, send a deliberate hard-bounce test to a known-invalid address on a throwaway subdomain (never on your primary brand domain at volume) and confirm the SNS notification arrives. If it does not, fix destination IAM / topic policy before you scale.

Isolate cold vs transactional; pause and reputation alarms

Run product and receipt mail on a separate configuration set (and ideally separate subdomain). When outbound bounce rate climbs, you can pause cold sequences without guessing whether password resets caused the spike. Dedicated IP pools amplify this isolation if your volume justifies the SES pricing for leased IPs.

Mirror AWS reputation metrics into CloudWatch alarms with headroom — for example notify well below the review floors so a human can halt campaigns the same day. Pair SES metrics with Google Postmaster Tools spam rate; SES pause risk and Gmail spam rate are related but not the same dashboard.

What to do when bounce or complaint rates spike

1. Pause outbound immediately on the affected domains / sequences. Continuing to "push through" is how reviews become pauses.
2. Read the events — hard bounce clusters by domain or list source usually mean a bad import; complaint clusters by template or offer usually mean messaging or targeting failure.
3. Suppress globally in your CRM / sequencer, not only in SES. SES account suppression stops retries through SES; your tool must stop scheduling follow-ups too.
4. Re-verify the list before restarting. See the list cleaning guide — unverified uploads are the classic bounce disaster.
5. Restart slowly on warmed domains with tighter daily caps. Check your deliverability checklist and the broader pre-send deliverability checklist before volume returns.

If SES already paused the account, follow AWS's review process honestly: root cause, remediation, and evidence you will not repeat the pattern. Vague "we fixed lists" replies waste weeks.

While paused, use the downtime to confirm SPF / DKIM / DMARC still align, that List-Unsubscribe works, and that your sequencer cannot re-import suppressed addresses from a CSV. Configuration sets and SNS give you detection; list hygiene and send discipline are still what lower the underlying rates. Treat a spike as an operations incident with an owner, a timeline, and a written restart plan — not as a quiet dashboard annoyance.

How this fits LeadSnipper BYO SES

LeadSnipper is built for teams that want cold email software on infrastructure they own. With BYO SES you keep the AWS account, reputation, and configuration sets — while LeadSnipper handles sequences, warmup, and campaign ops. That split matters: shared-pool tools can hide bounce plumbing; on SES you either wire it or inherit the risk.

Compared with tools that rent shared sending (see LeadSnipper vs Instantly), BYO SES plus configuration sets gives you explicit bounce/complaint destinations and account-level suppression you can audit. Pricing stays predictable because you pay SES at ~$0.10 per 1,000 emails plus the platform plan — not mystery shared-IP fees when someone else burns reputation.

Soft recommendation: finish SES identity + config-set + SNS alarms first, then connect the account to LeadSnipper and keep outbound on the cold configuration set. Warmup and verified lists still matter more than any dashboard widget.

If you are migrating from a shared-infrastructure tool, export suppressions and bounce history before you flip DNS. Starting "clean" on SES with a polluted CRM is how bounce rates spike in week one. Bring your suppression list, your config set name, and your CloudWatch alarms into the new stack the same day the first campaign goes live.

Bottom line

Bounce and complaint handling is not optional polish on Amazon SES — it is how you keep the right to send. Create a cold-outbound configuration set, publish BOUNCE and COMPLAINT to SNS and CloudWatch, keep suppression on for both reasons, pass ConfigurationSetName or X-SES-CONFIGURATION-SET on every message, isolate transactional mail, and pause yourself before AWS pauses you.

Ready to run cold sequences on SES you control? Review LeadSnipper plans or start free and wire the next domain with bounce plumbing you can actually see.