Per-Tenant Sending Domains for Multi-Tenant SaaS

If you run a multi-tenant SaaS where your customers send email to their own users, you face a choice most teams get wrong by default: send everything from your domain, or let each tenant send from theirs. The default, sending all tenant mail from yoursaas.com, is simpler and works until it does not. The moment one tenant's users mark their mail as spam, every tenant's deliverability suffers, because they all share one reputation. For any product where tenants send meaningful volume to their own audiences, per-tenant sending domains are not a premium feature, they are how you stop one bad tenant from poisoning the well for everyone.

The shared-reputation trap

When all tenants send from your domain, you pool their reputations into one. That is fine when every tenant behaves. But tenants do not all behave. One imports a stale list, hits spam traps, and draws complaints. The receiving providers see yoursaas.com sending problem mail, and they throttle or junk all of it, including the well-behaved tenant whose password resets now land in spam. You have coupled the fate of every customer to your worst customer.

For a low-volume product where tenants send only a trickle of purely transactional mail, the shared model is acceptable and far simpler. The trap only springs at volume and with varied tenant behavior. Know which situation you are in.

What per-tenant sending domains solve

Letting each tenant send from their own domain, tenant.com or mail.tenant.com, isolates reputation per customer. Now a spammy tenant only damages their own sending, not yours or their neighbors'. It also looks better to the tenant's own users, because the mail comes from a brand they recognize rather than from your platform. This is the same reputation-isolation logic as should you send app email from a subdomain, applied one level up: each tenant gets their own isolated surface.

The cost is complexity. You now manage authentication for many domains, onboard each tenant's DNS, and handle the ones who set it up wrong.

Making tenants set up DNS is the hard part

Per-tenant domains require each tenant to publish DNS records: SPF includes, DKIM keys you generate for them, and ideally a DMARC policy. Most of your customers are not email administrators, so this is where onboarding stalls. Provide the exact records, a verification check that tells them clearly whether it worked, and a fallback so their app email still sends from your domain until their DNS verifies. Never leave a tenant in a state where email silently fails because they fumbled a TXT record. The authentication details they need are in the SPF, DKIM, and DMARC setup guide.

Warming and volume per tenant

Each tenant's domain starts cold. A big tenant that suddenly blasts their full list from a brand new domain will land in spam, so your platform needs to warm per-tenant sending, ramping volume as each domain builds reputation, following warm up your email sending domain. Small tenants may never reach the volume that justifies a dedicated setup, which is another reason to offer the shared domain as a default and per-tenant domains as an upgrade for customers who send real volume. The dedicated-versus-shared reasoning carries over from dedicated vs shared IP for sending email.

Observe deliverability per tenant, not just per platform

The whole value of isolation is lost if you cannot see per-tenant health. Track bounce rate, complaint rate, and delivery per tenant so you can catch the one importing bad lists before they get their own domain blocklisted, and so you can prove to a good tenant that their mail is landing. Wire delivery events through email webhooks for bounces and events and watch them per tenant using the approach in monitor transactional email sends in production. Per-tenant observability also lets you enforce per-tenant rate limits so one customer cannot generate a send spike that looks like abuse, per rate limit notification emails per user.

Offer both, default to shared, upgrade to isolated

The right architecture for most multi-tenant SaaS is to support both. New and small tenants send from your shared domain, which is simple and gets them running instantly. Tenants who send serious volume or want their own branding upgrade to a per-tenant sending domain, taking on the DNS setup in exchange for isolation and brand control. That path protects the platform's overall reputation while giving high-value customers what they need.

I built Usermails as developer-first application email designed for exactly this multi-tenant shape: programmatic per-domain authentication, per-stream observability, and clean delivery events so you can isolate tenant reputation without building the whole email plane yourself. For the broader case that this is core infrastructure worth designing well, read transactional email is infrastructure. In multi-tenant email, isolation is not gold-plating. It is how you keep one tenant's mistake from becoming everyone's outage.