Solutions
PowerMTA, matched to how you send.
The same engine serves very different senders. Pick the use case closest to yours to see the specific pressures it solves and how the Auto PMTA Configurator fits.
PowerMTA is one engine, but the right way to configure it depends on what you send. An ESP juggling many clients, a SaaS company protecting password resets, an agency answering to client reputations, and a publisher pushing a million-recipient edition all need the same correctly-built foundation — and a different shape on top of it. These pages map the four most common patterns to the setup each one needs, all built by the Auto PMTA Configurator or our services, and all for legitimate, opt-in sending.
Start from the use case, not the feature list
The hard questions in email aren't about features — they're about your situation.
Two senders can run the identical PowerMTA build and get very different results, because the decisions that matter are situational. How many separate reputations are you protecting? Does time-sensitive mail share a pipe with marketing it should never touch? Are you answerable for someone else's list quality? Is a single send large enough to trip a provider's rate limits on its own? None of those are answered by a feature checklist; they're answered by knowing who you are and what you're protecting.
That's why these pages are organised by sender rather than by capability. The capabilities — virtual MTAs, IP pools, per-provider throttling, isolation, warm-up — are the same building blocks throughout. What differs is how they're arranged, and getting that arrangement right for your situation is most of the difference between mail that lands and mail that struggles.
For ESPs
Multi-tenant sending across many domains and clients — isolated reputations, per-provider throttling, real-time visibility.
See the solution →For SaaS & transactional
Receipts, resets and verification codes that must reach the inbox — separated from marketing and sized for spikes.
See the solution →For agencies
Sending for clients with each reputation isolated, results proven with real numbers, and fast onboarding.
See the solution →For newsletters & publishers
High-volume editorial sends paced per provider, each title isolated, and the list kept to people who actually read you.
See the solution →ESPs & bulk senders
An email service provider's defining problem is that one server carries many clients, and any one of them can drag the others down. The work is isolation: every client on its own IP group with its own reputation, so a bad list on one account never bleeds into another's deliverability. Layered on that is per-provider throttling for the combined volume hitting Gmail and Microsoft at once, and visibility granular enough to see each client's delivery, bounces and complaints separately. Get the segmentation right and one box runs dozens of senders cleanly; get it wrong and a single client's mistake becomes everyone's problem. The ESP solution walks through how the isolation and routing are built.
SaaS & transactional
For a SaaS product, the email is the workflow — a password reset that lands in spam is a locked-out user and a support ticket, not a marketing miss. The priorities flip accordingly: speed and inbox placement on one-to-one mail matter more than throughput, and transactional traffic has to be kept strictly apart from any marketing the same company sends, so a promotional complaint never taints a receipt. The setup also has to absorb spikes — a launch or an outage notification can send the day's volume in minutes. The SaaS & transactional solution covers the separation and the headroom that protects critical mail.
Agencies
When you send for clients, your reputation rides on theirs, and you have to prove results you don't fully control. That makes three things central: isolating each client so one account's problems stay contained, producing evidence a client can see rather than promises they have to trust, and onboarding the next account quickly because setup is repetitive work. The same per-client isolation an ESP needs applies here, with the added weight of a client relationship on the line. The agency solution details the isolation, reporting and fast onboarding that make client sending defensible.
Newsletters & publishers
Editorial sending lives on two disciplines: pacing a full-list edition so it doesn't trip a provider's rate limits, and keeping the list to people who actually open it, because newsletter reputation is driven by engagement more than almost any other kind of mail. Add bulk-sender compliance — authentication, one-click unsubscribe, a complaint rate kept low — and per-title isolation so a struggling newsletter doesn't drag down the flagship. The publisher solution covers the pacing, isolation and list discipline that keep editions landing.
What every one of them shares
The same foundation underneath
For all the differences above, every one of these setups stands on the same base, and none of it is optional in 2026. Each needs SPF, DKIM and DMARC aligned to the sending domain, valid reverse DNS on every IP including IPv6, TLS and MTA-STS for encrypted transport, honest warm-up on new IPs, and feedback-loop processing with suppression to act on complaints. These are the conditions the major mailbox providers now enforce, and they apply to an ESP and a single SaaS sender alike.
This is the part worth automating once and getting exactly right, because it's identical across use cases and it's where most deliverability problems are born. The Auto PMTA Configurator builds this foundation in the same deterministic deploy whatever your use case, then applies the segmentation — the IP pools, the throttling, the isolation — that your situation calls for on top. You don't rebuild the fundamentals for each sender; you build them right once and shape what sits above them.
How to choose
Pick by what you're protecting
The fastest way to find your fit is to ask what's most at risk. If you're protecting many separate reputations on one platform, you're in ESP or agency territory — the difference being whether those reputations are your own products or your clients'. If you're protecting time-sensitive mail that simply has to arrive, the transactional pattern is yours. If you're protecting the engagement of a large recurring audience, the publisher pattern fits. Most senders recognise themselves in one of the four within a sentence or two.
If you sit across two of them — a SaaS company that also runs a newsletter, say — that's normal, and the answer is usually one server with isolated streams rather than two platforms. And if none of it is obvious yet, a deliverability audit reads your current sending and tells you where you actually stand before you commit to a shape.
One thing the choice is not is permanent. Sending changes — a SaaS product adds a newsletter, an agency takes on a client whose volume dwarfs the rest, a publisher spins up a second title. Because the foundation is identical across all four patterns and the segmentation sits on top of it, growing into a second use case is a configuration change on the same platform rather than a migration to a new one. Picking the pattern that fits today doesn't lock you out of the others tomorrow.
From use case to running platform
Where the Configurator and services fit
Whichever pattern you land on, there are three routes into it, and the choice is about how much you want to operate rather than how your sending is shaped. The Auto PMTA Configurator is the do-it-yourself route: a one-time €799 tool that deploys the foundation and the segmentation your use case needs in a single run, then hands you the operations to run it. It suits teams that want to own the server and the configuration outright.
If you'd rather not run the deploy, the setup service does the build for you on your server and hands it over working, and the managed service runs the platform on an ongoing basis while you keep the sending relationship — a fit agencies and lean SaaS teams often prefer. If you're already sending elsewhere, a migration moves you onto PowerMTA without resetting the reputation you've earned, which matters most for transactional and publisher senders who can't afford a placement dip during the move.
The point is that the use case decides the shape of the setup, and these routes decide who builds and runs it. You can change your mind about the second without changing the first: a sender who starts on the Configurator can move to managed later, and the underlying configuration is the same either way.
Not sure which fits?
A deliverability audit is the fastest way to see where you stand — or get the Auto PMTA Configurator and configure everything in one command.
Solutions FAQ
Which solution fits cold email or outreach?+
None of them. Every use case here assumes permission-based, opt-in sending, and we don't serve cold outreach, purchased lists or unsolicited bulk. That isn't a moral footnote — it's because the entire setup, from warm-up to throttling to reputation hygiene, is built to keep wanted mail in the inbox, which is the opposite of what cold-blasting a list needs. If your sending isn't opt-in, PowerMTA configured this way won't rescue it.
Can one PowerMTA server cover more than one use case?+
Yes. A single server hosts multiple clients and multiple sending streams with separate identities — different domains, IPs, credentials and dashboards — so a SaaS company can run transactional and marketing on the same box without their reputations mixing, and an agency can run several clients side by side. The isolation is what makes one server serve several use cases at once.
Do the different use cases need fundamentally different setups?+
They share the same foundation and differ in emphasis. Authentication, reverse DNS, TLS, warm-up and monitoring are non-negotiable for all of them. What changes is the segmentation: how IPs are pooled, how aggressively each stream is throttled, and which mail is kept apart from which. The Configurator builds the common base for any of them and applies the segmentation your case calls for.
My sending isn't listed here — does PowerMTA still fit?+
Probably, if you send a meaningful volume of permission-based email and want control over deliverability rather than handing it to a hosted platform. The four patterns here are the most common, not the only ones. A deliverability audit is the quickest way to confirm whether a self-hosted PowerMTA setup is the right move for your specific situation.
How do these solutions relate to the Configurator and your services?+
The use cases describe who you are; the Configurator and services are how you get set up. The Auto PMTA Configurator builds the platform for any of these patterns in one deploy; the setup service does that work for you and hands it over; and the managed service runs it on an ongoing basis. The solution pages link through to whichever route fits.
Is a self-hosted PowerMTA overkill for my volume?+
It can be. If you send modest volume and don't need multi-tenant isolation or fine control over routing and reputation, a hosted ESP is simpler and you should use one. Self-hosting on PowerMTA earns its keep when you need that control, when you're running many separate reputations, or when your volume has grown past where hosted plans price well. The honest comparison is in Configurator vs DIY vs SaaS — it's worth reading before you commit either way.
How quickly can I be sending for my use case?+
The deploy itself is under an hour for any of these patterns — the Configurator builds the foundation and the segmentation in one run. Reaching full volume takes longer regardless of use case, because new IPs have to be warmed gradually rather than opened at full rate. So you're configured the same day, and you ramp to your target volume over the following days or weeks as reputation builds.