PowerMTA setup service,
done right the first time.

Getting the PowerMTA binary onto a server takes minutes. Turning it into a setup that actually lands in the inbox is the part that defeats most people, because a production configuration touches a couple of hundred settings spread across the engine, DNS, authentication, transport security, the firewall, bounce and feedback handling, and per-provider throttling. Each of those is a place to be subtly wrong, and a subtle mistake — an SPF record over its lookup limit, a missing IPv6 reverse-DNS entry, a throttle set too high for a cold IP — usually doesn't throw an error. It just quietly sends your mail to spam.

That's the gap a done-for-you setup closes. Instead of spending a week reading documentation and learning which of those settings matter by watching your own deliverability suffer, you hand the build to someone who has done it many times and gets a server that's already authenticated, hardened and verified. The learning curve stops being your problem, and the cost of the mistakes you'd have made along the way — burned IPs, a damaged domain, weeks of recovery — never lands.

It's the same calculation behind any specialist work. You could read enough to wire your own building, but the value of an electrician isn't the wiring — it's knowing, from experience, every place it goes wrong. PowerMTA configuration is the same: the worth of the service is the failures it quietly prevents, not the commands it runs.

A lot of "setup" offers leave you renting a server you can't see into — the configuration lives on someone else's terms, and if you leave, you start over. This service is built the other way around. At handover the server is yours, on your license, with a configuration that was reviewed rather than pasted, and a short doc your team can actually operate from. You can read it, audit it, change it, or hand it to a managed provider later without being locked to us.

That ownership matters more than it sounds. Email infrastructure tends to outlive the person who built it, and a configuration only one party understands becomes a liability the day something breaks or that party disappears. A clean, documented setup that any competent engineer can pick up is the difference between an asset and a dependency. The point of the handover doc is exactly that: to keep the platform operable by your own team rather than dependent on ours.

Search for PowerMTA setup and the results fill with sellers promising "unlimited" sending, "100% inbox", cold-email infrastructure and cheap rotating IPs. We're a different thing on purpose. We require your own valid license, we set up permission-based sending only, and we won't attach our name to the kind of volume that gets IP ranges blocked. The configuration is built to keep a legitimate sender in the inbox for years, which is the opposite of what a blast-and-rebuild operation needs.

The honesty extends to what we'll promise. No setup, ours included, can guarantee the inbox — anyone claiming a "100% deliver rate" is selling a number that doesn't exist. What a correct setup guarantees is that you're authenticated and accepted, which is the entry ticket; placement after that is earned through reputation, list quality and engagement. We'd rather tell you that plainly than sell you a guarantee you'd later watch fail.

It's also why the constraint is a feature. A service that only works with licensed software and opt-in sending attracts the senders who plan to be around in a year, and the whole configuration is tuned for them. If you're looking for a way to send to a bought list without consequences, this isn't it — and that's deliberate.

Handover isn't a login emailed over with a note saying it's done. It's a server in a known, verified state. Before we call a setup complete, a real message has gone out and we've read its headers together to confirm SPF, DKIM and DMARC all pass and align; every IP has been checked against the major blacklists and is clean; the reverse-DNS records resolve on both IPv4 and IPv6; and the firewall, TLS and bounce handling are in place rather than on a to-do list.

Alongside the server you get a short operating document: where the configuration lives, how the virtual MTAs and IP pools are laid out, how to add a domain, and what the warm-up plan looks like for the IPs that are new. It's written to be read by your team, not to impress — enough that whoever operates the platform next can do so without reverse-engineering someone else's work. The goal of the whole engagement is a server you could hand to a new hire next month and have them understand it.

There are three ways to get a clean PowerMTA into production, and they differ only in who does the work. This setup service is the done-for-you, one-time route: an engineer builds it on your server and hands it over. The Auto PMTA Configurator is the do-it-yourself route — a one-time €799 tool that runs the same deploy for you to operate. And managed deliverability is the hand-it-off route, where we run the platform on an ongoing basis rather than just standing it up.

A simple way to choose: take the Configurator if you have the technical comfort to run a deploy and want to own the process end to end; take the setup service if you'd rather an engineer do the build once and leave you with a finished, documented server; take managed if you don't want to operate the MTA at all. Already running elsewhere and moving over? A migration handles the move without resetting the reputation you've built, and a deliverability audit is the quickest way to see where you stand first.

The prerequisites are short, and confirming them up front is what keeps a setup to one or two days rather than a back-and-forth. You provide root or SSH access to a clean, supported server — AlmaLinux 8 or 9, Rocky, or Ubuntu — with the sending IPs you intend to use. You provide a valid PowerMTA license; we install and configure on it, and we won't proceed on a nulled or shared copy. You give us control of the sending domain's DNS, or someone on your side who can publish records quickly, since authentication has to be verified before the server goes live. And you confirm with your host that outbound port 25 is open, because a surprising number of providers block it by default and it's the one thing we can't configure around.

Getting those four things lined up before intake is most of the difference between a smooth setup and a stalled one. If any of them is uncertain — you're not sure whether port 25 is open, or whether your IPs are already listed somewhere — say so at intake and we'll check it as part of the readiness step rather than discovering it halfway through.

It's worth being clear about why the authentication and reverse-DNS pieces are non-negotiable now. Over 2024 and 2025 the major mailbox providers moved their sending requirements from advice to enforcement — Gmail shifted from temporary deferrals to outright rejections for persistently non-compliant senders, and Microsoft began rejecting non-compliant bulk mail to its consumer domains. A server that skips proper SPF, DKIM, DMARC, reverse DNS or TLS doesn't just risk the spam folder anymore; it risks being refused at the door. Setting those correctly from the first send is the whole point of having it done right.