Should PowerMTA run on the same server as CyberPanel?

Usually not. CyberPanel's whole mail stack assumes Postfix owns port 25, and a control-panel box mixes your hosting reputation with your bulk-sending reputation. The cleaner architecture is a separate, dedicated PowerMTA or KumoMTA server for outbound, with CyberPanel handling domains, DNS, webmail and inbound mail. You can run both on one box, but it fights the panel and is rarely worth it.

Will CyberPanel's email limits throttle PowerMTA?

Only if PowerMTA sends through CyberPanel's Postfix. CyberPanel's Email Limits (per-domain and per-account hourly and monthly caps) apply to its own Postfix, not to an independent PowerMTA. That is another reason to send through a separate PowerMTA instance — those caps exist to protect a shared hosting box and are the opposite of what a bulk sender wants.

Whose DKIM signs the mail — CyberPanel's or PowerMTA's?

Pick one per domain. CyberPanel's OpenDKIM signs with the default selector for mail leaving its Postfix. PowerMTA signs with its own domain-key directive and selector. If both sign the same domain you get conflicting or double signatures. For PowerMTA-sent mail, disable CyberPanel's DKIM on that domain and publish PowerMTA's public key in DNS.

Why can a CyberPanel server receive email but not send it?

Almost always because the host blocks outbound port 25. Most clouds block it by default, so CyberPanel's Postfix can receive on 25 but its outbound connections to remote MX servers time out. The block is upstream of the server. The same constraint applies to PowerMTA — see the connection-timed-out guide. Request the egress unblock from the provider before anything else.

Can I keep using SnappyMail and mailboxes if PowerMTA sends my bulk mail?

Yes. That is the point of the recommended split. CyberPanel's Dovecot, SnappyMail webmail and inbound delivery keep working for ordinary mailbox mail. PowerMTA handles only the high-volume outbound stream, ideally from a separate IP, so your transactional or marketing sending does not touch the reputation of the addresses your staff read mail from.

Does the autopmta Configurator work with a CyberPanel setup?

Yes — on a separate sending server. The €799 Configurator stands up PowerMTA or KumoMTA on its own box, and you point CyberPanel's PowerDNS at the records it generates (SPF with the sending IPs, the DKIM public key, DMARC). It does not install onto the panel box itself, because mixing a high-volume MTA into CyberPanel's stack is the thing you are trying to avoid.

PowerMTA with CyberPanel — architecture, DKIM, SPF and port 25

CyberPanel is a popular OpenLiteSpeed control panel for managing domains, websites, DNS and mailboxes. PowerMTA is a high-volume sending engine. People put them together because they already run CyberPanel for hosting and now want to send at scale — and the integration works well, as long as you make one architectural decision correctly up front. Most of the trouble people hit with this pairing comes from treating it as "install a bulk MTA on my panel box" rather than as a question of which machine owns what.

The constant on this site applies here: PowerMTA is licensed commercial software. You bring a valid license and we automate the work around it — no bundled binary, no key, nothing that helps run a cracked build. KumoMTA is the free, open-source alternative, and it fits the same architecture.

What CyberPanel's mail stack is — and isn't

Before deciding where PowerMTA goes, it helps to know what CyberPanel already runs. The panel's admin sits on port 8090, and its mail stack is a conventional self-hosted set: Postfix as the MTA on port 25 (plus submission on 587), Dovecot for IMAP and POP, rspamd with OpenDKIM for spam scoring and signing, and SnappyMail for webmail. DNS is handled by a bundled PowerDNS instance, and the panel exposes a DKIM Manager, an Email Debugger, and an Email Limits feature for capping how much each domain or account may send.

That stack is built for one job: hosting mailboxes for the domains on the box, so people can send and receive ordinary mail through webmail or a desktop client. It is not a high-volume sending platform, and it is not trying to be. The Email Limits feature is the tell — it exists to stop any one account flooding the shared box, which is the precise opposite of what a marketing or transactional sender needs. So the integration is not "make CyberPanel send bulk." It is "let PowerMTA do the bulk sending, and let CyberPanel keep doing what it is good at."

The architecture decision

There are three ways to combine them. The first is almost always the right one; the other two exist for specific constraints.

Pattern A — a separate PowerMTA server (recommended)

Run PowerMTA or KumoMTA on its own dedicated server, distinct from the CyberPanel box. Your applications, or a front end like MailWizz, send their outbound stream to that server. CyberPanel keeps its Postfix and Dovecot for inbound and mailbox mail, and its PowerDNS hosts the records. There is no port 25 conflict because the two MTAs live on different machines, and — more importantly — your bulk-sending IP is cleanly separated from the IP your hosting and mailboxes use. This is the pattern that scales and the one that protects you when something goes wrong.

Pattern B — PowerMTA owns outbound on the panel box

You can install PowerMTA on the CyberPanel server itself and let it take port 25 for outbound, stopping or constraining Postfix. It is possible, but it works against the panel: CyberPanel expects its own Postfix to handle delivery, several of its mail features assume that, and you end up maintaining a hand-modified box the panel's updates may fight. You also bind your hosting reputation and your bulk reputation to a single IP. Reserve this for a small, single-purpose box where CyberPanel is really only there for DNS and you have accepted the trade-offs.

Pattern C — relay to PowerMTA on a submission port

A middle path: leave CyberPanel's Postfix on port 25 for local and inbound mail, and run PowerMTA bound to a submission port such as 2525 on the same box. Applications that need bulk delivery relay to PowerMTA on 2525; everything else flows through Postfix as normal. It avoids the port fight but leaves you running two MTAs on one host with two sets of logs and the same shared-IP reputation problem as Pattern B. Workable for a transitional setup, not where you want to end up.

Pattern	Port 25	Reputation	Use when
A — separate sender	No conflict (different hosts)	Isolated	Almost always
B — PowerMTA owns outbound	PowerMTA binds 25; Postfix constrained	Shared with hosting	Tiny single-purpose box
C — relay on 2525	Postfix keeps 25; PowerMTA on 2525	Shared with hosting	Transitional only

Why a separate sender is usually right

The argument comes down to reputation, and reputation is the whole game in email. A CyberPanel box hosts websites and mailboxes; its IP carries whatever reputation those workloads earn. The moment you also push marketing or transactional volume from that same IP, the two reputations merge. A spam complaint spike from a campaign can drag down the deliverability of the everyday mail your team relies on, and a blocklisting triggered by hosting abuse can take your campaigns down with it. A dedicated sending server keeps a wall between the two, so a problem on one side does not bleed into the other.

There is a practical operational point too. A bulk sender wants its own IP — ideally a warmed, dedicated IP — with rDNS that matches the sending hostname, throttling tuned per receiving provider, and detailed logs you can read without sifting through hosting noise. None of that fits comfortably on a shared panel box, and CyberPanel's Email Limits would actively get in the way. Separation is not extra complexity; it is the configuration that lets each side do its job.

Use CyberPanel for what it does well: DNS

Once PowerMTA lives on its own server, CyberPanel earns its keep as the place you manage records. Its bundled PowerDNS can host the full authentication set for each sending domain — SPF, DKIM, DMARC and the MX records for inbound. That is real convenience: you keep one console for domains and their DNS rather than hand-editing zones elsewhere. The two records that have to reflect PowerMTA rather than the panel are SPF and DKIM, and getting them wrong is where almost every CyberPanel-plus-PowerMTA problem comes from. In PowerDNS, the records for a domain PowerMTA sends look roughly like this:

# SPF — name the sending server's IP, not the panel alone
example.com.            TXT   "v=spf1 ip4:198.51.100.20 -all"
# DKIM — PowerMTA's public key, under PowerMTA's selector
s1._domainkey.example.com.  TXT  "v=DKIM1; k=rsa; p=MIGfMA0GCSq..."
# DMARC — start at none while you confirm alignment, then tighten
_dmarc.example.com.     TXT   "v=DMARC1; p=none; rua=mailto:[email protected]"
# MX — stays pointed at the CyberPanel box for inbound
example.com.            MX    10 mail.example.com.

The MX line is the reminder that inbound never moves: mail addressed to your domain still arrives at the CyberPanel box and lands in Dovecot. Only the outbound path changes.

The one-signer rule for DKIM

This is the single most common mistake. CyberPanel's OpenDKIM automatically signs outbound mail from its Postfix using the default selector, and its DKIM Manager publishes that key in PowerDNS. PowerMTA does its own signing through the domain-key directive, with its own selector and private key. If both systems sign mail for the same domain, you end up with conflicting selectors or double signatures, and receivers may fail the check.

The rule is one signer per domain. For any domain that PowerMTA sends, let PowerMTA sign and turn CyberPanel's DKIM off for that domain — then publish PowerMTA's public key in PowerDNS under the selector you chose in domain-key. In PowerMTA, the domain-key parameter sets the selector, the signing domain (the d= value) and the private key; if you need to sign for a From-domain that differs from the signing domain, the dkim-identity parameter sets the i= value for that third-party-signing case. The authentication guide covers the directives in full.

# /etc/pmta/config — PowerMTA signs, using its own selector and key
domain-key s1._domainkey,example.com,/etc/pmta/dkim/example.com.pem
# the published TXT record then lives at  s1._domainkey.example.com

SPF has to authorise the real sender

The second classic mistake is an SPF record that only lists the CyberPanel box. When PowerMTA sends from a different server, that server's IPs must be in the sending domain's SPF record, or every PowerMTA message fails SPF — and with DMARC enforcing, fails delivery. Add PowerMTA's sending IPs (or the IP range of your sending pool) to the domain's SPF, hosted in PowerDNS. If you instead relay PowerMTA's mail through another service, the SPF of the originating domain must include that relay, and the DKIM signature should remain the originating domain's, not the relay's. Keep SPF describing where the mail genuinely leaves from.

Pointing CyberPanel-hosted apps at PowerMTA

A separate sender raises a fair question: how do the sites and applications on the CyberPanel box actually reach PowerMTA? Out of the box, a WordPress site or PHP app on CyberPanel hands mail to the local Postfix, which is exactly the path you are trying to keep clear of bulk volume. There are two clean ways to redirect the high-volume stream to the dedicated sender.

The first is per-application. A WordPress site can use an SMTP plugin to send through PowerMTA directly — point it at the sending server's hostname on the submission port, with the SMTP credentials PowerMTA accepts for that app. The application's mail then bypasses the panel's Postfix entirely and goes straight to the engine that should be sending it. This is the tidiest option when only a handful of sites need volume, because each one targets PowerMTA explicitly and nothing else on the box is affected.

The second is host-wide, by relaying the panel's Postfix to PowerMTA. You add a relayhost line to CyberPanel's Postfix so its outbound hands off to the PowerMTA server, which then does the real delivery, signing and throttling. It is the same relay mechanism people use to route a blocked-port-25 box through an external service, except the destination is your own sender:

# /etc/postfix/main.cf on the CyberPanel box — relay outbound to PowerMTA
relayhost = [mta.example.net]:2525
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
smtp_sasl_security_options = noanonymous

With relaying, keep one detail straight: the DKIM signature and the SPF alignment belong to the originating domain and the server that genuinely sends — here, PowerMTA — so let PowerMTA sign and make sure SPF authorises its IPs. Relaying changes the path the mail takes, not which domain owns its authentication. For most setups the per-application route is cleaner, since it keeps the panel's own mail and your bulk mail on visibly separate paths.

The port 25 reality on a CyberPanel box

The most-reported CyberPanel email symptom is "I can receive mail but I can't send it." On a hosting box that almost always means the provider blocks outbound port 25 by default, so Postfix accepts inbound on 25 but its connections out to remote mail servers time out. PowerMTA faces exactly the same constraint — the block is upstream, at the provider's network edge, and no local change lifts it. Request the egress unblock from the provider; the connection-timed-out guide covers the diagnosis. If you do co-locate PowerMTA on the panel box (Pattern B or C), the additional concern is the local conflict — only one process can bind port 25 — which the port 25 fix covers. Confirm ownership with a quick check:

sudo ss -lntp | grep ':25 '          # exactly one process should answer

KumoMTA with CyberPanel

If you would rather not buy a PowerMTA license, KumoMTA fits the same architecture and the recommendation does not change: run it on a separate sending server, not on the panel box. KumoMTA is the open-source high-volume MTA — Rust, Lua policy, Apache 2.0 — and it handles the bulk stream while CyberPanel keeps DNS, webmail and inbound. The DKIM and SPF rules are identical: one signer per domain, and SPF that names the KumoMTA sending IPs. What KumoMTA lacks is an administration panel, which is the gap the Auto PMTA Configurator fills — and it builds that sender on its own box rather than onto CyberPanel.

Common CyberPanel + PowerMTA mistakes

Two DKIM signers on one domain. CyberPanel's OpenDKIM and PowerMTA both signing produces conflicting signatures. Pick one, disable the other.
SPF that lists only the panel IP. PowerMTA-sent mail then fails SPF. Add the sending server's IPs to the record.
Co-locating to "save a server." It merges hosting and bulk reputation and fights the panel. A separate sender is worth the second box.
Forgetting CyberPanel's Email Limits. They throttle the panel's Postfix; route bulk through PowerMTA instead so the caps never apply.
Moving MX to the sender. Inbound mail and MX records stay with CyberPanel; PowerMTA is outbound only. Do not repoint MX at the sending box.
Exposing the panel. Keep the CyberPanel admin on 8090 restricted to your own address, the same discipline as an MTA monitor.

End to end at a glance

The recommended setup, in order: stand up a dedicated PowerMTA or KumoMTA server and install on your license; in CyberPanel's PowerDNS, set SPF for each sending domain to include the new server's IPs, publish PowerMTA's DKIM public key under its selector, and confirm DMARC is in place; disable CyberPanel's own DKIM for those domains so there is a single signer; leave MX, inbound and mailbox mail on the CyberPanel box untouched; send one authenticated test through PowerMTA to a seed account and confirm SPF and DKIM both pass; then warm the sending IP gradually before turning up volume.

The bottom line

CyberPanel and PowerMTA coexist best when you stop trying to make them share a machine. Put the high-volume engine on its own server, keep one DKIM signer per domain, make SPF describe where the mail actually originates, and let CyberPanel's PowerDNS host the records while its Postfix and Dovecot keep doing mailbox mail. That split removes the port 25 conflict, protects your sending reputation from your hosting reputation, and leaves both systems doing the job they were built for.

If you would rather have it wired correctly from the start, our setup service builds the dedicated sender and aligns it with CyberPanel's DNS, and the one-click installer stands up PowerMTA or KumoMTA on that box for you. Either way the standard holds: a licensed or open-source engine, opt-in sending only, real deliverability work, and nothing that helps spam.