Implement Tenants in Amazon SES to streamline multi-tenant email sending, keep deliverability strong, and give each customer or business unit the visibility and control they need—without multiplying operational overhead. If you’re building a SaaS platform, a marketplace, or a multi-brand operation, structuring Amazon Simple Email Service (SES) for tenancy is a must-have pattern that pays off in compliance, observability, and scaling ease.
Why multi-tenancy matters in email
- Isolation: Separate traffic, metrics, and suppression lists per tenant to reduce blast radius and diagnose issues faster.
- Deliverability: Protect healthy senders from the bad habits of others by isolating configuration sets, pools, or even accounts.
- Compliance: Apply per-tenant policies for opt-in, content, and sending limits.
- Reporting: Provide every tenant clear analytics on bounces, complaints, opens, and clicks.
Key tenancy models with Amazon SES 1) Single SES account, logical separation
- Use configuration sets per tenant
- Route events to tenant-specific EventBridge rules or Kinesis streams
- Use tags to label messages (tenant_id, product, campaign)
- Optionally assign dedicated IP pools to premium tenants
Pros: Centralized management, cost-efficient, easy to automate. Cons: Less hard isolation; careful guardrails needed.
2) Multiple SES accounts (or sub-accounts)
- One AWS account per tenant (or per tenant tier), linked via AWS Organizations
- Cross-account sending via IAM and identity policies
- Centralized observability using EventBridge or CloudWatch cross-account
Pros: Strong isolation, best for regulated or high-volume/critical tenants. Cons: More overhead, cost, and coordination.
3) Hybrid approach
- Most tenants share one account with configuration sets; high-value tenants get dedicated IP pools or their own account
Core concepts for tenant isolation in SES
- Verified identities: Use per-tenant domains or subdomains (brand.com, or tenant.brand.com). Verify domain ownership in SES and configure SPF, DKIM (Easy DKIM), and DMARC per identity.
- Custom MAIL FROM: Configure a custom MAIL FROM domain per tenant to improve branding and alignment.
- Configuration sets: The backbone of logical tenancy. Attach a per-tenant configuration set to every send. Use it to:
- Route events to tenant-specific destinations (EventBridge, Kinesis Data Firehose to S3, or Amazon SNS)
- Apply dedicated IP pools per tenant or tier
- Add default tags for tenant_id and environment
- Message tags: Add tenant_id, product, campaign, and environment as tags for filtering analytics and suppression decisions.
- Dedicated IP pools (optional): Allocate pools to premium tenants or high-volume senders to isolate reputation. Warm them gradually.
- Suppression lists:
- Account-level global suppression exists, but aim for per-tenant logic in your application or via event processing
- Maintain a tenant-aware suppression store (e.g., DynamoDB keyed by tenant_id + recipient) and check before sending
- Rate limits and throttling: SES enforces sending quotas. Implement per-tenant rate limiting in your app layer to prevent noisy neighbors.
How to Implement Tenants in Amazon SES 1) Decide your isolation level
- Start with configuration sets and tags per tenant
- Reserve dedicated IP pools for high-volume or reputation-sensitive tenants
- Move top-tier tenants to separate accounts if needed
2) Domain and identity strategy
- Provide each tenant a branded subdomain (e.g., mail.tenantA.com) or host their full domain if they can add DNS records
- Verify domains in SES, enable DKIM signing (Easy DKIM preferred), and set up SPF and DMARC
- Configure a custom MAIL FROM domain for alignment
3) Configuration sets per tenant
- Create a configuration set for each tenant: config-tenantA, config-tenantB
- Attach event destinations:
- EventBridge bus with rule filtering by configuration set
- Or Kinesis Data Firehose to S3 partitioned by tenant_id/date
- Optionally associate a dedicated IP pool with premium tenants
4) Event pipeline and analytics
- Route events (deliveries, opens, clicks, bounces, complaints, rejections) to S3 via Firehose for long-term storage
- Use Athena to query S3, or stream into a data warehouse
- Build tenant dashboards (QuickSight, Grafana, or your product UI)
- Alert on bounce/complaint spikes per tenant via CloudWatch or EventBridge -> SNS/Slack
5) Suppression management
- Maintain a tenant-aware suppression table (DynamoDB):
- Key: tenant_id + recipient
- Attributes: status, reason, timestamps, source
- On bounce/complaint events, update this table and optionally push to the SES account-level suppression list for that tenant’s identities
- Check suppression before each send
6) Sending flow
- For every outbound email:
- Select the tenant’s verified identity (From domain) and configuration set
- Apply message tags: tenant_id, campaign_id, environment
- Enforce per-tenant rate limits and quotas in your send gateway
7) Security and access control
- Use IAM policies to constrain which identities and configuration sets an application (or microservice) can use per tenant
- For cross-account models, use resource-based policies on identities to allow delegated sending (ses:SendEmail) from your central service account
- Encrypt stored events and logs, and limit PII access by tenant via fine-grained IAM
8) Warm-up and deliverability
- Gradually ramp traffic for new tenants, especially on dedicated IPs
- Send to engaged recipients first; monitor bounce/complaint rates
- Maintain list hygiene; verify opt-ins; implement preference centers
9) Testing and migration
- Keep a sandbox or staging environment mirroring production config sets and event routes
- Use seed lists and inbox placement tests
- Roll out tenant by tenant and review metrics before scaling
10) Automation and IaC
- Codify SES resources (configuration sets, event destinations, identities, IP pools) with CloudFormation, CDK, or Terraform
- Automate tenant onboarding:
- Provision subdomain and DNS records
- Create configuration set and event routes
- Generate API keys or roles scoped to the tenant
- Validate DKIM/SPF/DMARC before enabling production sends
Common pitfalls to avoid
- Single shared configuration set for everyone: makes troubleshooting and per-tenant analytics hard
- Skipping DMARC/DKIM/SPF: hurts deliverability and brand trust
- No per-tenant suppression logic: leads to repeat bounces and reputation damage
- Lack of rate limiting: one tenant can consume your SES quota and harm others
- Ignoring event data: you’ll miss early warning signs of reputation issues
Quick reference architecture
- App or email microservice receives send request with tenant_id
- Lookup tenant config (domain, configuration set, IP pool, limits)
- Validate recipient against tenant-aware suppression store
- Call SES v2 SendEmail with:
- From: [email protected]
- ConfigurationSetName: config-tenantA
- Tags: tenant_id=tenantA, campaign=spring
- EventBridge captures SES events filtered by configuration set
- Firehose writes events to S3 partitioned by tenant_id/date
- Lambda updates suppression table on bounce/complaint
- Dashboards query S3/Athena for tenant analytics
Measuring success
- Deliverability: High inbox placement, low bounce/complaint rates per tenant
- Reliability: No cross-tenant impact during incidents
- Visibility: Self-serve tenant dashboards with near-real-time metrics
- Scalability: Automated tenant onboarding under minutes
By establishing clear identity strategy, per-tenant configuration sets, robust event routing, and tenant-aware suppression and throttling, you can implement tenancy in Amazon SES with confidence. Start with logical isolation, promote top-tier tenants to dedicated IPs or accounts as needed, and automate everything to keep operations effortless as you grow.
Further Reading
