Every client isolated, every result provable.

When you send for clients, deliverability stops being a technical metric and becomes the thing the relationship is judged on. A client does not see your virtual MTA configuration; they see whether their campaign reached inboxes and what it did for them. That shifts the stakes: a deliverability problem is no longer merely an engineering ticket, it is an account at risk. And the risk runs in both directions — one client with a poorly maintained list can drag down the reputation that your other clients depend on, so the cost of a single bad sender is paid by your whole book of business.

That is why the agency setup is built around two ideas the rest of this page expands: isolate every client so their reputations never touch, and prove results with real numbers so the relationship rests on evidence rather than reassurance. PowerMTA, automated by the Configurator, gives you the mechanism for both — the isolation through IP groups and per-domain signing, the proof through per-client visibility. The work that is specific to agencies is the part the engine does not do for you: authenticating domains you do not own, onboarding and offboarding clients cleanly, and deciding who owns what when an account moves on.

Reputation at the mailbox providers attaches to the sending IP and the signing domain, so the way to keep clients from affecting each other is to give each one its own. In PowerMTA that means assigning every client a virtual MTA and its own IP group, so the addresses a struggling client sends from are not the addresses a healthy client relies on. When one client's complaint rate climbs, the damage is contained to that client's IPs instead of bleeding across the agency. The Configurator layers per-domain IP-group rotation with automatic failover on top, so a degrading address does not strand a client mid-campaign.

For an agency, isolation also has a commercial shape. A larger client sending steady volume justifies its own dedicated IPs, where the reputation is unambiguously theirs and easy to report on; a set of smaller clients usually shares a warmed pool, trading a shared reputation for not having to sustain dedicated addresses each. The dedicated versus shared IP guide covers where that line sits. Giving each client a distinct sending subdomain matters too, because it keeps the DMARC identity separate — a reputation issue lands on the client's own mail.theirdomain.com rather than on anything shared, which is exactly the separation you want when accounts come and go.

The authentication problem that is unique to agencies is that the domain belongs to the client, not to you. You need their mail to pass SPF, DKIM and aligned DMARC under their own From domain, but you do not control their DNS. The clean way through is delegation: the client publishes a small set of records once, and you manage the signing behind them. For DKIM that usually means a CNAME pointing at a selector you control, so you can rotate keys without asking them again:

Alignment is what makes this count: the DKIM d= has to match the client's visible From domain, and the SPF return-path should sit on an aligned bounce subdomain of theirs, because DMARC only credits a mechanism that aligns with the From. Get it right and the client's mail clears Gmail's 5.7.26, Yahoo's 5.7.9 and Microsoft's 5.7.515 authentication checks; get it wrong for one client and only that client bounces. Across dozens of client domains this is exactly the work that is error-prone by hand, which is why the Configurator publishes the records through the SPF/DKIM/DMARC setup over the Cloudflare API where you manage the zone, and the generator drafts them per client where you do not.

For an agency, the report is part of the product. Clients are paying for results they cannot see directly, so the ability to show where their mail actually landed is what separates a credible agency from one asking to be trusted. The Configurator's real-time dashboard breaks delivered, deferred and bounced volume down per client stream, so you can show a client their own numbers rather than a platform average. A point-in-time deliverability audit complements that with something shareable — a snapshot of authentication, placement and reputation a client can hold onto.

The discipline is in what you report and how you frame it. Inbox placement, bounce and complaint trends, and authentication status are the figures that mean something to a client; raw send counts are not. Setting expectations early — that recovery from a reputation dip takes days of clean sending, that a provider's spam-complaint threshold is unforgiving — turns deliverability from a mystery the client blames you for into a shared, measured process. When a stream does degrade, seeing it live in the dashboard lets you act before the client notices, which is the difference between a quiet fix and an awkward conversation. A listing that appears is caught quickly by blacklist monitoring rather than discovered from a stalled campaign.

Agencies win and lose clients, so the lifecycle matters as much as the steady state. Onboarding by hand — config, keys, DNS records, a bounce subdomain, IP assignment, a warm-up plan — is slow and easy to get subtly wrong, and a single missed record produces bounces days later. The Configurator turns it into one command per client: the per-client config, the Cloudflare DNS setup, the IP-group assignment and the warm-up schedule through provider APIs, so a new account starts sending safely instead of being throttled on day one.

Offboarding is the part agencies forget until it is urgent. When a client leaves, their sending should stop cleanly, their dedicated IPs should be retired or reassigned rather than left to decay, and the authentication records in their DNS should be handed back or removed so nothing keeps signing in their name. Because isolation lives in pools and per-domain signing, retiring one client touches only their footprint and leaves every other client untouched. Treating offboarding as a defined step — not an afterthought — is what keeps a departing account from becoming a stale, half-configured liability on your platform.

A question worth settling at the start of each engagement is who owns what. The client's domain and its DNS stay with the client — you manage records through delegation, but the domain is theirs, which is correct and also protects you when the relationship ends. The sending IPs are usually yours, part of the infrastructure you operate, which means a client's reputation is built on addresses you control and can reassign. That arrangement is clean as long as everyone understands it: the client owns their identity and their lists, you own and operate the sending platform, and the authentication is delegated rather than handed over.

Spelling this out avoids the two arguments agencies actually have. The first is at handover, when a client leaving wants to take "their" deliverability with them — easy to resolve when it was clear from the outset that the domain and lists are theirs and the platform is yours. The second is blame during a dip, which a shared, reported set of numbers defuses far better than competing assertions. Governance like this is unglamorous, but it is what lets an agency grow its client count without each new account adding ambiguity.

Plenty of agencies are excellent at the client relationship and the creative work, and have no wish to operate a mail server. That is a legitimate choice, and it is what the managed service is for: we run PowerMTA or KumoMTA for you — provisioning, warm-up, monitoring and delisting — while you keep the client relationship and the reporting. If you are moving off another platform, a migration brings your clients across without losing warmed reputation, and a one-time setup stands the platform up if you would rather own the operation afterward.

The honest version of the decision turns on scale and appetite. An agency with a handful of low-volume clients may find a hosted sending platform or API simpler than running an engine, and there is no shame in starting there; the economics and the control of running your own PowerMTA or KumoMTA assert themselves as the client count and volume grow, the same threshold the Configurator-vs-DIY-vs-SaaS comparison works through. What does not change is that sending for clients raises the consent bar rather than lowering it — which is where the next note comes in.

Each mailbox provider meters how much it accepts from a given IP, and your traffic to Gmail or Microsoft is the sum of every client sending at once. A dozen small clients that each look harmless can, together, push a provider hard enough to trigger deferrals that affect all of them. PowerMTA handles this with per-provider throttling driven by MX rollup pattern lists, which collapse the many hostnames behind a provider into one logical destination you can rate-limit as a whole, and it backs off automatically when a provider signals it is being pushed too hard.

On a multi-client platform the right reading of a temporary 421 deferral is the provider asking you to ease the aggregate pace to that destination, not a fault with any one client. Reserving rate budget by pool matters too, so a client's time-sensitive mail is not delayed because another client is draining a large campaign into the same provider at the same moment. That governance is invisible to the client and decisive for their results.

Authentication proves the message; reverse DNS proves the connection. Every IP a client sends from needs its own PTR record resolving to a sending hostname, with a matching forward record back — the forward-confirmed reverse DNS that Gmail and Microsoft weigh before they even look at the message. It is per-address work, set at the host that owns the IP rather than at any domain's registrar, and a new client IP that arrives with a generic provider hostname quietly undercuts that client's delivery until someone notices.

The habit that prevents it is to treat reverse DNS as part of bringing any IP online, checked the moment you assign it to a client. The reverse DNS and PTR guide covers the two-way check, and the reverse DNS checker confirms it from outside your network. Across a roster of clients, keeping each IP's PTR, forward record and HELO consistent is the kind of small, repeated detail that separates a deliberate platform from a rented one.

There is a financial reason agencies move to their own engine, more than a technical one. Reselling a hosted platform means a per-message cost that scales straight up with your clients' volume, and a margin that a vendor sets. Running your own PowerMTA or KumoMTA converts that into a largely fixed cost — the licence or the open-source engine, the servers, the IPs — that you spread across every client you send for. Past a certain combined volume the difference is substantial, and it accrues to you rather than to a platform between you and the inbox.

That also gives you a clean way to package tiers. A client on dedicated IPs with its own warmed reputation and detailed reporting is a premium offering you can price accordingly; smaller clients on a shared pool are a lighter tier. Because the isolation and reporting are built into how you send rather than bolted on, moving a growing client from shared to dedicated is a configuration change, not a migration — so your commercial tiers map directly onto the technical setup instead of fighting it. The same holds when a client scales down or pauses: you can move them to a lighter tier without unwinding their authentication, so the relationship can flex with their budget rather than forcing an all-or-nothing decision each time their volume changes.

What a client sees should carry your name, not the name of an engine they have never heard of. The deliverability story you present — the placement figures, the bounce and complaint trends, the authentication status from an audit — is part of how an agency demonstrates its value, so it belongs in your reporting and your language. The underlying engine and the per-client mechanics stay where they should: in the infrastructure you operate, invisible to the client, doing the work that makes the numbers you show them real. That separation, between the technical layer you run and the account layer the client experiences, is the whole shape of an agency that sends well. Presented consistently, under your own brand and your own framing, it also becomes something a prospective client can weigh when choosing you — evidence of competence rather than another vague promise of "great deliverability."

Strip it back and an agency needs four things from its email infrastructure: every client isolated so no one account can harm another, every client domain authenticated and aligned through delegation, results it can prove rather than promise, and a lifecycle — onboarding and offboarding — that stays clean as the roster changes. PowerMTA, automated by the Configurator or run for you as a managed service, gives you all four on infrastructure you control, with margins a hosted platform would take for itself.

The premise underneath it is consent. Per-client isolation, delegated signing and provable reporting are worth building only for sending that is genuinely permission-based, because that is the sending that compounds reputation over time instead of burning through IP ranges. Build on that footing and an agency can take on the next client as a command and a clear agreement, rather than another fragile manual setup.