Multi-Tenant Email: Suppression and Isolation Checks

Multi-tenant email needs a reliable answer to two questions: which tenant caused this message, and which controls apply before another one is sent? Per-tenant suppression helps keep recipient decisions tied to the correct sender. It works alongside access controls, provider policies and delivery monitoring, rather than making reputation isolation automatic.

Start by tracing tenant identity from the send request through delivery feedback and enforcement. Then decide which domains, sending accounts and infrastructure should be shared. A dedicated IP cannot repair an event that was attributed to the wrong customer.

What is multi-tenant email and why does isolation matter?

Multi-tenant email serves separate customers, workspaces or agents through a common platform. Each needs an explicit boundary for its data, credentials and sending policy. Reputation can still be shared through domains, IPs or provider accounts, so access isolation alone does not establish deliverability isolation.

The main paths are outbound submission, inbound mailbox access, provider routing, sender authentication and delivery feedback. Carry a stable application tenant ID across them. A mailbox ID, sender domain and provider account ID are related identifiers, but they do not necessarily describe the same boundary.

Microsoft's multitenant architecture guidance describes deployment stamps serving one tenant or a group. A shared stamp can still have noisy-neighbour problems. The pattern does not prescribe a fixed tenant count or guarantee that every reputation problem stays inside one group.

Use separate infrastructure when the required isolation and workload justify its cost. Define the boundary and test it. Do not describe a shared application deployment as fully isolated merely because its architecture diagram contains separate tenant boxes.

Should tenants get their own domain or a shared subdomain?

Choose the sender-domain arrangement from branding, DNS control and the provider's authentication requirements. A platform-controlled subdomain can reduce the DNS work a customer must perform. A customer-owned domain gives that customer control of its visible sending identity, but setup still depends on verified ownership and the correct records.

For example, a platform might provision workspace.example.com under a zone it controls. That is an illustrative domain, not a promise of instant provisioning. DNS publication, provider verification and any approval requirements still need to complete before the identity is ready for the intended traffic.

A subdomain does not guarantee an independent reputation. Receivers can consider other signals, including shared sending IPs and related domains. DMARC alignment is an authentication test; strict alignment does not itself create or remove a reputation boundary.

Under DMARC's identifier-alignment rules, a pass requires at least one successful, aligned authentication mechanism: SPF or DKIM. Strict alignment requires the relevant authenticated domain to match the visible From domain exactly. Relaxed alignment permits an organisational-domain match. Passing both mechanisms is useful, but DMARC does not require both to pass and align.

Review the visible From address, DKIM signing domain and envelope MAIL FROM together. Amazon SES custom MAIL FROM is configured on a verified email or domain identity, not on a configuration set. Its DNS requirements and failure behaviour must match the intended identity. A passing SPF result alone does not establish DMARC alignment.

Automate records only where you are authorised to manage the DNS zone. For customer-owned zones, provide the exact records and expose pending, verified and failed states. Recheck authentication after configuration changes, and test authorised messages through the intended route instead of treating one historical verification as permanent proof.

How should you split traffic across shared and dedicated IPs?

There is no universal tenant count or sending threshold that makes a dedicated IP the correct choice. Consider sustained volume, sending consistency, message type, provider policy and the ability to monitor and warm the IP. Low volume can make it harder to establish a consistent dedicated-IP reputation.

Salesforce's shared and dedicated IP policy recommends dedicated IPs above 100,000 messages per month and requires them beyond 250,000 for the service covered by that policy. That policy also prohibits simultaneous shared and dedicated IP use. These are Salesforce-specific rules, not a universal hybrid-pool recommendation or a threshold for every service.

New dedicated IPs need the provider's warming process. Amazon SES's standard dedicated-IP guidance describes its own warm-up behaviour. Do not turn a provider's schedule into a universal two-to-four-week rule. Consistent, wanted traffic and observed delivery results matter throughout the ramp.

A shared pool also needs sender controls. Joining one does not mean a new tenant can immediately send at any volume. Keep onboarding limits, authentication checks and monitoring appropriate to the provider and the tenant's legitimate use.

Separate sending accounts or delivery groups can help control routing and capacity. They do not prove separate IP ownership or independent reputation. Do not rotate accounts or move an abusive tenant to another pool simply to continue sending mail that a provider has rejected.

How do you contain a tenant that is damaging deliverability?

First, attribute the feedback to the responsible tenant and message. Then apply the relevant recipient and sending controls. A recipient complaint, a confirmed invalid-address hard bounce and a temporary delivery delay require different responses; “suppress every bounce” is too broad.

AWS's tenant-level suppression guide explains how one tenant's complaint or hard bounce can otherwise affect another tenant using an account-level list. Tenant-scoped records help preserve the distinction between those sender relationships. They do not authorise unwanted mail or override every provider safety restriction.

In SES, tenant-level suppression is opt-in; ACCOUNT remains the default scope. The documented precedence is configuration set, then tenant, then account, resolving to one suppression list for a send. The tenant must be correctly identified in the request. Verify the effective configuration instead of assuming that creating a tenant automatically changes suppression behaviour.

Account-wide or wider safety controls can still be legitimate. Design your own policy so it is clear which decisions are tenant-specific and which apply across the platform. Do not silently merge every tenant's list, or blindly ignore broader restrictions because a local tenant list is empty.

Feedback formats vary by provider. Some events identify a message and recipient; other reporting is aggregate. Preserve the provider message ID and your tenant mapping at submission time. If an event cannot be attributed safely, hold the decision for investigation rather than guessing which tenant should be penalised.

A practical containment sequence is:

1. Check the event type, reporting window, sample size and tenant mapping.

2. Suppress an applicable complaint or confirmed permanent recipient failure under the correct policy.

3. Reduce or pause the tenant's sending when the evidence warrants it; stop clearly abusive traffic promptly.

4. Notify the owner and operations team with the affected route, event and corrective action.

5. Restore only after the cause is addressed, permissions remain valid and monitored traffic supports recovery.

A quarantine state should restrict or pause sending while a problem is reviewed. It is not a low-reputation route for continuing the same traffic. Returning a tenant to a shared pool must also preserve the controls that protect its other senders.

Choose suppression-history retention from the reason for suppression, the need to honour recipient choices and your applicable retention policy. Do not apply a fixed 12-month cutoff without checking those needs. A previous complaint is also not evidence that the address later became a spam trap. The suppression list management guide provides related operating context.

How do you automate tenant onboarding without DNS tickets?

Automate the parts you control, and make the remaining dependencies visible. A customer domain can still require its owner's DNS changes. Provisioning speed, DNS propagation and provider approval are separate states; an API response should not conceal an incomplete setup.

Record the tenant's identity, authorised domain, mailbox, credential scope, selected provider and verification state. Make repeated provisioning requests safe to reconcile. If a step fails, retain enough state to resume or roll back without issuing extra credentials or leaving partially configured senders active.

Generate and rotate DKIM keys through the provider's supported process where that responsibility belongs to your platform. Protect secret material and restrict access to it. Do not assume every sending provider expects you to generate the key yourself or supports the same rotation procedure.

Use a bounded verification schedule and show the last result. Checking every few minutes initially, then hourly, is one possible schedule, not a DNS standard. Choose intervals from the provider's limits and the onboarding experience, and stop repeating checks when they no longer help.

Test mailboxes and provider simulators can reduce risk when their documented limits fit the test. A mailbox labelled “sandbox” does not automatically isolate production reputation. Use authorised recipients and the provider's test facilities, and verify which traffic reaches real recipients.

What should you measure per tenant, and how often?

Track attempted submissions, accepted recipients, delivery outcomes, hard and temporary failures, complaints, suppression decisions and send volume by tenant and provider. Define each denominator and event state. A submission accepted by the sending service is not proof of inbox placement, and a delivery rate is not simply the inverse of a complaint rate.

Use windows that suit the traffic. 24-hour, 7-day and 30-day views can help compare recent activity with longer trends; they are example reporting windows. Compare absolute counts as well as percentages so a small sample does not look like a reliable trend. Review persistent problems alongside alerts for sudden changes.

SES's sending review thresholds include a 5% hard-bounce rate and a 0.1% complaint rate as reasons for review. These are provider-specific review thresholds with their own calculations. They are not universal mailbox-provider throttling rules or permission to keep sending just below a threshold.

Gmail's sender requirements distinguish requirements for all senders from additional requirements for bulk senders. Verify the current rules for your traffic, including authentication and applicable unsubscribe requirements. Avoid treating a vague industry trend as an operational specification.

Keep delivery and webhook records long enough to support your incident process while respecting the applicable retention policy. There is no universal seven-day minimum for every email log. Export the evidence you need before a provider's documented retention expires, and limit who can access recipient data and payloads. Sendmux's deliverability content covers related checks.

How do you tier tenants and migrate them between isolation levels?

Describe each tier's actual controls: access scope, sender identity, sending capacity, provider arrangement and operational support. A price label does not create an isolation guarantee. A dedicated domain does not necessarily include a dedicated IP, and a dedicated IP does not remove application authorisation requirements.

Deployment stamps can serve one or several tenants. Choose their size from measured workload and the intended failure boundary, rather than an arbitrary tenant count. Write down what remains shared, including any provider account or sending reputation dependencies.

Track migration steps explicitly. Verify the new sender configuration and routing, retain rollback information, and expand traffic only after the tested path works. A rollback must still honour suppression, recipient choices and abuse controls; moving back to a shared pool is not always a safe response to a reputation problem.

How do you keep tenant data and credentials properly isolated?

Enforce authorisation where each operation accesses data or performs a send. Derive the allowed tenant and mailbox set from a trusted authenticated context. A caller-supplied tenant ID or a user-interface filter does not establish access permission.

Issue the least privilege needed for the integration, keep credentials out of logs, restrict their storage and test revocation. Review owner, administrator, developer and member permissions where those roles exist. Do not infer an application's role model or encryption contract from a generic architecture checklist.

MailChannels' multi-tenant sending analysis emphasises attribution, tenant controls, feedback and enforcement. Its warning about shared sending accounts is a reason to inspect the complete authorisation path. Properly enforced application authorisation can be a security boundary; cosmetic filtering alone is not one.

Log enough context to investigate an action: the tenant, authorised actor or credential identifier, operation and outcome. Avoid logging secrets to make an audit trail easier. Test that one tenant cannot request another tenant's message by changing a mailbox ID, message ID, cursor or event filter.

What API and webhook patterns keep tenancy correct at scale?

Use server-side mailbox filtering and pagination when the API supports them. A count endpoint can avoid fetching message bodies for a simple total, and a changes endpoint can reduce repeated retrieval. State tokens and cursors still belong to an authorised resource; they must not become shortcuts around tenant checks.

Batch operations can reduce request overhead, but each item needs the same access and failure handling as an individual operation. Check the provider's batch limits, partial-success behaviour and retry contract before using a batch response as evidence that every item succeeded.

For webhooks, verify the signature before processing the payload. Resolve the event to the permitted tenant or mailbox, deduplicate using a stable event identifier, and make the state update safe to repeat. A valid signature authenticates the notification; it does not prove that your application applied it to the correct customer.

Server-Sent Events can suit a client that maintains a live connection. Webhooks can suit a backend with an HTTPS endpoint. Neither removes the need for reconnect or retry handling, cursor/state reconciliation and documented event coverage. Consult the rate limiting guide when planning recovery.

How does Sendmux support these boundaries?

Sendmux platform provides an email API for AI agents and SaaS platforms, combining inbound mailboxes with outbound sending through connected providers. Your application's tenant model still needs to map to the appropriate Sendmux team, mailbox and sending resources. A mailbox is not automatically a separate provider account, suppression list or reputation boundary.

Teams separate people, billing, mailboxes, providers, logs and keys. Manual mailbox credentials are scoped to one mailbox. The documented permissions are email.send, email.receive, mailbox.read and mailbox.settings.update; grant only the actions the integration needs. Root Management API keys do not replace mailbox credentials.

The Mailbox API documents message filters, pagination, count and changes endpoints, batch message operations and thread access. Manual mailbox credentials can also serve as SMTP and IMAP passwords, subject to their permissions. Connected-app credentials may cover a granted mailbox set, so test the actual credential role rather than assuming every token has the same scope.

Agent access has a separate approval path. A self-registered agent can read and receive with its durable token. Sending requires owner approval and an exchange for a one-hour Sending-resource token. Provisioning a mailbox alone does not grant unrestricted outbound sending.

Delivery groups select permitted sending accounts. Quotas and weights apply within the supported account settings; customer-connected Gmail, Microsoft 365 and custom SMTP accounts are distinct from managed Amazon SES. Shared myagent.mx mailboxes use the managed sending route rather than arbitrary connected providers. These controls do not create a dedicated-IP service or an automatic per-application-tenant suppression policy.

Delivery logs expose message status, sender, recipient, provider and recorded attempts. Webhooks can be team-wide or filtered to selected mailboxes and event types. They include delivery, bounce, complaint, rejection, delay and inbound-message events. The Mailbox API's live event stream covers received-message updates; it is not a substitute for every outbound delivery event.

Sendmux documents HMAC-SHA256 webhook verification, a 24-hour window for retryable webhook failures and seven-day retention for webhook delivery metadata and retained payloads. An HTTP 410 response stops retries for that delivery. Those are the webhook contract's specific limits, not a general rule for all logs or an indefinite event-replay guarantee.

Use the SDK catalogue and CLI documentation with the matching API contract and credential scope. Their role is to expose documented operations; tenant policy, suppression mapping and migration checks remain responsibilities your application must implement where required.

What should you implement first?

Begin with tenant attribution, access checks and the suppression decision before expanding sending capacity. Test a correctly scoped send, a forbidden cross-tenant request, duplicate feedback, a temporary failure, a permanent recipient failure and a paused tenant. Then automate the configuration work whose dependencies are understood.

A 90-day plan could sequence telemetry, DNS automation and routing. Treat that as an illustrative planning horizon, not a delivery estimate or a required architecture. Set milestones from verified outcomes, such as correct event attribution and an effective pause, rather than promising that a particular week makes the platform safe.

For standards and provider models, RFC 8058 defines one-click unsubscribe signalling. MailChannels' multi-tenancy documentation distinguishes sub-accounts from sender IDs: sender IDs do not supply the same separate keys, limits, suppression lists, webhooks and reporting as sub-accounts. Verify the boundary each provider actually offers before mapping it to your customers.

Further reading

• AWS tenant-level suppression and precedence.

• Microsoft's deployment-stamp trade-offs.

• Salesforce IP policy.

• Suppression list management.

• Cold email infrastructure for AI agents.

• Cold email batching and send controls.

• Outlook sending limits.