Email marketing agencies face a deliverability challenge that no single-brand sender encounters: managing the reputation risk of multiple clients on shared or semi-shared infrastructure, where one client's poor list quality, complaint spike, or spam trap hit can damage the infrastructure that serves all other clients. The agency's infrastructure is simultaneously the most commercially flexible arrangement (shared infrastructure is cheaper than dedicated per-client infrastructure) and the highest reputation risk configuration (one bad actor contaminates everyone). This guide covers the architectural and operational practices that allow agencies to serve multiple clients with reliable, isolated deliverability at commercial scale.
The Core Agency Deliverability Challenge
The agency deliverability problem is fundamentally different from a brand's deliverability problem. A brand controls the list quality, content quality, and sending frequency for its single sending programme — the only sender making reputation decisions is the brand's own team. An agency manages 10, 50, or 200+ client sending programmes simultaneously — each client making their own list quality and content decisions, each potentially exposing the shared or adjacent infrastructure to their specific reputation risks.
The risk cascades that agencies must prevent: (1) Client A runs a purchased list acquisition campaign that generates complaint rates above 0.20%. If Client A's sends share IP addresses with Clients B and C, the complaint rate impacts the shared IPs' reputation at Gmail SNDS and Postmaster Tools — potentially damaging Clients B and C's inbox placement for campaigns they deploy in the same week. (2) Client D imports a list with a Spamhaus spam trap address. If Client D's sends share an IP with Client E, the spam trap hit may trigger a Spamhaus SBL listing for the shared IP — blocking Client E's campaign deployment for 1-3 weeks while the listing is resolved. (3) Client F's domain experiences a DMARC alignment problem after a DNS change. If the agency manages Client F's authentication, the authentication failure affects all sends from Client F's domain until the issue is diagnosed and fixed — regardless of what other clients are doing.
Per-Client IP Isolation Architecture
The gold standard for agency email infrastructure is per-client IP isolation — each client's sending programme uses dedicated IP addresses that carry only that client's reputation signals. A complaint spike from Client A's campaign affects only Client A's IPs, leaving all other clients' IPs with their established, unaffected reputation history.
Per-client IP isolation pricing reality: dedicated IPs from major ESPs (SendGrid, Mailgun) cost $20-30/month per IP. For small clients sending 50,000 messages per month, two dedicated IPs add $40-60/month to the infrastructure cost — representing 40-80% of the entire infrastructure cost for a small client. The per-client IP investment makes financial sense for clients above approximately 100,000 monthly messages, where the infrastructure cost is proportional to the sending volume and the deliverability benefit justifies the cost.
For small clients below the per-client IP threshold: pool clients by risk profile (list quality tier, complaint rate history) rather than random pooling. High-quality clients (permission-based lists, consistent low complaint rates, verified email acquisition) share a "premium" IP pool. New or unverified clients (first campaign, unknown list quality) share a separate "onboarding" IP pool. Low-quality or problem clients (repeated complaint issues, purchased lists) are isolated on their own IP pool separate from all other clients. This tiered pooling limits the blast radius of any single client's reputation problem — a problem in the onboarding pool does not affect the premium pool.
PowerMTA VMTA Architecture for Agencies
PowerMTA (Port25's commercial MTA) is the industry standard for agency email infrastructure because its VMTA (Virtual MTA) architecture provides per-client IP isolation within a single server installation. Each VMTA has its own: IP address (or multiple IPs), DKIM signing configuration, accounting log file, rate limits and retry configuration, and bounce processing settings. Multiple VMTAs run on the same physical server — the server handles all clients' email, but each client's sending is logically isolated within its own VMTA configuration.
# PowerMTA config: per-client VMTA architecture # /etc/pmta/config # Client A: premium list quality, 3 dedicated IPs <virtual-mta clientA> smtp-source-host 203.0.113.10 mail1a.agency.com smtp-source-host 203.0.113.11 mail2a.agency.com smtp-source-host 203.0.113.12 mail3a.agency.com dkim-sign domain=clientA.com selector=agency2027 key=/etc/pmta/keys/clientA.com.key bounce-handling on bounce-action pattern=5xx suppress </virtual-mta> # Client B: new client, single IP in onboarding pool <virtual-mta clientB-onboarding> smtp-source-host 203.0.113.50 onboard1.agency.com dkim-sign domain=clientB.com selector=agency2027 key=/etc/pmta/keys/clientB.com.key max-smtp-out 5 # Conservative during warmup </virtual-mta> # Source routing: send each client through their VMTA <source 10.0.0.100> # Client A's submission IP virtual-mta clientA </source>
The PowerMTA VMTA architecture provides the per-client isolation that makes it the technical foundation for serious agency email infrastructure. Each client's accounting log is separate — billing, deliverability diagnosis, and complaint analysis are per-client by default. Each client's IP reputation history is isolated — Client A's complaint event appears only in Client A's VMTA's IP reputation, not in Client B's. When Client A has a reputation problem, the agency can quarantine or rotate Client A's IPs without touching Client B or C's configuration.
Client Authentication Setup and Domain Management
Every client sending programme must use the client's own domain for DKIM signing — not the agency's domain and not a generic shared signing domain. This is a non-negotiable requirement for both MAGY compliance and for domain reputation to accumulate under the client's own domain. The agency's role in client authentication: (1) generate DKIM key pairs for each client domain, (2) provide DNS records for the client to publish (or publish them directly if the agency manages client DNS), (3) verify authentication is correctly configured before any campaign is deployed, and (4) maintain DKIM key rotation on the client's behalf annually.
SPF management for agency clients: Each client's SPF record must include the agency's sending infrastructure as an authorised sender. The agency provides a standard SPF include mechanism that covers all IPs in the relevant IP pool: include:spf.youragency.com. The agency maintains the SPF record at spf.youragency.com with all current sending IPs — clients add one include to their own SPF records rather than managing the full IP list themselves. When the agency adds new IPs or migrates infrastructure, clients' SPF coverage updates automatically through the agency's SPF record.
DMARC for clients: The agency should assist every client in publishing a DMARC record and advancing to p=quarantine or p=reject. Provide DMARC aggregate report processing as a service — most clients cannot interpret DMARC XML reports without assistance. Offer a dashboard view of each client's DMARC authentication pass rate and any sources generating authentication failures. DMARC enforcement at p=reject provides the anti-spoofing protection that is increasingly expected of commercial senders and the inbox placement benefit that enforcement-level DMARC provides at Gmail and Microsoft.
Reputation Monitoring Across Multiple Client Accounts
Agency reputation monitoring must cover every client simultaneously — a reputation event with Client F that goes undetected for 48 hours causes 2 days of degraded inbox placement for Client F and potentially for other clients sharing adjacent infrastructure. The monitoring infrastructure for an agency serving 20+ clients:
Unified monitoring dashboard: A single operational view showing all client domains' Postmaster Tools spam rate, SNDS IP status for all active IPs, and blacklist status for all sending IPs. Commercial tools that support multi-domain monitoring: MXToolbox Monitor, Validity Everest (multi-domain edition), and custom dashboards built on Postmaster Tools API data. The dashboard alerts on any metric crossing threshold — not just the most recently active client's metrics.
Per-client Postmaster Tools accounts: Register each client's sending domain in Gmail Postmaster Tools under a separate Google account that the agency manages on the client's behalf. This provides per-client Gmail spam rate and domain reputation data that would not be visible if all clients' sends appear only under the agency's sending domain (which they should not — each client signs with their own domain).
Automated SNDS monitoring: Register all sending IPs across all client VMTA pools in Microsoft SNDS. Query SNDS daily via the SNDS data download API. Alert on any IP transitioning to Yellow (warning level) or Red (blocked level). Per-client IP isolation means a Yellow SNDS status on Client C's IPs is immediately identifiable as Client C's problem — without per-client isolation, a Yellow status on a shared pool IP requires investigation to identify which client's sends generated the issue.
Client Onboarding and Warmup Protocol
Every new client account must complete an IP warmup before being promoted from the onboarding IP pool to the premium pool and before full-volume campaign deployment. This is non-negotiable regardless of client urgency or campaign deadline pressure — deploying a full-volume campaign from a cold IP causes reputation damage that takes weeks to resolve and affects the client relationship more severely than a 6-8 week warmup delay.
The agency client onboarding warmup protocol: (1) Verify client authentication — DKIM, SPF, DMARC — before any sends. (2) Run client's email list through verification to establish baseline list quality. Any client list with hard bounce rate above 2% in verification must be cleaned before warmup begins. (3) Begin warmup at 500-1,000 messages/day to the client's highest-engagement segment. (4) Scale per the warmup schedule over 6-8 weeks. (5) Monitor daily for Postmaster Tools spam rate and SNDS status on the warmup IPs. (6) At warmup completion criteria (Gmail High reputation, SNDS Green for 14+ days), transfer client to premium pool and full campaign deployment. The warmup period is also the optimal time to identify any list quality issues — complaint or bounce problems at warmup volume are far cheaper to discover and fix than at full campaign volume.
Incident Isolation: Containing One Client's Problem
When a client experiences a reputation event (complaint spike, blacklist listing, Postmaster Tools Low reputation), the agency must be able to contain the problem to that client's infrastructure without affecting other clients. The per-client VMTA architecture enables this containment at the IP level — the affected client's VMTAs can be quarantined (suspended from active sending) while their problem is resolved, without touching any other client's VMTA configuration.
The incident response protocol for a client reputation event: (1) Identify the affected client and affected sending IPs from the monitoring dashboard alert. (2) Pause all ongoing sends from the affected VMTA — no new injections, no queue processing. (3) Notify the client: specific problem identified, sends paused, investigation in progress. (4) Diagnose root cause from the client's accounting log and complaint data. (5) Implement fix (list cleaning, suppression of complaining addresses, removal of purchased segments). (6) Resume sends at reduced volume on the affected IPs — or migrate to new IPs if the existing IPs have been listed on a blocklist that requires extended recovery time. (7) Monitor recovery — restore full volume only after 14+ days of sustained below-threshold complaint rate on the recovered IPs.
The client service agreement must specify: the agency's right to pause client sends in response to reputation events, the client's obligation to provide list quality documentation on request, the client's obligation to comply with list quality standards (no purchased lists, no co-registration without verification), and the client's acknowledgement that reputation events may require warmup recovery periods before full volume is restored. These provisions protect both the agency (from clients who deny agency authority to pause during incidents) and the other clients (by establishing the framework for incident isolation as a contracted right).
Agency Reporting and Volume-Based Billing
The PowerMTA accounting log provides the per-client delivery data needed for transparent billing and client reporting. Each client's accounting log file records every injection event with the client identifier — billing is based on injected messages (what the client submitted for sending) rather than delivered messages (which excludes bounces that are outside the agency's control).
Per-client deliverability reporting provides each client with: monthly inbox placement rate (from seed testing on a representative campaign), Gmail Postmaster Tools spam rate trend, hard bounce rate per campaign, complaint rate per campaign, and SNDS status history. This data gives clients visibility into the deliverability investment's commercial impact and creates the transparency that justifies the agency's infrastructure investment to clients who might otherwise see deliverability management as overhead rather than commercial return.
Agency email infrastructure done right — per-client IP isolation, systematic warmup, unified monitoring, and documented incident protocols — is the foundation that allows the agency to scale its client roster without reputation risk compounding proportionally with client count. The investment in isolation and monitoring architecture is the investment that makes the agency's email services reliably excellent regardless of client list quality variation — which is the operational foundation that differentiates excellent email agencies from average ones in the increasingly competitive email marketing agency market.