One bad tenant can sink your whole email platform: what I learned building a reputation circuit breaker

Steve — Tue, 20 Oct 2026 17:51:20 +0000

I'm a solo founder in the UK building SentriSend, a security gateway that sits in front of transactional email (AWS SES / Resend). This week I shipped two features. Building them changed how I think about multi-tenant email, so here's what I learned.

The problem nobody sees: subscription bombing

Bots push a victim's address into hundreds of signup forms at once. The victim's inbox floods, and every site involved picks up complaints and spam-trap hits.

The nasty part is that each individual site only sees one or two "signups". From where any single app is standing, nothing looks wrong.

Two layers of defence

1. Per-sender limits. Any one sender is stopped from repeatedly emailing the same address in a short window. Blocked requests get an HTTP 429 with a Retry-After header, and no quota is charged.

2. Cross-sender detection. A gateway sits in front of many senders, so it can see something no single app can: lots of unrelated senders suddenly emailing the same address. That's a strong bombing signal. It triggers an alert first, then a temporary pause.

In a live production test, six identical sends went to one address. Five were accepted, and the sixth came back 429 recipient_rate_limited.

Privacy: no plain addresses are stored. Recipients become keyed, pseudonymous identifiers, which are cleared automatically within hours.

The lesson: one bad tenant can sink everyone

While planning the next feature, I realised something uncomfortable. Every customer sends through my provider account. One customer with a scraped or stale list could push bounces and complaints high enough to get the whole account suspended, and every other customer would go down with them.

Worse, I had no feedback loop at all. Provider "accepted" isn't the same as delivered, and I wasn't receiving bounce or complaint reports.

The fix: a reputation circuit breaker

Listen. A signed webhook receives delivery, bounce and complaint events. Each event is matched back to the API key that sent it, using hashed message IDs, and duplicates are counted once.
Measure. Each key's hard-bounce and complaint rates are tracked over a rolling window, with minimum sample sizes so a key isn't judged on three emails.
Act. Warn, then slow, then pause, all well before the provider's published limits. A paused key only returns through a manual review and a probation period. If the reputation check itself fails, sending stops rather than quietly carrying on.

There's also an account-wide alert, plus an alarm if webhook reports stop arriving, because silence shouldn't be mistaken for good health.

Takeaways if you run multi-tenant email

If tenants share your sending account, their reputation is your reputation. Isolate them.
"Sent" isn't "delivered". Wire up provider webhooks early.
Fail safely. Decide deliberately which checks fail open and which fail closed.
Write the privacy policy from the code, not from memory. Mine caught two mismatches before publishing.

There's a free developer sandbox at sentrisend.com. If you run multi-tenant email, I'd love to hear how you stop one tenant hurting the rest.

How AWS SES bounce rates can put your account at risk, and how to reduce bad signups before sending

Steve — Tue, 22 Sep 2026 14:50:14 +0000

If you send transactional email through Amazon SES, your bounce rate matters more than most developers realise until it becomes a problem. This post explains how bad signups push it up, what AWS says about thresholds, and one way to reduce the problem before you send. I'm the author of SentriSend, the API mentioned below, so treat this as a builder's perspective rather than a neutral review.

The thresholds

AWS publishes bounce-rate guidance for SES. As I understand it, AWS recommends keeping the rate low (around 2% or under), may place an account under review above 5%, and may pause sending at 10% or more. These numbers can change, so check the current SES documentation rather than relying on this post. Other providers, including SendGrid, have their own rules.

If sending is paused, everything that depends on your email stops: verification codes, password resets and receipts.

Clean DNS doesn't prevent bounces

SPF, DKIM and DMARC matter for deliverability, but they don't stop bounces caused by the addresses you send to. Three common sources:

Automated signups with disposable or made-up addresses
Typos in real users' addresses
Domains that don't exist or can't receive mail

For a small sender, a modest number of bad addresses can move the percentage a lot, because the total volume is low.

Handling it after the fact isn't enough

Many guides cover SNS/SQS bounce notifications and suppression lists. Those are worth setting up, but they run after the message has been sent and the bounce has been recorded. To reduce bounces in the first place, you need to check the address before you send.

A pre-send check

SentriSend is an API that validates an address with one call before you send. It checks that:

the address is well formed
the domain isn't on a bundled list of about 133,000 known disposable domains (the list is built into the service at build time)
the domain exists and can receive mail, using live DNS/MX lookups

If the DNS result can't be determined, the address is allowed with MEDIUM risk, so a slow lookup doesn't block a genuine user.

curl -X POST https://sentrisend.com/api/v1/validate \
  -H "Authorization: Bearer YOUR_SENTRISEND_KEY" \
  -H "Content-Type: application/json" \
  -d '{"email": "user@example.com"}'

An allowed address returns HTTP 200:

{ "allowed": true, "disposable": false, "risk_score": "LOW" }

A disposable domain returns HTTP 400:

{ "allowed": false, "disposable": true, "reason": "DISPOSABLE_DOMAIN", "risk_score": "HIGH" }

Your application reads the result and decides whether to continue sending through SES, Resend or whatever you use.

What it doesn't do

It doesn't confirm that an individual mailbox exists. A real domain with no such mailbox can still bounce.
It doesn't detect bots. It validates the address, so pair it with CAPTCHA or rate limiting on your forms.
It doesn't replace bounce handling. Keep your SNS/SQS suppression list.

Privacy

In SentriSend's send audit records, the recipient, subject and message bodies are redacted. Customer account and billing data is stored separately.

Try it

The free tier is 100 requests a month, with no card needed. There's also a live simulator on the site, and the docs and a working example are public.

Site: https://sentrisend.com
GitHub: https://github.com/sentrisend/SentriSend

If you've dealt with bad signups hitting your bounce rate, I'd like to hear how you handle it.

DEV Community: Steve