4:00 PM on a Friday, a ticket came in from our highest-paying customer:
"None of our staff are receiving your system alerts."
I opened the AWS SES console expecting a quick answer.
Instead: no dashboard, no way to search admin@enterprise-client.com, just a line graph showing 14,000 emails sent, 200 bounced.
No idea which 200, or why.
The cause turned out to be an SPF record that no longer matched our sending setup after a domain migration weeks earlier. Nothing alerted us—we found it by opening bounces one at a time and reading raw headers in the console.
That afternoon is when it clicked:
SES is a sending engine, not a platform.
The cheap price tag doesn't include visibility.
You have to build that yourself.
What SES actually gave us
SES did exactly what it's designed to do.
It accepted mail, attempted delivery, and charged roughly $1 per 10,000 emails.
Against providers like SendGrid or Resend, that can easily look like hundreds of dollars per month saved.
What it didn't give us out of the box:
- A way to look up one recipient and see what happened to their message.
- Bounce reasons in a form support could use without reading SMTP headers.
- Events we could act on without wiring AWS plumbing first.
Bounce and complaint data exists in SES—but it shows up as notifications you route through SNS, often into SQS, then into a Lambda (or similar) before you have anything resembling a searchable delivery log.
Want support to answer:
"Did this email bounce?"
You'll need to build an internal UI on top of that pipeline.
That's real engineering time spent recreating a feature most email products ship by default.
None of this makes SES a bad product.
It makes it a different product than the one we thought we were buying when we optimized for the invoice line.
The middle option isn't free either
Managed providers like SendGrid, Postmark, Loops, or Resend solve the Friday afternoon problem.
You can:
- Search a recipient
- Open a message
- See a bounce reason
- Subscribe to webhooks
...without standing up an event bus inside your AWS account.
They also come with two trade-offs that mattered for us:
- Pricing that scales with volume—fine early, painful when send volume is part of the product.
- Your users' email data lives on someone else's servers—acceptable for many apps, but a real constraint in healthcare, finance, or anywhere with data-residency requirements.
We didn't want "cheaper SES."
We wanted the investigation experience of a managed provider on infrastructure we controlled.
That's what Reloop is built to be.
What that Friday actually taught us
It's tempting to rewrite this story as:
"If only we'd had better monitoring, the SPF drift would never have hurt a customer."
That's not quite true.
And it's not a claim we'll make about Reloop either.
DNS changes are an operations problem.
After a migration, someone has to re-check that:
- SPF
- DKIM
- DMARC
still match.
No platform pages you the week that drifts on its own.
The honest lesson from that Friday was narrower—and more useful.
When delivery fails, you should find out why in a few clicks—not spend an hour digging through AWS consoles.
We needed to:
- Search a recipient
- Open the message
- Read a clear bounce reason
- Move on to the DNS fix
SES made the first half of that afternoon expensive.
The SPF mismatch was the root cause.
The missing platform layer is what turned it into a fire drill.
What we built
That gap is why we built Reloop—open-source email infrastructure you can self-host with Docker or Kubernetes, or run with us.
For the SES pain specifically, Reloop gives you:
- Delivery logs you can actually use—open a message, see status, bounce classification, and headers without digging through AWS consoles.
- Recipient and contact activity—answer "What happened for this address?" without writing a custom lookup service.
- HTTP webhooks for sent, delivered, bounced, delayed, and complained—one endpoint instead of SNS → SQS → Lambda.
- Domain DNS setup and verification for SPF, DKIM, and DMARC, so after a migration you can quickly re-check the records that broke us.
- Your data on your servers when you self-host—the same product shape, without a third-party mailbox for transactional content.
We're not claiming Reloop would have magically prevented that customer's outage.
We're claiming the investigation shouldn't have required raw header archaeology.
Owning the stack shouldn't mean rebuilding a dashboard from scratch.
The trade-off
SES is cheap and opaque until you build the missing pieces.
Managed providers are visible and convenient until volume pricing or data residency gets in the way.
Self-hosting trades the per-email bill for operational ownership.
You're on call for your own email infrastructure.
- Queues
- DNS
- Deliverability
- Upgrades
Those become yours.
If that trade fits your team, check out the Reloop GitHub repository setup docs.
If it doesn't, use a managed provider.
The Friday ticket is still a useful warning either way.
Optimize for the invoice, and you may end up paying in engineering hours and customer trust instead.
Top comments (0)