How a Dutch ESP reseller scaled to 47 enterprise tenants without two FTE deliverability hires
A 4-year partnership covering per-tenant pool isolation, cross-tenant reputation containment, and the operational discipline that made running 47 enterprise outbound flows on shared infrastructure economically viable.
- Tenants on shared infrastructure
- 47 isolated
- pool-per-tenant
- Cross-tenant reputation incidents
- 0/year
- −100%
- Internal FTE required
- 0 FTE
- outsourced
- Aggregate monthly volume
- 180M emails
- 4.6× growth
The challenge
The client operates a campaign management ESP for mid-market Dutch and Belgian enterprises. Their value proposition is the platform layer — segmentation, dynamic content, reporting, integrations with the major CRM and analytics stacks. They are explicitly not in the SMTP engineering business. Until 2022 they had relied on a US-based transactional email vendor for the actual outbound delivery, billing on per-email pricing.
Two pressures pushed them to reconsider. First, per-email pricing scales linearly with success: the more tenants they signed, the more their cost-of-goods-sold rose, eroding margins as they grew. Second, the US-based vendor was treating all of their tenants as a single shared sending pool. When one tenant had a deliverability incident — usually because of a content shift or a list-quality regression on their end — the reputation impact bled into the other tenants on the same pool. Mid-market enterprise tenants do not tolerate "your other clients caused your delivery to drop" as an explanation.
The third issue, less visible, was the operational competence gap. The US vendor offered "shared deliverability support" via tickets, and the response cycle was 24-48 hours. For a tenant whose CRM team was watching real-time campaign delivery dashboards, a 48-hour response cycle on a reputation question was not workable. The client ended up running their own deliverability triage layer on top of the vendor's, which required their support team to understand SMTP issues at a depth they were not staffed for.
The board decision in early 2022 was to outsource SMTP infrastructure to a partner who could deliver three things: per-tenant pool isolation, sub-4-hour response on reputation incidents, and operational discipline (DKIM rotation, BIMI publication, DMARC migration) at the level a high-touch enterprise tenant expects. They went to RFP with seven vendors. We were the smallest of the seven and the only one that proposed pool-per-tenant from the first call.
Approach
The pool-per-tenant architecture sits at the centre of everything else in this engagement. The principle is simple: each tenant gets at minimum a dedicated /29 (8 IPv4 addresses), with the largest tenants getting a /27 or /26. The IPs are not just nominally dedicated — the PowerMTA virtual MTA configuration enforces strict pool boundaries, and the per-tenant accounting database means that one tenant's rate-limit consumption never affects another tenant's sending capacity.
The architecture in 2022 started with two PowerMTA nodes carrying 18 tenants. The capacity model we built showed 22-24 tenants per node as comfortable, with the failover plan being that node A could absorb node B's tenants for up to 4 hours during planned maintenance. By 2024 we were running four nodes and 38 tenants. By 2026 the cluster is six nodes, 47 tenants, with median per-node tenant count at 8 and the largest tenant occupying its own dedicated node.
The reputation containment work — the part that made cross-tenant incidents disappear — is more interesting than the pool architecture. The pool isolation prevents IP-level reputation bleed, but receivers also do per-domain reputation, which means one tenant's sending domains being flagged could affect another tenant if they shared a parent root domain. We avoided that by giving each tenant their own DKIM signing identity, their own MTA-STS policy, and structurally isolating their DMARC reporting flow.
The operational layer is where the partnership actually pays off. We run a 24/7 deliverability operations team across NL and PA office hours, with a 4-hour SLA on reputation incidents (against a 24-48 hour benchmark from the prior vendor). The DKIM rotation cadence is automated — RSA-2048 selectors rotate every 6 months on a staggered schedule across the 47 tenants, with the rotation orchestration handling the in-flight-mail double-publish window. BIMI publication is offered as an add-on for the 11 tenants that have invested in VMC certificates.
Outcome data
Per-receiver and per-week breakdowns from the engagement.
Tenant count and monthly volume growth
Cross-tenant reputation incidents (annual)
Median tenant inbox placement, by receiver (2026)
DMARC policy status across 47 tenants
Technical detail
The PowerMTA configuration uses one virtual-mta-pool per tenant, with hard rate-limit ceilings configured per-pool against the per-tenant accounting database. The vmta entries themselves bind to specific source IPs, ensuring no IP is shared across pools. The global config has typeahead-protect-enabled true so that if a tenant accidentally configures their campaign to source from a different pool's IP, the pmta refuses the request rather than silently bleeding traffic.
The reputation tracking is per-tenant. Each tenant has its own Gmail Postmaster Tools registration (the client provides API credentials during onboarding), its own Microsoft SNDS access, its own Talos polling cadence, and its own bounce-classification dashboard. The aggregate monitoring layer at the cluster level only kicks in for capacity planning and cluster-wide health metrics — it never mixes per-tenant reputation signals.
The DKIM rotation orchestration is worth a paragraph. RSA-2048 selectors rotate every 180 days. The orchestration begins by publishing the new selector's public key in DNS 14 days before the cutover. At cutover, signing transitions from the old selector to the new one. The old selector's DNS record stays published for 14 days post-cutover to handle in-flight mail still under mailing-list forwarding. After 14 days, the old DNS record is removed. Across 47 tenants, that's ~94 rotation events per year, all automated.
BIMI publication is the most operationally complex per-tenant work. Each VMC-holding tenant has their SVG normalised against the BIMI 1.0 spec (no inline scripts, no external references, no animation, square aspect ratio with the proper viewBox). The publication system handles VMC certificate renewal — pulling new intermediates from the issuing CA 30 days before expiry and validating the chain locally before swapping production. The 11 BIMI-enabled tenants have collectively had zero BIMI display interruptions in 2025.
The DMARC migration cadence is staggered. We typically take a tenant from p=none to p=quarantine in months 4-6 of onboarding, after we have a clean parsedmarc baseline of which receivers are reporting and what the legitimate-mail mix looks like. Migration to p=reject is offered as a follow-up engagement at month 10-12, after the quarantine policy has been in production long enough to surface any forwarded-mail edge cases. Of the 47 tenants, 38 are at p=reject as of 2026.
The cluster monitoring stack is Prometheus + Grafana + a custom exporter that translates PowerMTA accounting database fields into Prometheus metrics. The dashboards cover global cluster health (per-node capacity, per-region transit health, per-IP reputation deltas), per-tenant operational metrics, and a synthetic monitoring layer that sends test mail to a basket of external seed addresses every 15 minutes per tenant. The synthetic layer is the early-warning system that catches inbox placement drift before tenants notice it themselves.
Results
Across the four-year partnership, the cross-tenant reputation incident count is zero. Not a single tenant has had their reputation affected by another tenant's sending behaviour. That is the most concrete metric, and the one that comes up first in client conversations.
The economic outcome is harder to put in a single number, but the client's margin per tenant is roughly 3.4× higher than what they were achieving on the per-email-pricing US vendor. That margin improvement funded their 2024 platform investment cycle. They are also able to land enterprise deals (the kind with procurement-driven RFPs) that they could not have credibly pitched before — RFPs that ask "what is your pool isolation model?" go very differently when the answer is "1:1 dedicated pool, contractually" instead of "shared pool, isolated logically."
The aggregate monthly volume across the 47 tenants now sits at 180M/month. Median tenant inbox placement against Gmail is 91%, against Outlook.com 87%, against Yahoo 84%. None of the 47 tenants is currently in a Gmail Postmaster "Low" reputation tier. The DKIM and BIMI operational discipline is, by client sentiment in the most recent quarterly review, the single feature they would not give up if they had to choose.
"The architecture they spec'd gives us per-tenant pool isolation so reputation problems on one tenant do not bleed into the others, and the operational discipline on DKIM rotation, BIMI publishing and DMARC migration is the kind of thing we genuinely could not afford to do in-house at our headcount."
Have a similar engagement?
If this case study describes a problem close to yours, we will give you a 30-minute diagnostic call at no cost — honest read on whether the playbook would translate.