I'm building a platform and need multi-tenant email sending

A good multi-tenant email system usually needs to solve 5 things well:

1. Tenant isolation
   Each customer/org should have its own sending identity, templates, limits, and tracking.

2. Deliverability
   Use proper domains, SPF/DKIM/DMARC, reputation management, and throttling.

3. Queueing and retries
   Don’t send synchronously from your app; use a job queue and retry logic.

4. Observability
   Track per-tenant sends, bounces, complaints, opens/clicks if needed, and error rates.

5. Compliance and abuse prevention
   Opt-outs, suppression lists, rate limits, and tenant-level guardrails.

Recommended architecture

Core entities

• Tenant
• Sender identity: from-name, from-email, reply-to, domain
• Template
• Campaign / message
• Suppression list
• Delivery event

Sending flow

1. App creates an email job for a tenant.
2. Job goes to a queue.
3. Worker resolves tenant config:
   • provider
   • sender identity
   • template
   • rate limits
4. Worker renders content and sends via provider.
5. Webhooks update status: delivered, bounced, complained, unsubscribed.
6. Suppression lists are updated per tenant and globally if needed.

Tenant isolation models

1. Shared provider, tenant-scoped configuration

Best for most SaaS products.

• One sending provider account or a small pool
• Separate domains/subdomains per tenant or per tenant group
• Tenant-specific API keys in your app layer, not necessarily in provider

Pros:

• Simple
• Lower cost
• Easier to manage

Cons:

• Shared reputation risk if one tenant misbehaves

2. Provider account per tenant

Useful for enterprise customers.

• Each tenant has their own SES/SendGrid/Mailgun account
• You send through their credentials

Pros:

• Strong isolation
• Tenant owns reputation and compliance

Cons:

• More complex setup
• Harder onboarding

3. Dedicated infrastructure per tenant

Only for very high scale or strict compliance.

• Separate queues, workers, IPs, domains, maybe separate DB/schema

Pros:

• Maximum isolation

Cons:

• Expensive and operationally heavy

What I’d recommend

For most platforms:

• Start with shared infrastructure
• Use tenant-scoped sender domains
• Add per-tenant rate limits
• Maintain tenant-level suppression lists
• Support dedicated provider credentials for enterprise tenants

Important deliverability details

• Set up SPF, DKIM, DMARC
• Use a custom sending subdomain per tenant or per environment
  • e.g. mail.tenant.com or mail.yourapp.com
• Warm up new domains/IPs gradually
• Separate transactional and marketing traffic
• Track bounce/complaint thresholds and auto-pause bad actors

Data model idea

tenants
sender_identities
email_templates
email_jobs
email_events
suppression_lists
tenant_limits
provider_accounts

Practical rule set

• Never let one tenant exceed configured volume without approval
• Do not allow a tenant to send from an unverified domain
• Enforce unsubscribe links for marketing email
• Make all sends idempotent
• Store provider message IDs for webhook reconciliation

Common stack choices

• Queue: SQS, RabbitMQ, Redis/BullMQ, Kafka
• Workers: Node.js, Go, Python, Java
• Provider: SES, SendGrid, Mailgun, Postmark
• Tracking: webhook receiver + event store

If you want, I can help you design:

1. a multi-tenant email architecture diagram,
2. a database schema, or
3. a provider selection strategy for your platform.