Email infrastructure for SaaS platforms that send on behalf of thousands of customers
When one of your tenants buys a list, gets compromised, or just has bad sending hygiene, the blast radius is supposed to be that tenant — not your entire platform. Most shared-IP setups fail this test. We ship the per-tenant isolation primitives that actually contain the damage.
Shared IPs were designed for the case where a single sender controls the content. Multi-tenant SaaS isn't that case.
You run a SaaS platform. Maybe it's invoicing software, a property-management tool, a help-desk product, a field-service app. Your customers are small businesses that depend on your platform to send appointment reminders, invoice notifications, password resets, support replies. The aggregate volume is meaningful — single-digit millions per month is common — but no individual customer sends much. The temptation is to plug in SendGrid or SES, share a pool of IPs across all your tenants, and call email "solved."
It isn't. A shared IP pool means a shared reputation. One spammer, one compromised account, one customer who decides to upload a purchased list, contaminates the sending reputation of everyone else on your platform. SendGrid's own documentation states this explicitly. Real incidents are extensively documented: companies have woken up to find their shared IPs blocked at Microsoft, delivery rates collapse below 30%, and recovery taking weeks.
The shift from IP-based to domain-based reputation that came with the 2024 Gmail/Yahoo bulk-sender mandate (and Microsoft's parallel rules in 2025) helps a little — sub-domain isolation is now a real lever — but doesn't solve the problem. The receivers still aggregate signals across pooled infrastructure. And most platforms hadn't operationalised the domain-level controls those mandates require.
In August 2025, AWS shipped Amazon SES Tenants — explicit per-tenant isolation with reputation policies that can pause a problematic tenant before it takes the rest down. The product launch validated the diagnosis: the existing architecture was structurally inadequate for SaaS-on-behalf sending, and customers had been carrying the cost. Postmark, Mailgun, and SendGrid all support sub-accounts to varying degrees, but the abuse-containment automation around them is uneven.
The cost of getting this wrong is concrete. The economic literature on email reputation suggests every 1% of mail filtered to spam translates to roughly $1,200 of lost revenue per active sender. Recovery from a serious blocklisting incident is documented at two weeks to six months. One week of email downtime for a twenty-person sales team running its outbound through a contaminated platform is over $50,000 of pipeline. Multiply that across your tenant base if their email goes down because of someone else's behaviour.
How much does one bad tenant actually cost the rest of your platform?
Move the sliders to model your situation. The math uses the lost-revenue and recovery-time figures published in the deliverability literature; it isn't a guarantee, but it's the right order of magnitude.
Math: volume_per_tenant × tenants × spam_fold% × €0.04 (avg gross-margin per delivered email for transactional SaaS) × (recovery_days / 30). Order-of-magnitude — substitute your own per-email value if known.
A per-tenant isolation architecture caps that figure at the affected tenant's individual exposure — typically two to three orders of magnitude lower. That's the case for getting the architecture right before the first incident, not after.
Three real patterns. We support all three. The right one depends on your tenant mix.
There's no universal right answer, but there are three answers we see most often, and the choice usually correlates with tenant maturity, regulatory exposure, and how much variance exists across your customers' sending behaviour.
Shared IPs across all tenants, segmentation by domain
All tenants share one IP pool. Per-tenant subdomains and DKIM keys provide the only isolation. Cheapest to operate, weakest containment.
- Best for
- Early-stage SaaS, low-volume tenants
- Cost
- Lowest
- Blast radius
- Entire platform
A single bad tenant takes the pool down. Acceptable risk only when you can vet tenants tightly or your aggregate volume is small enough that you'd survive a brief outage.
Tiered: standard tenants on a pool, premium tenants on dedicated IPs
Default tenants share a pool; tenants who pay for the premium tier (or who exceed a volume threshold) get a dedicated IP. The dominant pattern in 2026 mature SaaS.
- Best for
- Mid-stage SaaS with volume variance
- Cost
- Moderate, scales with premium tenants
- Blast radius
- Pool tenants only (premium isolated)
Premium isolation as a paid feature aligns the cost with the customer who values it. Pool tenants still share fate, so abuse detection has to be sharp on the pool side.
Dedicated IP per tenant from the entry tier — full isolation
Every tenant gets their own dedicated IP (or pair) plus their own subdomain plus their own DKIM keys. The blast radius for any incident is one tenant.
- Best for
- Compliance-heavy SaaS (banks, health, public sector)
- Cost
- Higher per tenant; lower per incident
- Blast radius
- Single tenant
Pricing has to absorb the per-tenant cost, which means this pattern only works for SaaS targeting mid-market and up. Below ~$500/mo per tenant, the math gets uncomfortable.
SaaS-on-behalf sending compared, April 2026
| Provider | Per-tenant isolation primitive | Auto-pause on bad tenant | EU operator | Dedicated IP from |
|---|---|---|---|---|
| Authorize Hosting Stockholm, since 2003 | Per-tenant subaccount + dedicated IP pool, configurable from 1 IP per tenant up to N pools. Reputation isolated by both IP and subdomain. | Yes — operator team plus automated rate limiting on the affected tenant only | Yes — Stockholm + Frankfurt | Entry plan (€399/mo, 10 dedicated IPs included) |
| Amazon SES Tenants launched Aug 2025 | Tenants feature: up to 10K (default) or 300K (on request) isolated tenants per account. Each tenant has own identities, configuration sets, IP pools. | Yes — Standard / Strict / None reputation policies, automatic pause on findings | Depends on AWS Region. EU regions exist; AWS is a US operator legally. | $24.95/IP/mo add-on; one IP per ~50K daily emails recommended |
| SendGrid (Twilio) acquired 2019 | Subusers (up to 25K) and "teammates" with scoped credentials | Manual via dashboard; no auto-enforcement at subuser level by default | No — US operator (Twilio) | 100K+ tier ($89.95/mo) plus IP add-on; free tier eliminated May 27 2025 |
| Mailgun (Sinch) acquired 2021 | Subaccounts on Scale plan; per-domain segregation otherwise | Webhooks for spam complaints; enforcement is operator-side | No — Swedish parent (Sinch), US ops | Scale plan ($90/mo+) plus $59/IP/mo |
| Postmark (ActiveCampaign) acquired May 2022 | Multi-server architecture; Message Streams isolate transactional from broadcast | Strict pre-approval; broadcast and B2B profiles flagged at vetting time | No — US operator (ActiveCampaign) | $50/IP/mo with 300K minimum monthly volume per IP |
| Self-hosted PowerMTA commercial license | vMTAs and IP pools with full operator control. Most flexible primitive available. | Whatever you build — there's no managed product | Wherever you host | License $40K/year + hardware + ops salary (~$80K/yr loaded) |
Pricing and feature data verified against vendor pages April 2026. SES Tenants product details from AWS launch posts (August 2025 and follow-up November 2025). SendGrid free-tier elimination announced and effective May 27 2025. Mailgun pay-as-you-go pricing doubled December 2025.
The actual stack underneath your SaaS platform
The product underneath a multi-tenant SaaS engagement with us is the same operator-managed PowerMTA stack we ship for any other dedicated-infrastructure customer, configured for the multi-tenant case. The pieces:
- Per-tenant vMTA configuration Each tenant maps to one or more virtual MTAs in PowerMTA. Each vMTA has its own outbound IP allocation, its own per-receiver rate-limit profile, and its own bounce-classification tree. Reputation telemetry is collected per-vMTA, not per-account.
- Subdomain + DKIM key per tenant Tenants send from
acme.platform-mail.comor their own domain delegated to us. DKIM keys are generated per tenant. The 2024 Gmail/Yahoo enforcement and 2025 Microsoft rules were built around domain-level signals; the architecture leans into that. - Reputation policy engine Per-tenant thresholds for complaint rate (default 0.1% target, 0.3% hard pause), bounce rate, and DNSBL listings. When a tenant trips a threshold, that tenant is paused. Other tenants on the platform are unaffected. The operator desk gets paged.
- FBL ingestion per IP Yahoo, AOL, Hotmail, Microsoft 365, La Poste, Comcast feedback loops are registered per allocated IP. Complaints are routed back to the originating tenant — not aggregated globally — so abuse detection has the right signal at the right granularity.
- Daily Spamhaus + DNSBL monitoring Each allocated IP is checked against 50+ DNSBLs daily. Listings are remediated by us, not by you. The remediation work — the SBL ticket, the CSS request, the email to delisting@ — is what we do; you don't rebuild that capability internally.
- Operator escalation channel When a real incident hits — tenant gets compromised, an IP is blocked at Microsoft, Spamhaus lists a /24 — there's a Stockholm phone number and a Slack channel that goes to humans who do this for a living. Not a ticket queue with SLAs that look good on the contract page.
How a multi-tenant SaaS engagement is typically priced
SMTP Relay base + per-tenant IPs
The starting setup for SaaS platforms with single-digit-million aggregate volume. Our SMTP Relay Pro base (€749/mo, 20 dedicated IPs, 5 domains) gives you the operator infrastructure; we allocate IPs against tenants as you onboard.
See SMTP RelayManaged PowerMTA Pro
Where most multi-tenant SaaS engagements land. Pro tier (€1,499/mo) includes the PowerMTA license, a Xeon Gold 6326 server, 64GB ECC RAM, 20 dedicated IPs, 150K msg/hr throughput. We map tenants 1:1 or 1:N onto vMTAs based on volume.
See Managed PowerMTACustom Enterprise
Above 50 million aggregate per month, the conversation starts with the actual tenant distribution: 80/20 fat-tailed, evenly distributed, growing fast — these shapes lead to different IP allocation strategies. Custom quote based on real numbers.
Talk to an operatorWhat multi-tenant SaaS teams ask before moving
Can we onboard tenants programmatically, or is each one a manual provisioning step?
+
Programmatic. Tenant creation, IP allocation within an existing pool, DKIM key generation, and subdomain routing all happen via our control API. The first ten tenants are typically set up together with our team to validate the integration shape. After that you provision against the API on your own and we get notified when the count crosses the next IP-allocation threshold.
What happens when a tenant's reputation tanks at 2am on a Sunday?
+
Automated rate limiting on that tenant's vMTA kicks in within minutes — based on the complaint-rate, bounce-rate, or DNSBL-listing thresholds you configured during onboarding. The Stockholm on-call rotation gets paged with the tenant ID, the trigger, and the current state. The other tenants on your platform see no impact.
If the trigger is a transient blocklist (CSS often resolves itself within 24-48 hours), we typically wait it out and document the cause. If it's a real abuse incident — purchased list, compromised account — we work with you on the tenant-level remediation. Operator response, not a ticket bot.
How does pricing scale as we add tenants? Is it a per-tenant fee?
+
No per-tenant fee. Pricing scales with infrastructure: how many IPs, how many domains, how much PowerMTA throughput. The Pro plan at €1,499/mo includes 20 dedicated IPs and 150K msg/hr; Enterprise at €2,799/mo includes 30 IPs and 500K msg/hr. The price doesn't move whether you're allocating those IPs against 50 tenants or 500. Above ~30 IPs we move to a custom quote where we discuss the tenant shape.
We're already on Amazon SES Tenants. Is there a reason to migrate?
+
SES Tenants is a real product. If you're happy with the AWS jurisdiction posture, the per-IP add-on pricing, and the support model (forums and documentation, with paid Enterprise Support if you want a person), staying is a defensible choice. The conversations we end up having with SES Tenants customers are usually about EU operator residency for procurement reasons, predictable EUR pricing without IP add-ons, or wanting an actual human to call when something goes wrong. If none of those apply to you, we'd say so.
Can our customers use their own custom sending domains?
+
Yes. Custom domains delegated to us via CNAME (typical for SPF and DKIM record provisioning), with full DMARC alignment. Many SaaS platforms run two patterns simultaneously: tenants on a platform-owned subdomain for the casual case, and tenants who care enough to set up their own domain for the premium case. Both patterns work; pricing doesn't change.
What's the migration path from SendGrid Subusers or Mailgun Subaccounts?
+
Two-week parallel run is typical. Week 1: dual-send through both providers for the same tenants, comparing deliverability metrics by receiver. Week 2: cut over the easy tenants while keeping the riskier ones (high volume, bad reputation history) on the old provider for one more cycle. By week 3 most platforms have moved fully and are off the old contract by month-end. The IP warmup is what dictates pace — new dedicated IPs need 14 to 28 days before they carry full volume, and that's not negotiable with the receivers.
What does GDPR look like with tenant email content?
+
We're the processor; you're typically the controller (with your tenants as either downstream controllers or downstream processors depending on your contract structure). Our standard DPA is a sub-processor agreement built for that pattern. Message logs are retained for 90 days by default; longer retention for compliance reasons is a configuration option. EU data centres are the default — Stockholm primary, Frankfurt secondary. The data does not leave the EU unless your contract explicitly opts into it.
The architecture conversation is the right next step
Tell us your tenant count, your aggregate volume, your current provider, and the rough shape of your customer mix. We'll come back with a sized configuration and a migration plan, not a contact-sales placeholder.