MailWizz PowerMTA Integration

MailWizz and PowerMTA are the classic self-hosted email stack — a capable campaign application in front of an enterprise delivery engine — and pairing them is how a great many serious senders and ESPs run. It is also an integration that looks simple and is not. Connecting the two takes minutes; making the connection deliver well, stay off blocklists, and reliably feed bounces and complaints back into MailWizz takes real expertise, and the gap between those two states is where most setups quietly fail. This page walks through how the integration actually works, where it breaks, and the parts — especially bounce processing — that separate a working stack from one that looks fine until reputation collapses.

How do MailWizz and PowerMTA fit together?

They occupy two different layers of the same stack. MailWizz is the application — it builds campaigns, manages lists and subscribers, runs automation, and produces the mail. PowerMTA is the delivery engine — it accepts that mail over SMTP and does the actual sending, with fine-grained control over IP pools, per-ISP throttling, retries, and bounce and feedback-loop handling. The relationship is exactly the one PowerMTA’s own documentation describes: it sits beneath your applications as the engine, not the car. MailWizz relays each campaign to PowerMTA over an authenticated SMTP connection; PowerMTA enqueues, applies its policies, sends, and logs everything; and the results — deliveries, bounces, complaints — flow back into MailWizz so its reporting and suppression stay accurate. Understanding that division is the whole foundation, because nearly every integration problem is really a problem at the seam between these two layers.

Connecting them: the Delivery Server

The connection itself is made through a MailWizz Delivery Server. In MailWizz you create an SMTP delivery server that defines the host, port, authentication method and encryption pointing at PowerMTA, and on the PowerMTA side you configure an SMTP listener set to accept authenticated connections from the MailWizz application server’s address. Once that handshake works, MailWizz hands every campaign to PowerMTA over SMTP, and PowerMTA takes over delivery. This is the part that is genuinely easy — it is a standard SMTP relay configuration, and a basic version works in minutes. The mistake is thinking that because the connection is simple, the integration is done. The Delivery Server is the doorway; everything that determines whether your mail lands and whether your list stays clean is on the other side of it, in how PowerMTA is configured and how bounces find their way home.

Virtual MTAs and pools: where the power is

PowerMTA’s real value is in its virtual-MTA system, and using it well is most of what separates a serious integration from a basic relay. A virtual MTA binds sending to a specific IP and EHLO hostname, and virtual-MTA pools group those together, so you can map different kinds of traffic to different sets of IPs. That mapping is what enables every advanced pattern: a “gold” pool for your most engaged lists separated from a “standard” pool, transactional mail isolated from marketing, or — in a multi-tenant ESP — each customer or risk tier confined to its own pool so one sender’s reputation cannot bleed into another’s. Layered on top is per-ISP control: PowerMTA lets you set concurrency, sending rates and backoff behaviour individually for Gmail, Yahoo, Microsoft and other major providers, which is how you send fast without tripping their limits. MailWizz feeds these pools by aiming Delivery Servers at the right ports; PowerMTA does the routing and shaping underneath. The pools are where deliverability strategy becomes configuration.

How do you separate streams and tenants?

Through ports and pools working together, which is one of the most useful things this integration enables. Because you can create multiple Delivery Servers in MailWizz, each pointing at a different PowerMTA port, and configure PowerMTA to route each port to a different virtual-MTA pool, you get clean stream separation: transactional mail down one path to its own isolated IPs, bulk marketing down another to different IPs. MailWizz Delivery Server Groups and weighted rotation then let you distribute a campaign across several servers — sixty percent through one pool, forty through another — to balance volume. The same mechanism builds per-tenant isolation in an ESP: each customer’s sending routes to a pool dedicated to them or to their risk tier, so a complaint spike from one tenant stays contained. This is the practical expression of the multi-IP and isolation principles deliverability depends on, implemented at the seam between the two systems.

Why does per-ISP throttling need constant tuning?

Because the providers’ tolerances are not fixed, and the right settings are a moving target. PowerMTA makes per-ISP throttling easy to configure — concurrency, rates and backoff per provider — but the difficulty, as experienced operators put it, is not writing the configuration; it is monitoring the accounting logs and adjusting those domain settings to back off quickly enough when a provider starts deferring, while still keeping throughput high. Send too aggressively into Gmail and you collect deferrals and reputation damage; send too cautiously and you waste capacity and delay campaigns. The correct settings depend on your IP reputation, your volume, and the provider’s current mood, all of which change, so a configuration that was perfect last month throttles wrong this month. This ongoing analysis-and-adjustment loop is the real work of running PowerMTA, and it is the part that rewards experience rather than a one-time setup — the engine runs itself, but the tuning does not.

The headers that glue it together

The integration depends on a small set of headers that let a bounce or complaint find its way back to the exact subscriber, and they are easy to overlook until bounce processing fails. MailWizz injects identifying headers into every message — most importantly a subscriber UID, along with the list identifier and the standard List-Unsubscribe header — and PowerMTA logs these in its accounting records. When PowerMTA later records a bounce or a feedback-loop complaint, those logged headers are what allow a handler to map the event back to the specific MailWizz subscriber and list, so the right contact gets unsubscribed rather than a guess. Feedback-loop records carry an FBL identifier that serves the same purpose for complaints, and Microsoft even tucks the original recipient into its own header that has to be mapped back. Without this header mapping, a bounce is just an address with no home; with it, the pipeline can act precisely. Getting these headers flowing and parsed correctly is a quiet prerequisite for everything downstream.

Why is bounce processing the hard part?

Because there are several ways to do it, none of them is automatic, and the one most people choose has a hidden hole. There are three approaches to getting bounces from PowerMTA into MailWizz, and each has trade-offs.

The accounting-file and webhook approaches are faster and more precise than polling a mailbox, since they read PowerMTA’s own classification of each bounce. But choosing one of them and stopping there is exactly the mistake that breaks most setups, because of what they do not see.

The bounce gotcha most setups miss

Here is the detail that catches nearly everyone, and it is worth stating plainly: a large share of bounces never appear in PowerMTA’s logs at all. When a receiving server accepts a message and then rejects it later, it sends an asynchronous DSN back to your return-path address — and because that bounce arrives after the SMTP connection closed, PowerMTA’s accounting logs and webhooks never record it. Operators consistently find this is 40 to 60 percent of their bounces. A setup that relies only on the accounting-file handler or only on webhooks therefore silently misses half its bounces, leaving dead addresses on lists, inflating future bounce rates, and slowly poisoning sender reputation while the dashboards look fine. A complete pipeline processes both sources: PowerMTA’s in-band logged bounces and the out-of-band DSNs landing in the return-path mailbox. This is the single most common reason a MailWizz-plus-PowerMTA integration looks healthy and is quietly degrading, and building it correctly means handling both paths from the start rather than discovering the gap months later.

FBL processing and anonymized recipients

Feedback-loop complaints need the same care as bounces and add one more wrinkle. PowerMTA captures complaints through its feedback-loop records, each carrying an FBL identifier that, together with the subscriber UID, lets a handler map the complaint back to the right MailWizz subscriber and suppress them — because a complainer who keeps receiving mail is a fast route to a blocklist. The wrinkle is that some feedback-loop providers anonymise the recipient address in their reports, stripping out the very email you would use to identify the complainer. This is exactly why the injected subscriber UID and list identifier matter: when the recipient address is hidden, those headers are the only way to know who complained and unsubscribe them. A feedback-loop setup that does not preserve and parse these identifiers cannot act on anonymised complaints at all, which means complaints accumulate invisibly. Handling FBLs properly, including the anonymised case, is part of the same pipeline discipline that makes bounce processing reliable.

The multi-tenant scale problem

Running this stack as a multi-tenant ESP introduces a scale problem that naive setups cannot handle. You cannot realistically maintain a separate API key, bounce mailbox and list configuration for each of a thousand customers — the per-customer approach simply does not scale. The standard solution is a single handler that reads the subscriber UID directly from PowerMTA’s logged headers and calls the MailWizz API to unsubscribe the correct contact regardless of which customer owns them, so one pipeline serves every tenant. Some operators pair this with catch-all return paths that encode the subscriber UID in the address itself, extracting it to drive suppression. On the sending side, the virtual-MTA pools isolate each tenant’s reputation, and generating the PowerMTA configuration for hundreds or thousands of IPs and VMTAs becomes its own engineering exercise that operators automate. None of this is in the basic documentation; it is the accumulated practice of people who have run these stacks at scale, which is precisely the knowledge a managed integration brings.

How we build and run your MailWizz + PowerMTA integration

With MCSNET, the integration is built the way experience says it should be, not assembled from forum threads. We wire the MailWizz Delivery Servers to PowerMTA’s listeners, design the virtual-MTA pools for your streams, tenants or risk tiers, and tune the per-ISP throttling and backoff so you send fast and stay under provider limits — then keep tuning it as conditions change. We make sure the identifying headers flow and are parsed, and we build the complete bounce and feedback-loop pipeline, processing both PowerMTA’s logged bounces and the out-of-band DSNs that simple setups miss, mapping every bounce and complaint back to the right subscriber for reliable suppression. All of it runs on PowerMTA on our own IPs, with reverse DNS, authentication and warming handled, so the MailWizz front end sits on delivery infrastructure that actually performs. You get the integration done right the first time, rather than the version that works until reputation quietly erodes.

# mcsnet · mailwizz + powermta integration · brand.example
delivery srv   port 587 → vmta pool: transactional  ok
delivery srv   port 2525 → vmta pool: marketing  ok
per-isp        gmail/yahoo/outlook throttling tuned
headers        subscriber-uid + list-id flowing  ok
bounce: in-band  accounting logs → api unsubscribe  ok
bounce: out-band return-path mailbox parsed  ok
fbl            complaints → suppress (uid-mapped)  ok
status         both bounce paths live · nothing lost

Why work with us?

Because we have built this exact integration many times, and we know where it breaks. The connection is easy; the parts that take others months of trial and error — virtual-MTA pool design, per-ISP throttling that needs constant tuning, and a bounce pipeline that catches the out-of-band DSNs most setups silently lose — are ones we wire correctly from the start. We run it on PowerMTA on IPs we own, so reverse DNS, authentication and warming are handled rather than left to you, and the whole stack stays resident in Canada under PIPEDA with a permission-based, CASL-aware approach. We bring the deliverability and operations culture PowerMTA rewards, so you get the campaign flexibility of MailWizz on a delivery engine that is tuned, monitored and correctly integrated — instead of a stack that sends fine and degrades invisibly.

Who this is for, and who it is not

It is for senders and ESPs who run, or want to run, MailWizz on PowerMTA and need the integration done by people who have done it before — operators scaling past what a casual setup can handle, or anyone whose existing stack is losing bounces, tripping ISP limits, or drifting toward blocklists. It is for white-label operators needing per-tenant pool isolation and a bounce pipeline that scales across customers. It is not for a non-technical sender who wants a drag-and-drop platform with no engine to understand — PowerMTA is the engine, not a Mailchimp interface, and a simpler stack or managed platform may suit better, which we will say honestly. The integration pairs the MailWizz application with the PowerMTA delivery layer and the feedback-loop and bounce processing that keep it clean. Wired correctly, tuned continuously, and built with the complete bounce pipeline from the start, MailWizz and PowerMTA become the high-volume stack they are meant to be — instead of one that quietly poisons its own lists.