Multi-Tenant SaaS Email: Isolating Tenant Reputation

The situation

Consider a project-management SaaS with a few thousand business customers and a product team of about twenty. The product sends several kinds of email: sign-up confirmations, password resets, invitations to join a workspace, weekly digests, invoices and billing alerts. Customers can also connect their own domain so that invitations and notifications appear to come from their company.

For two years everything left through one shared sending setup: one domain, one set of authentication records and one pool of IP addresses. It worked until it did not. A handful of customers started inviting large lists of contacts who had never heard of the product. Those invitations drew spam complaints, and the complaints landed on the shared reputation. Within weeks, password-reset emails to some mailbox providers were arriving late or in the spam folder, and the support queue filled with "I never got the email" tickets.

What was actually going wrong

The team started by separating symptoms from causes. Three problems were tangled together:

1. One reputation for every kind of mail. Critical messages (resets, billing) and risky messages (customer-triggered invitations) shared a domain and IPs, so the riskiest traffic set the reputation of the most important traffic.
2. No tenant isolation. A single customer's bad behaviour could damage everyone, and there was no quick way to see which customer was responsible.
3. Weak visibility. The team saw bounces in the application log but had no view of complaints by provider, no alerting, and no per-tenant breakdown.

Notice that none of these is a content problem. Rewriting subject lines would not have helped. The fix was structural.

The plan

The team agreed on four principles before touching any configuration: separate streams by risk, authenticate every domain properly, give each tenant a boundary, and measure by stream and by customer. The work ran in four phases over about six weeks. The timeline is indicative; a smaller product could do it faster.

Phase 1: separate the streams

The team split its mail into three streams, each on its own subdomain and, where the plan allowed, its own IP pool:

The principle is that the stream most likely to attract complaints must never share a reputation with the stream users cannot live without. We explain why in our analysis of bulk-sender rules: complaint thresholds are measured against a sending domain, so isolation is a protection, not an optimisation.

Phase 2: authenticate every domain

Each subdomain received its own SPF, DKIM and DMARC setup. The team published the records shown in the sending console for each domain, and used a DMARC policy of p=none with a reporting address first, so they could see every system that sent as the domain before tightening anything.

_dmarc.account.example.com  TXT  "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"

Two weeks of aggregate reports found a surprise: an old marketing tool was sending as the billing subdomain. The team moved it to a different subdomain before moving to enforcement. Without the reporting step, moving to reject would have blocked real invoices. Our guide to reading aggregate reports and moving to reject covers the method.

Phase 3: tenant boundaries

For the invitation stream the team introduced controls that sit in the product as well as in the email setup:

• Every outgoing invitation carries a tenant identifier in a header or metadata field, so a complaint or bounce can be traced to the customer who triggered it.
• New tenants have a low daily invitation limit that rises as their invitations are accepted rather than ignored.
• Invitations to addresses that bounce are suppressed automatically, and repeated invitations to the same address are blocked.
• Customers who connect their own domain complete authentication before their domain is used for sending.

Phase 4: monitor by stream and tenant

Delivery events (delivered, bounced, complained) were sent to the company's own systems through webhooks and stored with the stream and tenant identifier. A simple dashboard showed complaint rate and bounce rate by stream, by mailbox provider and by tenant, with alerts when a tenant crossed an internal threshold. The team also set up Google Postmaster Tools for each sending domain to see Gmail's view of reputation and compliance.

A worked example: tracing one incident

Here is how the new setup changes a bad day. Suppose a complaint alert fires for the collaboration stream at one mailbox provider on a Tuesday morning. Before the split, the team would have seen delayed password resets and spent hours guessing. Now the response is a short, ordered routine:

1. Confirm the blast radius. The critical and billing streams show normal delivery times, so customers can still sign in and pay. The problem is contained to one stream.
2. Find the tenant. A query on the tenant identifier shows that one workspace sent a large batch of invitations overnight, most to addresses at the affected provider.
3. Act at the right level. The team pauses that tenant's invitations, which stops the damage immediately, and contacts the customer with the facts.
4. Repair. The tenant's list is cleaned, its daily limit is reset to the low starting value, and it earns higher limits again as invitations are accepted.
5. Close the loop. The team reviews whether the alert fired early enough and lowers the internal threshold if needed.

The incident still costs time, but it costs one customer's invitations for a day instead of every customer's password resets for a week. That difference is the entire business case for isolation.

What it does not solve

Isolation limits the damage; it does not remove the cause. A tenant who wants to mail people who did not ask for it will still generate complaints, and a separate subdomain does not make that mail welcome. The company's acceptable-use terms and onboarding flow, which asks customers to confirm that they have a relationship with the people they invite, matter as much as the technical split. Likewise, authentication proves who sent a message, not whether anyone wanted it.

How the team would measure success

We do not give result numbers here; set your own baseline and targets. What matters is the set of measures a team like this should watch, and what each tells you.

What the team learned

1. Isolation is cheaper before an incident. Splitting streams after a reputation problem means working under pressure; doing it earlier is a quiet configuration project.
2. Tenant identifiers are worth adding on day one. The most valuable question in an incident is "who sent this?", and the answer should be a query, not an investigation.
3. Reporting comes before enforcement. The forgotten sender found in the first DMARC reports would have been blocked by a hasty reject policy.
4. Product controls are deliverability controls. Invitation limits and suppression rules in the app protect sender reputation as much as DNS records do.

How to apply this to your product

1. List every kind of email your product sends and rate each by risk and by importance.
2. Give critical mail its own subdomain, and keep customer-triggered mail away from it.
3. Authenticate each subdomain, start DMARC at p=none with reporting, and read the reports before tightening.
4. Tag every message with a tenant and stream identifier.
5. Capture delivery events through webhooks and alert on complaint and bounce rates by tenant.
6. Add product-side limits for new tenants and automatic suppression of bad addresses.

Related reading

• Emails going to spam: troubleshooting checklist
• Passkeys and the future of transactional email
• DMARC aggregate reports: moving to reject