How do I build multi-tenant email sending for each customer domain?

To build multi-tenant email sending per customer domain, think in terms of:

1. Tenant isolation
2. Domain authentication
3. Routing and sending
4. Tracking and compliance

Here’s a practical blueprint.

---

1) Decide what “multi-tenant” means for email

Usually there are two patterns:

A. One shared sending infrastructure

• One app/platform sends on behalf of many customers.
• Each customer has their own “From” domain, branding, and tracking domain.
• You manage all auth records centrally.

B. Per-tenant dedicated sending

• Each customer gets separate infrastructure:
  • dedicated subdomain
  • dedicated IP pool or provider account
  • separate suppression lists and analytics
• Better isolation, more operational overhead.

For most SaaS products, shared infrastructure with per-tenant domains is the best starting point.

---

2) Require tenants to verify their domain

You should never let a customer send from a domain they haven’t proven they own.

Verification flow

1. Tenant enters:
   • sending domain: mail.customer.com or customer.com
   • optional tracking domain: click.customer.com
2. Your system generates DNS records.
3. Customer adds them to DNS.
4. You verify automatically.

Common records

For sending:

• SPF
• DKIM
• DMARC (recommended)

For tracking:

• CNAME for open/click tracking domain

Example:

• customer.com sends as noreply@customer.com
• DNS includes:
  • SPF TXT
  • DKIM TXT or CNAME
  • DMARC TXT
  • tracking CNAME like links.customer.com -> your-tracking-domain.example.com

---

3) Use a provider that supports multiple identities

Good options:

• SES
• SendGrid
• Mailgun
• Postmark
• SparkPost (depending on use case)

You need support for:

• verified sending domains
• API-based sending
• per-message headers or metadata
• webhooks for bounces, complaints, deliveries

Important

If you need each tenant to send from their own domain, make sure your provider can:

• verify many domains
• handle bounce webhooks
• separate reputation/tracking per domain or tenant
• support configuration sets / tags / streams if needed

---

4) Design your data model

You’ll want tables/entities like:

Tenants

• id
• name
• status

EmailDomains

• id
• tenant_id
• domain
• verification_status
• spF_status
• dkim_status
• dmarc_status
• tracking_domain
• provider_identity_id

SendingIdentities

• id
• tenant_id
• email_domain_id
• from_name
• reply_to
• provider_account
• active

EmailMessages

• id
• tenant_id
• recipient
• subject
• body
• from_address
• provider_message_id
• status
• metadata

Suppressions / complaints / bounces

• store per tenant and possibly globally if you need shared blocklists.

---

5) Route every email through the tenant context

When your app sends an email, it must know:

• which tenant it belongs to
• which verified domain to use
• which template/branding to apply

Example flow:

1. User action triggers email send.
2. App loads tenant settings.
3. Picks verified sending domain.
4. Builds message:
   • From: Brand <noreply@customer.com>
   • Reply-To: support@customer.com
   • Headers include tenant ID or metadata.
5. Sends through provider.

Never allow arbitrary From addresses without validation.

---

6) Authenticate each domain correctly

SPF

Authorize your email provider to send for the domain.

DKIM

Sign outgoing email with a domain-specific key.

DMARC

Tells receiving mail servers how to handle failures.

Best practice:

• Use at least DKIM + SPF
• Align the visible From domain with authenticated domains
• Add DMARC once setup is stable

If you send from customer.com, ideally:

• SPF passes for the envelope sender
• DKIM signs with d=customer.com
• DMARC aligns with customer.com

---

7) Consider subdomains instead of apex domains

Often easier:

• mail.customer.com
• notify.customer.com
• mg.customer.com

Why:

• safer for customers
• easier DNS delegation
• less risk of interfering with their primary business email
• cleaner SPF/DKIM isolation

Many SaaS apps use:

• email.customer.com for sending
• links.customer.com for tracking

---

8) Handle bounce, complaint, and unsubscribe events per tenant

This is critical.

Use provider webhooks to receive:

• bounce
• complaint
• delivery
• open/click events
• unsubscribe

Then:

• map event back to tenant and message
• update suppression state
• prevent future sends to bad addresses
• expose analytics in tenant dashboard

Keep suppression lists isolated:

• tenant A’s complaint should not suppress sends for tenant B
• unless you intentionally use a global suppression policy

---

9) Build a queue-based sending pipeline

Don’t send synchronously from your web request.

Use:

• API request creates email job
• queue/worker picks it up
• worker resolves tenant domain + templates
• worker sends via provider
• worker updates status

This gives:

• retries
• rate limiting per tenant
• better observability
• safer scaling

---

10) Rate limit and protect reputation

You’ll need controls like:

• max sends per tenant per minute/hour/day
• warm-up for new domains
• blocked sends if domain not fully verified
• reputation monitoring
• bounce thresholds

If one tenant sends spam, it can hurt shared infrastructure. Add:

• content checks
• abuse detection
• manual review for high-risk tenants

---

11) Support templating and branding per tenant

Store tenant-specific:

• logo
• colors
• footer text
• legal address
• unsubscribe link
• support email

Use templates like:

• welcome email
• verification email
• invoice email

Render with tenant context so every message looks like it came from that customer’s brand.

---

12) Security and compliance

Important safeguards:

• only allow verified domains
• audit all domain changes
• log who approved DNS verification
• encrypt secrets and API keys
• use per-tenant access controls
• support unsubscribe and GDPR/CCPA deletion workflows
• avoid exposing raw provider credentials to tenants unless necessary

---

13) A simple architecture

Example components

• Tenant service: stores customer settings
• Domain verification service: creates and checks DNS records
• Email sending service: prepares and sends messages
• Webhook service: processes bounces/complaints
• Analytics service: per-tenant reporting

Flow

1. Tenant adds domain
2. You generate DNS instructions
3. Customer verifies DNS
4. Domain marked active
5. App sends from that domain
6. Webhooks update status and metrics

---

14) Example sending logic

Pseudo-flow:

if tenant domain is verified:
    from_address = tenant's verified from address
    dkim_domain = tenant's domain
    tracking_domain = tenant's tracking domain
    send via provider with tenant metadata
else:
    reject send

---

15) Start simple, then add sophistication

MVP

• one provider
• tenant table
• domain verification
• send emails via queue
• webhook processing
• basic dashboard

Later

• dedicated IPs
• regional sending
• advanced suppression rules
• tenant-level analytics
• provider failover
• custom DKIM key rotation
• per-tenant sending pools

---

Recommended best practice setup

If you want a strong default:

• Use subdomains for sending
• Require SPF + DKIM + DMARC
• Send through a queue
• Keep tenant metadata on every email
• Process webhooks for bounces/complaints
• Maintain per-tenant suppression lists
• Add rate limiting and abuse detection

---

If you want, I can also give you:

1. a database schema
2. a reference architecture
3. provider-specific setup for SES / SendGrid / Mailgun
4. a Node.js / Python implementation example