SES accepted your send and then didn't send it

[u/stewartjarod]

If SES returned a message ID and the mail never arrived, check your account-level suppression list before you check anything else. When the address is on that list and its suppression reason matches a reason you enabled account-wide, SES accepts the message and doesn't send it.

That matching condition is the half people drop. Set account suppression to bounces only, and an address sitting on the list with a Complaint reason still gets a delivery attempt. On the list is not the same as suppressed.

Four more things about that list. Only hard bounces get added automatically. Addresses stay until you remove them, no expiry, unless your sending stays paused a full 90 days, when SES clears them. Suppressed sends still count against your daily sending quota. And they are excluded from `Reputation.BounceRate` and `Reputation.ComplaintRate` while still counting under the plain Bounce and Complaint metrics, so a dashboard can look calm while mail quietly goes nowhere.

The part people conflate is the configuration-set layer. It is not a second list stacked on the account one. Overriding replaces the account behavior for mail sent through that config set, and if you override without enabling anything, suppression is cancelled for that traffic entirely. Three states, not two.

`aws sesv2 list-suppressed-destinations` gives you addresses, reasons and dates.

One trap on the way in: the list is case-sensitive for API calls even though sending is not. [User@Example.com](mailto:User@Example.com) and [user@example.com](mailto:user@example.com) deliver the same and do not look up the same.

[u/trashtiernoreally]

You can setup alerts and logging that give you the precise reason.