Tenant Email Isolation: Seven Migration Steps
Tenant email isolation separates access, sending identities, suppression decisions and operational controls for customers sharing a platform. It can limit cross-tenant damage, but a subdomain, mailbox or dedicated IP does not guarantee independent reputation. Migrate by verifying each boundary, keeping a rollback plan and pausing harmful traffic before it spreads.
Contents
- FAQ
What does tenant email isolation solve?
Tenant email isolation addresses several different boundaries. Email authentication checks sending-domain or signature claims; it does not decide whether an application actor may send particular content to a recipient. SPF and DKIM have different identities, and DMARC checks alignment with the visible From domain. Passing those checks does not replace application authorisation.
Mailbox providers can assess signals associated with domains and IPs, while your internal tenant ID helps your own application attribute activity. Shared infrastructure can create shared exposure. The email reputation overview explains why sending behaviour matters, but no configuration can promise that another tenant's activity will never affect delivery. Keep access-control evidence separate from reputation measurements.
Four concepts make the design easier to review:
- Tenant identity: the application customer, workspace or agent that owns a workflow and its authorised data.
- Sending identity: the permitted sender address and domain used for that workflow.
- Suppression scope: which recipient restriction applies, why it exists and where it must be enforced.
- Reputation telemetry: acceptance, bounce and complaint data attributed to a tenant, alongside account-wide signals.
These concepts need explicit mappings. An application tenant, an email provider tenant and a mailbox are not necessarily the same object. Record their relationship and enforce it when resolving credentials, recipients and routes rather than relying on similar names in different systems.
Which isolation techniques should you use?
Per-tenant subdomains can separate sender configuration, DKIM keys and reporting. A name such as tenant123.mail.example.com makes ownership visible, but it does not force mailbox providers to score each subdomain independently. Google's sender guidance aggregates related subdomains when identifying bulk senders. Use the multi-tenant architecture guide as design context, not proof of guaranteed reputation separation or a universal tenant-count threshold.
Scope application suppression decisions to the relationship they protect. A useful record can include tenant ID, address, reason and evidence, but provider account-wide or global safety policies may still apply. A complaint, marketing opt-out and confirmed invalid address need different handling. Do not treat every global restriction as an error or bypass a provider's safety decision because another tenant wants to send.
Amazon SES supports tenant-level suppression. Its default is account-level suppression; tenant mode is an explicit choice. The effective setting is selected in configuration-set, tenant, then account precedence, rather than checking three lists in sequence. Tenant hard bounces can also be recorded globally, so tenant scoping is not a promise that every restriction stays local.
Choose IP arrangements from traffic consistency, provider policy and operating capacity. Shared pools can suit variable or low-volume traffic; dedicated IPs require enough sustained sending and reputation work to justify them. Amazon SES describes those trade-offs. Treat quarantine as stopping or restricting affected traffic during investigation. Moving an abusive campaign to a fresh pool would continue the problem rather than contain it.
How do you bind tenant context to sending?
Resolve the allowed tenant from authenticated context, then authorise the requested sender, recipient and content against that tenant's data. A client may identify a resource, but that identifier is a lookup input, not proof of ownership. Preserve the verified tenant association through the queue and event records, including retries and route changes.
For SES, Tenants uses TenantName on supported sending API requests and X-SES-TENANT for SMTP. Associate the sending identity and applicable configuration set with the tenant; an associated identity's default configuration set can apply. Resources may be shared or dedicated, and tenant activity can still affect account-wide reputation. Omitting tenant context can leave a send outside the intended tenant controls, so enforce its presence in your integration.
Before enqueueing, apply the tenant's authorised recipient and suppression decisions; recheck relevant changes before sending. Choose only routes permitted for that identity and credential, with quota and safety controls. Log the resolved tenant alongside request, message and event identifiers so an investigation can follow the decision without reconstructing ownership from an email address.
Treat templates as another authorisation boundary. If your product supports tenant-authored content, validate and sanitise it under an explicit content policy. If workflows need a fixed structure, use typed templates and validate their parameters. Arbitrary HTML is not automatically impossible to handle, and a trusted template alone does not authorise its recipient list.
What should trigger remediation?
Track bounce, complaint and provider acceptance rates per tenant and at the account level. Keep their denominators, time windows and diagnostic causes visible. Acceptance is not inbox placement, and a bounce spike is not proof of abuse. Set warnings, throttles and pauses from the applicable provider rules and your own evidence instead of applying an unqualified universal threshold.
Choose responses by cause. Temporary pressure may justify throttling; suspected compromise or abusive content may require an immediate pause. Quarantine should restrict the affected workload while someone investigates. Record who can resume it and what evidence they must check. A graduated sequence is useful where appropriate, but serious problems need not wait through every stage.
SES reputation findings can arrive through EventBridge, with the tenant ARN in the event's resources. Its Standard, Strict and None policies differ in automated pausing behaviour; do not assume every finding pauses or automatically reinstates sending. Correlate events to your tenant mapping and follow the configured policy. The rate limiting and retry guide provides queue-control context for implementing an authorised response.
How do you automate DNS onboarding?
DNS automation needs authority over the relevant zone. You can publish records through a DNS provider API for a domain you control or one the customer has explicitly delegated. Otherwise, give the customer the exact records to publish and report verification progress. Automation can reduce manual work, but it cannot remove the ownership and permission requirement.
Generate or request the DKIM material appropriate to the sending provider, publish its required records and set SPF and DMARC for the intended identities. A managed signing service may supply DNS records rather than requiring your application to hold a private signing key. Where you do hold private keys, protect them, restrict access and plan rotation with enough overlap for DNS caches and in-flight messages.
Cloudflare is one option when you have authorised DNS API access; other providers have their own contracts and permissions. Keep verification state visible in onboarding and distinguish missing records, propagation, failed checks and readiness. A successful DNS write is not the same as a successful external lookup or a passing received-message authentication check.
Which security risks does isolation reduce?
A trusted workflow can become a relay for unauthorised messages when an authenticated actor controls a recipient or content that the application never properly authorises. The email can pass authentication because an authorised sending service produced it. The missing check is whether that actor could trigger that particular message, not whether the domain's DNS records exist.
A 2026 trusted workflow relay analysis examines disclosed cases and defensive controls at workflow boundaries. Apply that distinction to your own integration without assuming the paper demonstrates a vulnerability in Sendmux. Validate the authenticated actor's permission for the object, recipient and content before a sending workflow executes.
- Bind recipients to authorised data. Validate recipient choices against the tenant's permitted workflow; do not trust a client-supplied tenant ID as authority.
- Constrain composition. Use typed templates where appropriate, validate parameters and sanitise allowed content before delivery.
- Check tokens at the receiver. Validate the audience and permissions of credentials used across service boundaries.
- Investigate unusual activity. Recipient fan-out, unexpected template changes and unfamiliar outbound links are signals to review, not proof on their own.
How do you migrate a tenant in seven steps?
Use a staged migration to make problems observable and reversible. It cannot guarantee unchanged deliverability. Define the tenant's authorised identities, providers and suppression policy before cutover, then keep the old configuration available only for a controlled rollback that remains permitted and does not continue harmful traffic.
- Baseline. Record recent volume, acceptance, bounce and complaint data, including the measurement windows and known failure causes.
- Provision. Create the required provider and application resources, obtain DKIM records and publish authorised DNS changes. Wait for the required verification checks.
- Bind. Associate permitted identities, configuration and credentials with the intended tenant. Confirm both allowed access and rejection of another tenant's resources.
- Route. Apply the verified tenant context using the protocol's actual API field or SMTP header. Confirm recipient, suppression and routing decisions with recorded evidence.
- Verify. Send only authorised controlled tests, inspect received authentication and reply behaviour, and check that message and event identifiers map back to the right tenant.
- Monitor. Review delivery outcomes, DMARC reports and reputation findings closely during rollout. Set a review schedule and observation period based on reporting delay, volume and risk.
- Resume deliberately. Increase traffic or lift restrictions only after the responsible owner verifies the cause is resolved and provider policy permits it. Preserve the decision and supporting records.
| Phase | Check | Failure response |
|---|---|---|
| Before migration | Baseline, DNS readiness and authorised identities | Hold cutover until missing evidence is resolved |
| Cutover | Tenant binding, recipient policy and effective routing | Stop the affected migration if the intended controls do not apply |
| After cutover | Controlled tests, event attribution and delivery trends | Investigate unexpected changes before increasing traffic |
| Rollback | Permitted prior configuration and retained diagnostics | Revert a configuration fault when safe; keep abusive traffic paused |
Do not automatically roll every bounce increase back to a shared identity. First determine whether the cause is configuration, recipient quality, abuse or a provider restriction. Rollback can restore an earlier configuration; it cannot erase reputation history or make an otherwise prohibited send acceptable. Notify the affected tenant through your normal incident process and retain the diagnostic record.
What does isolation cost to operate?
Isolation adds configuration, verification, key lifecycle, monitoring and incident-response work. Dedicated IPs add their own volume and warming requirements. Choose the boundaries that match a tenant's risk and traffic instead of assigning dedicated resources as a status benefit. Shared and dedicated resources can both be valid, depending on the provider and the controls you need.
Automating authorised DNS changes, attribution and suppression decisions can reduce repetitive work. It does not make operating cost stay flat as tenants grow: provider limits, exceptions, permission failures and investigations still need ownership. Measure the actual workload and test the onboarding failure paths before promising a particular tenant scale or a zero-configuration setup.
Which boundaries does Sendmux provide?
The Sendmux platform overview covers persistent mailboxes and outbound sending for agents and SaaS applications. You provision mailboxes and map them to your own tenants; an application workspace does not automatically become a mailbox. Mailbox-scoped credentials can limit access to that mailbox, while standalone Sending credentials serve other outbound workflows. Neither credential type guarantees independent sender reputation.
The Mailbox API uses permissions such as mailbox.read, email.receive and email.send. Domain and mailbox sender allow/block settings govern inbound filtering, not a native per-application-tenant outbound suppression list. Keep that distinction explicit when designing recipient policy and testing cross-tenant access.
Delivery groups constrain eligible outbound providers according to the key or mailbox scope. Configured weights, quotas, provider status and sender requirements still apply. Shared myagent.mx mailbox sending uses the managed route, so connecting another account does not grant that mailbox arbitrary provider choice. These controls do not move all reputation responsibility onto infrastructure you exclusively own.
Sendmux's domain workflow returns the records required for custom-domain use and checks verification status through the dashboard or Management API. The customer must publish those records or authorise a DNS integration to do so. Choose sending-only or sending-and-receiving mode deliberately; hosted custom-domain mailboxes require the receiving configuration. Test the documented behaviour before assigning it to your application's isolation model.
Sources
Recommended reading
Frequently Asked Questions
What is tenant isolation in email infrastructure?
Tenant isolation separates access, sending identities, recipient policies and operational controls for customers sharing a platform. It helps contain failures and attribute activity, but does not guarantee independent reputation or prevent every cross-tenant delivery effect. Verify application authorisation, provider resource associations and suppression policy separately, and keep account-wide safety signals in view.
What does "email tenant" mean?
An email tenant is the customer, workspace or other grouping to which an application or provider assigns email resources and activity. Define that boundary explicitly: an application tenant, an SES tenant and a mailbox are not interchangeable objects. Map the resources, credentials and permitted workflows between them rather than assuming matching names establish ownership.
Is email quarantine a legitimate practice?
Quarantine can mean restricting or pausing an affected sending workload while its owner investigates a problem. It should not mean moving an abusive campaign to a different IP so it can continue sending. Use the provider's documented controls, preserve evidence and require a deliberate remediation and resumption decision; separate infrastructure alone does not settle the cause.
How does per-tenant suppression avoid cross-tenant contamination?
Tenant-scoped suppression can keep relationship-specific restrictions attached to the right customer and recipient. It does not authorise bypassing unrelated provider safety decisions. In SES, tenant-level suppression is an explicit setting rather than the default, and configuration-set, tenant and account settings determine which list applies. Apply the effective provider policy and distinguish complaints, marketing opt-outs and confirmed invalid addresses instead of treating every global restriction as unwanted contamination.
What's the difference between shared and dedicated IP pools for tenants?
Shared pools can suit lower or variable volume, while dedicated IPs require sustained sending and active reputation management. Choose using provider policy, traffic consistency and the controls you can operate. Neither arrangement guarantees independent reputation or inbox placement, and dedicated resources do not replace recipient permission, suppression checks or a response to harmful traffic.
