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 (3)
The "which 200" problem is painfully familiar — we hit the same wall and ended up wiring SNS → SQS → Lambda just to get bounce reasons into a searchable store, which felt absurd for something every managed provider ships by default. One thing that would have caught your SPF drift earlier: DMARC aggregate reports. With DMARC at p=none plus a rua tag, you get daily reports showing exactly which IPs fail SPF/DKIM per domain — free early warning, no plumbing required. Most teams set DMARC and never look at the reports. Is Reloop planning to ingest those, or focused on send-side visibility first?
That 14,000 sent / 200 bounced with no visibility into which 200 is exactly the gap I'm building for. I'm working on rootmail — it gives SES the delivery dashboard it doesn't have: searchable bounce/complaint logs, suppression management, reply capture. Opening a small closed beta (8 seats) — would you want in? Your SES war stories would make you a sharp tester.
Twinkal — following up from yesterday. rootmail's beta is open and you're the tester I most want stress-testing it.
You lived the 14,000-sent/200-bounced blind spot and hand-built the visibility layer SES doesn't ship. rootmail is that layer as a product: searchable delivery logs, bounce/complaint routing, per-recipient status — the dashboard you had to build yourself.
8 seats, closed beta. I'd genuinely like to see what breaks when someone who knows this infra deeply puts it through its paces.
Interested? rootmail.io/beta