Amazon SES emails suddenly going to spam: a troubleshooting checklist

If an Amazon SES account that was previously sending well starts landing in spam, the sandbox and initial DKIM setup are almost never the cause - those problems show up immediately, not after a period of healthy sending. This checklist is for diagnosing a shift that happened after SES was already working.

Check the SES reputation dashboard first

SES exposes account-level reputation metrics directly in the console - bounce rate and complaint rate specifically. AWS can place an account under review or restrict sending if bounce rate climbs past roughly 5% or complaint rate past roughly 0.1% sustained over a rolling window. If either metric has climbed, that's very likely the proximate cause, and it points to the list or content, not the infrastructure.

Confirm authentication hasn't quietly broken

• Easy DKIM rotates its keys periodically - confirm the current DKIM record is still correctly published in DNS, since a DNS change elsewhere (a migration, a new DNS provider) can drop a TXT record without anyone noticing until mail starts failing DKIM.
• Custom MAIL FROM domain (used for DMARC alignment) needs its own MX and SPF records - confirm these are still intact, especially if DNS has changed hands or been migrated recently.

Check for engagement decline, not just technical failure

A list that was engaged when the account was new naturally decays over time - open and click rates drop as some recipients lose interest, change addresses, or stop checking the inbox you're sending to. Sending the same volume to a now-less-engaged list produces exactly the complaint and low-engagement pattern that drops reputation, even with zero technical changes on the SES side.

Review configuration sets and event destinations

If configuration sets aren't correctly wired to log bounces and complaints (via SNS notifications), you can be flying blind on exactly the metrics that would have warned you earlier - confirm event destinations are active and actually being monitored, not just configured once and forgotten.

Dedicated IP warm-up, if recently added

Switching from SES's shared IP pool to a dedicated IP resets sending history for that specific IP - a dedicated IP needs its own gradual warm-up exactly like a new domain would, and sending full volume on a freshly provisioned dedicated IP is a common, specific cause of a sudden spam-folder shift right after making that switch.

Sending rate limits and configuration sets

Confirm sending rate limits in configuration sets still match actual sending patterns - a rate limit set conservatively when the account was small, left unchanged as volume grew, can create burst patterns right at the limit's edge that read as inconsistent sending to the receiving side.

What not to do

• Don't re-check the sandbox exit or original DKIM setup as a first step if the account has been sending successfully for months - look at what changed recently instead.
• Don't add a dedicated IP as a "fix" for a spam-folder problem without separately warming it - an unwarmed dedicated IP sending at established volume is often worse than staying on the shared pool.
• Don't ignore the SES reputation dashboard in favor of guessing at content issues - the dashboard's bounce and complaint metrics are the most direct signal available and should be the first thing checked.

A diagnostic order for an account that was previously healthy

A minimal SNS notification check

aws ses describe-configuration-set \
  --configuration-set-name your-set-name \
  --configuration-set-attribute-names eventDestinations

Running this (or checking the equivalent in the SES console) confirms whether bounce and complaint events are actually being published somewhere you're monitoring - a configuration set with no active event destination means you have no early warning at all, and the first signal of a problem becomes AWS placing the account under review.

Email infrastructure issues worth a final check

Beyond reputation and authentication, a handful of infrastructure-level issues can independently cause an SES account to underperform: an outdated or incorrectly scoped IAM policy restricting what the sending application can actually do, a Lambda or application-side retry loop accidentally resending the same message multiple times (inflating both volume and apparent complaint rate per unique recipient), or a region mismatch between where the SES identity is verified and where the application is actually sending from. These are rarer than a reputation or authentication cause, but worth ruling out specifically if the dashboard and DNS checks above come back clean and the spam-folder problem persists.

MailPilot tracks per-mailbox reputation and real inbox placement daily independent of what SES's own dashboard reports, which catches an engagement-driven decline even in the window before SES's own metrics cross a restriction threshold.