Email agencies — service providers managing sending operations for multiple clients simultaneously — face a deliverability challenge that individual programme operators do not: reputation contamination between clients. When Client A's poor campaign quality degrades the shared IP pool's reputation, Client B and Client C's campaigns suffer the delivery consequences despite having nothing to do with Client A's quality event. Solving this isolation problem without requiring a completely separate infrastructure stack per client is the central architectural challenge of multi-client email service provision.
The Core Agency Problem: Client Reputation Isolation
The agency reputation isolation problem has two dimensions: IP-level and domain-level. IP-level contamination occurs when multiple clients share the same sending IPs — a complaint spike from Client A's campaign produces a reputation signal on the shared IP that affects ISP rate limits and spam scoring for all subsequent sends from that IP, including Client B's and Client C's campaigns. Domain-level contamination occurs when multiple clients share a signing domain — Postmaster Tools attributes all reputation signals from the shared domain to a single domain reputation history, making it impossible to distinguish which client's behaviour drove a reputation change.
Complete isolation — separate IPs and separate signing domain per client — eliminates both contamination vectors but requires significant infrastructure investment at low client volumes. A practical intermediate approach: tier clients by volume and risk level, applying full isolation only above the volume and risk threshold that justifies the cost, and applying shared-pool arrangements with quality gates for smaller clients below the threshold.
| Client tier | Monthly volume | IP arrangement | DKIM domain | Postmaster Tools |
|---|---|---|---|---|
| Tier 1 — Enterprise | >2M messages | 4+ dedicated IPs | client.com (own) | Separate property per client |
| Tier 2 — Mid-market | 500K–2M | 2 dedicated IPs | client.com (own) | Separate property per client |
| Tier 3 — SMB | 50K–500K | Shared pool (quality-gated) | mail.client.com (agency subdomain) | Shared property, client-tagged |
| Tier 4 — Starter | <50K | Shared pool | Agency signing domain | Shared property |
VMTA-per-Client Architecture in PowerMTA
PowerMTA's Virtual MTA (VMTA) system is the mechanism that enables multi-client isolation on a single MTA instance. Each VMTA has its own IP bindings, DKIM signing configuration, per-domain connection limits, and queue management settings — making a VMTA functionally equivalent to a dedicated MTA for the client it serves, while sharing the underlying operating system and PowerMTA licence with all other VMTAs.
The per-client VMTA configuration in PowerMTA's config file:
<virtual-mta clienta-vmta> smtp-source-host 203.0.113.10 clienta-mail1.brand.com smtp-source-host 203.0.113.11 clienta-mail2.brand.com dkim-sign domain=clienta.com selector=mail key=/etc/pmta/dkim/clienta.com/mail.pem max-smtp-out 20 for gmail.com max-smtp-out 12 for outlook.com max-smtp-out 15 for yahoo.com </virtual-mta> <virtual-mta clientb-vmta> smtp-source-host 203.0.113.20 clientb-mail1.brand.com smtp-source-host 203.0.113.21 clientb-mail2.brand.com dkim-sign domain=clientb.com selector=mail key=/etc/pmta/dkim/clientb.com/mail.pem max-smtp-out 15 for gmail.com max-smtp-out 10 for outlook.com </virtual-mta>
The injection API (or SMTP submission from the client's campaign platform) specifies which VMTA to use for each injection, ensuring that Client A's campaigns are always routed through clienta-vmta and never contaminate Client B's traffic. The routing is enforced at the VMTA-selection level in the injection configuration — not at the campaign level, where human or software error could route traffic incorrectly.
IP Pool Strategy for Multi-Client Operations
The agency IP pool strategy must balance three competing concerns: isolation quality (more IPs per client = better isolation), cost efficiency (more IPs = higher hosting cost), and warmup feasibility (each new IP requires 8-10 weeks of warmup before it can carry full production volume). The practical resolution: size IP pools by client tier and volume, with quality gates that prevent lower-tier clients from contaminating shared resources.
For Tier 1 and 2 clients with dedicated IP pools, the pool sizing follows the same per-ISP calculation used for any dedicated infrastructure programme: required messages per hour ÷ per-ISP effective rate per IP = minimum IPs per ISP. The binding constraint ISP determines the total pool size. For a Tier 2 client sending 1M messages per month across a 4-day weekly cadence (250,000 messages per send, 6-hour delivery window), the Gmail calculation: 250K ÷ 6h = 41,667/hour; at High reputation 15 concurrent connections per IP delivering 200 msg/session every 3 minutes ≈ 60,000/hr/IP → 1 IP sufficient for Gmail. Microsoft at lower rate limits requires 2-3 IPs. Pool size: 3 IPs covers the binding constraint.
For shared-pool Tier 3 and 4 clients, quality gates prevent poor-quality clients from contaminating the pool: (1) maximum hard bounce rate per campaign of 0.5% before the campaign is paused and the client is required to clean the list; (2) maximum spam complaint rate of 0.05% per week across all sends; (3) mandatory list age verification — no list segment older than 12 months without verification. Clients who breach any gate are moved to a quarantine pool separate from the main shared pool until the quality issue is resolved. The quarantine pool protects the main shared pool from contamination while keeping the client's programme operational during remediation.
Per-Client Authentication: DKIM, SPF, DMARC
Authentication configuration for agency clients is more complex than for single-programme senders because each client requires its own authentication records in its own DNS zone — which may be managed by the client's IT team rather than the agency. The agency onboarding process must include a clear authentication setup checklist that the client's DNS administrator can execute, with verification steps that confirm each record is correctly published before the first campaign is sent.
The authentication records that every Tier 1 and 2 client requires: (1) DKIM TXT record: mail._domainkey.clienta.com with the public key generated by the agency for the client's VMTA DKIM configuration. (2) SPF TXT record: updated to include the agency's sending IPs as authorised senders for the client's MAIL FROM domain. (3) DMARC TXT record: at minimum v=DMARC1; p=none; rua=mailto:dmarc@clienta.com — with the reporting address going to the agency for processing (the agency handles DMARC aggregate report review as part of the managed service). (4) PTR records: the agency's IP hosting provider must set reverse DNS for each client's dedicated IPs to hostname values that match the client's domain (clienta-mail1.brand.com or, better, mail1.clienta.com if the client delegates this subdomain).
For Tier 3 clients using agency subdomain signing (mail.clienta-managed.brand.com), the authentication records are in the agency's DNS zone, simplifying the client onboarding DNS requirement. The tradeoff: DMARC alignment requires relaxed alignment mode (aspf=r, adkim=r), which is the default but allows subdomain signing to pass DMARC for the client's From: domain. The client's own DMARC record must be at p=none (not p=reject) for this to work — a constraint that the agency must document clearly in the client onboarding materials.
Monitoring Multiple Clients Simultaneously
Agency deliverability monitoring must cover all clients simultaneously, which means the monitoring infrastructure must aggregate data from multiple Postmaster Tools properties, multiple SNDS IP ranges, and multiple FBL mailboxes into a unified dashboard that surfaces any client's problems immediately — without requiring a separate monitoring session per client.
The technical implementation: a monitoring aggregator script that (1) queries the Gmail Postmaster Tools API for each registered domain (one API call per client domain, runnable in parallel), extracts the spam rate and domain reputation for the past 24 hours, and writes results to a central monitoring database; (2) checks SNDS status for all client IP ranges (one SNDS login per IP range or agency-wide SNDS access for all agency-managed IPs); (3) queries FBL complaint counts per client from the FBL processing database. The combined data feeds a central dashboard that shows a traffic-light status for each client: green (all metrics within targets), amber (any metric approaching threshold), red (any metric breaching threshold).
The amber-to-red escalation alert fires as a Slack message to the agency's deliverability team with the specific client name, the metric that triggered the alert, the current value, and a link to the relevant monitoring tool. The on-call deliverability analyst investigates and determines whether the alert represents an emerging problem (requires immediate action) or a transient spike (monitor for 24 hours). Documenting this investigation and its outcome in the client's incident log builds the historical record that makes subsequent similar incidents faster to diagnose and resolve.
Metering and Billing by Client from the Accounting Log
The PowerMTA accounting log records every delivery event with the VMTA used for that event — making it the authoritative data source for per-client message metering and billing. An ETL pipeline that processes the accounting log daily, extracts per-VMTA delivery counts, and writes them to a billing database provides the data for accurate per-client invoicing without manual counting or reliance on application-layer metrics that may not capture all message events.
The billing data extracted from the accounting log per client per billing period: messages injected (total injection events per VMTA), messages delivered (250 OK response count per VMTA), messages deferred at expiry (messages that reached queue-life without delivery), messages hard bounced (permanent 5xx responses per VMTA), and FBL complaints received (per-client complaint count from the FBL processing database). This data supports multiple billing models: per-message delivered, per-message injected, or a hybrid flat-fee-plus-overage model based on delivered message counts.
The accounting log billing pipeline also provides the performance data for client reporting: per-campaign delivery rate, per-ISP delivery breakdown, per-campaign hard bounce rate, and per-ISP deferral rate — all extracted from the same per-event accounting log data that drives the billing calculation. Clients receive accurate performance data derived from authoritative infrastructure-level events rather than from application-layer reporting that may be incomplete or inaccurate.
Client Onboarding and Warmup Workflow
Agency client onboarding requires a structured sequence that establishes the technical infrastructure, authentication records, and warmup schedule before any production traffic is routed through the new client's VMTA and IP pool. Skipping steps — particularly authentication verification and warmup — produces deliverability problems in the first weeks of client operation that reflect poorly on the agency and require recovery effort that the client's first impressions cannot afford.
▶ Agency Client Onboarding Checklist
Incident Response When One Client Affects Others
Despite isolation architecture, incidents can still propagate between clients in a multi-client environment — particularly when clients share any infrastructure component (shared pool for Tier 3/4 clients, shared monitoring infrastructure, shared FBL processing endpoint). When an incident affects one client and potentially contaminates shared resources, the agency's incident response must simultaneously protect the affected client, protect other clients from contamination, and diagnose the root cause.
The agency incident response protocol for shared-pool contamination: (1) Immediately identify which client's traffic generated the incident signal — per-VMTA accounting log query for the incident period. (2) Move the offending client's VMTA to the quarantine pool, stopping further contamination of the shared pool. (3) Assess contamination level — has the shared pool's SNDS status changed or the Postmaster Tools shared domain reputation dropped? If yes, pause all shared-pool client sends pending assessment. (4) Notify affected clients with a factual description of the incident and the containment actions taken. (5) Investigate the root cause of the offending client's quality event — list quality, authentication failure, content issue — and implement the fix before restoring the client to the standard pool.
The agency that handles this protocol transparently — notifying affected clients promptly, explaining the containment actions, and demonstrating that the isolation architecture minimised the blast radius — builds the trust that multi-client operations require. Clients whose campaigns were protected by the isolation architecture because the quarantine system worked correctly have direct evidence of the value the agency's infrastructure investment provides. That evidence is the most compelling marketing for the agency's technical capabilities that any case study could provide.