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

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

1. 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.
2. 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.
3. 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.