Multi-tenant SaaS email has two jobs: keep tenants isolated enough for trust and support, while keeping the sending system simple enough to operate. The hard parts are sender identity, suppressions, logs, and per-tenant limits.
last updated 2026-05-074 sections
section 01
Choose the tenant boundary
Some products only need tenant metadata on each send. Others need provider sub-accounts, separate domains, or customer-owned sending identities. The right boundary depends on support, compliance, and reputation risk.
boundary
fit
tradeoff
Metadata only
Small SaaS with one owned sender domain.
Less isolation.
Per-tenant stream
Different message classes by tenant.
More routing rules.
Provider sub-account
Agency or client reporting needs.
Higher setup cost.
Customer domain
Enterprise customers sending as themselves.
DNS and support load.
section 02
Separate suppressions by stream and tenant
A hard bounce on one tenant stream should not always suppress a user from every message in the product. Complaints and global unsubscribes need stricter handling.
okTrack suppression reason, tenant, stream, recipient, and provider.
okMake complaint handling stricter than ordinary unsubscribe handling.
okGive support a way to inspect why a message was suppressed.
section 03
Log for support first
Support needs to answer whether a specific tenant email was sent, accepted, bounced, delayed, or suppressed. Store provider message IDs and tenant IDs together.
section 04
Rate limits should protect tenants from each other
One tenant should not be able to exhaust the send quota or reputation budget for the whole product. Add tenant-level caps before the first high-volume customer arrives.