SES Returned 200. The Email Never Arrived.

Last week my signup flow worked perfectly and the verification email never arrived.

Form validated. User row written. SES accepted the send — 200 OK. Every check I had said "sent."

But the inbox was empty. Not in spam. Not delayed. Just gone.

I spent a week trusting the API response before I admitted the API was telling the truth about the wrong thing.

200 means accepted, not delivered

This is the nastiest lie in email infrastructure, and I believed it for a week.

When SES returns 200, it means exactly one thing: SES accepted your message into its pipeline. Between acceptance and the inbox, your message passes through a gauntlet that can kill it without a single error surfacing back to you:

• Suppression lists — SES silently drops sends. No bounce, no error. Just silence.
• Reputation filters — mailbox providers throttle or spam-folder while your 200 stays a 200.
• Greylisting that never retries — messages die in the gap between "accepted" and "attempted."
• Configuration sets that swallow events — failures happen in a void if events go nowhere you read.

My code reviewed the pattern. Nobody reviewed the last mile.

The debugging sequence

Dead ends included, because the dead ends are the lesson.

Checked the obvious first — nothing. Trusted the logs — they all said "sent." That's where most people stop.

The breakthrough: check the suppression list first.

aws sesv2 get-suppressed-destination --email-address [e-mail] --region us-east-1

If the address is there, SES will never deliver to it, and nothing tells you. Then seed real inboxes (Gmail, Yahoo, Outlook — real accounts, real mail). Then trace backward from the inbox, not forward from the API.

The stranger test

I test my own product like a stranger now. The framework:

1. Use a fresh identity — your test fixtures carry your assumptions
2. Watch the real outcome, not the system's report of it
3. Set a timebox — if it doesn't materialize, investigate the gap
4. Trace backward from the user's eyes
5. Write down what you assumed

If your monitoring can't distinguish "sent" from "received," you don't have monitoring. You have a comfort blanket.

What I'd check first

1. Suppression list — the quietest killer
2. Configuration set event wiring — are events going somewhere you read?
3. Seed real inboxes — watch placement, not just "delivered"
4. Don't trust "delivered" in dashboards — 99.5% delivered can hide 40% in Promotions

The question

Where's the 200 you're trusting that isn't the finish line? Find yours before your users do.