MailWizz Hosting

MailWizz is one of the most capable email-marketing platforms you can run, and one of the most misunderstood to host. The confusion is almost always about what it is: people treat it as an email-sending tool, when it is really the application half of an email-sending system whose other half — the delivery engine — is a separate thing entirely. Get that distinction right and MailWizz gives you a platform you own outright, with your data on your own hardware and no per-subscriber SaaS bill. Get it wrong and you end up with the application and the delivery layer fighting on one overloaded box. This page explains what MailWizz hosting actually involves, how the layers fit together, and the honest limits of what any platform can do.

What is MailWizz, and what is MailWizz hosting?

MailWizz is a self-hosted email-marketing application — commercial software, written in PHP with a MySQL database, that you install on your own server. It handles everything on the campaign side of email marketing: building and managing lists and subscribers, a drag-and-drop and HTML template editor, segmentation, automation flows, autoresponders, A/B testing, surveys, detailed reporting, an API, and multi-tenant customer panels for running an email-service business. MailWizz hosting, then, is running that application on infrastructure configured for it — the web server, the database, the cron jobs that drive its queues, and the connection to a delivery layer that actually sends. Because MailWizz is a one-time license rather than a subscription, hosting it means you own both the software and the data inside it, which is the core appeal: a full-featured marketing platform that is genuinely yours rather than rented by the month.

MailWizz is the application layer, not the sending engine

This is the single most important thing to understand, because nearly every MailWizz problem traces back to missing it. A complete sending system has three layers: the application (MailWizz — campaigns, lists, automation), the queue (MailWizz’s worker processes, driven by cron, that hand mail to delivery and ingest bounces in reverse), and the delivery layer (the MTA — PowerMTA, KumoMTA or Postfix — doing the actual SMTP sending, throttling, bounce and feedback processing). MailWizz occupies the first two; it does not deliver mail itself, and instead passes campaigns over SMTP to a delivery layer you choose. The architectural error that wrecks DIY ESP builds is collapsing these layers — running MailWizz and an MTA on a single server, where the PHP application and the delivery engine compete for the same CPU and memory exactly when a high-volume send needs both. A serious install keeps them separate: MailWizz on its own server, the MTA on its own with the sending IPs. That separation is the foundation everything else rests on.

Why choose MailWizz over a SaaS platform?

Because MailWizz makes the platform and the data yours in a way subscription services do not. It is a one-time license, so as your list grows you pay nothing extra per subscriber — a contrast with SaaS platforms whose pricing climbs with every contact. Your subscriber data lives on your own hosting, not in a vendor’s account that can be suspended without warning, which is a real risk on managed platforms. And MailWizz is multi-tenant, so you can run your own email-service business and resell sending to your own customers, something no SaaS platform permits. The honest counterweight is that you take on the hosting — but the ownership, the cost control at scale, and the ability to build a business on top are exactly why operators choose it.

The catch: self-hosting is a burden

Owning the platform means owning its operation, and that is the real cost of MailWizz. It runs on PHP and MySQL, which need a properly configured and maintained server. It depends on cron jobs to drive its sending queues — without correctly scheduled cron, campaigns simply do not go out — and on PHP extensions like pcntl for parallel processing. It needs software updates, database tuning as lists grow, and a correctly configured SMTP integration to the delivery layer. And when something breaks before a campaign, troubleshooting it is yours. For a team with the technical depth and the willingness to be on-call, that is a fair trade for ownership. For most, the self-hosting is precisely the part they would rather not own — which is the entire point of managed hosting: you keep the software ownership and data control, and the server, the cron, the updates and the integration become someone else’s responsibility.

It is worth being concrete about how these things fail, because they fail quietly. A misconfigured cron does not throw an error; campaigns simply sit in the queue and never send, and the first sign is a customer asking why their newsletter never went out. A database that was fine at fifty thousand subscribers starts timing out on segmentation queries at half a million, turning a quick send into a stalled one. A MailWizz update applied without testing can break a customized template or a delivery integration mid-campaign. None of these is dramatic, and all of them are avoidable with the right operational discipline — which is the difference between owning software and owning a working system.

MailWizz and PowerMTA: the canonical stack

The standard way to run MailWizz at volume is to pair it with PowerMTA as the delivery layer, and the integration is well-defined. In MailWizz, a Delivery Server record defines the SMTP host, port, authentication method and encryption pointing at the MTA. On the PowerMTA side, an SMTP listener is configured to accept authenticated connections from the MailWizz application server’s address. MailWizz submits campaigns to that listener over SMTP, PowerMTA delivers them from the appropriate virtual-MTA pool with all its throttling and routing applied, and MailWizz reads PowerMTA’s accounting logs back to populate its reporting. KumoMTA integrates the same way and is a strong open-source alternative for high volume. This is the architecture that separates the two layers cleanly: MailWizz decides what to send and to whom; the MTA decides how it reaches each receiver. Wired correctly, it scales to serious volume; wired carelessly, it is where most MailWizz deliverability complaints originate.

How do you separate transactional and marketing in MailWizz?

Stream separation is one of the most valuable things the MailWizz-plus-MTA architecture enables, and it is done through Delivery Servers and ports. Because you can create multiple Delivery Server records in MailWizz, each pointing at a different port on the same MTA, you can route transactional campaigns to one port and bulk marketing to another — and have PowerMTA map each port to a different virtual-MTA pool on different IPs. The result is that your time-critical transactional mail sends from a pool whose reputation is insulated from your marketing, so a complaint spike on a newsletter cannot delay an order confirmation. MailWizz also supports Delivery Server Groups and rotation, distributing a campaign across several servers by round-robin or by weight — sixty percent through one, forty through another — which is how you spread volume across a pool. Configured this way, the separation and pooling that good deliverability demands are built into how campaigns route, not bolted on afterward.

Bounce handling and suppression

A serious MailWizz install closes the loop on bounces, and the mechanism is worth understanding. MailWizz uses a dedicated Bounce Server record — a mailbox it connects to over IMAP or POP3 — and the envelope sender on outgoing mail is set so that bounces return to that mailbox. MailWizz reads it, classifies each bounce against its pattern database, and on a hard bounce immediately blacklists the address, adding it to the global suppression list so it is never mailed again. This matters because bounce rate is one of the fastest ways to damage sender reputation, and a suppression list that actually works is what keeps a bad address from being hit twice. The same return path carries feedback-loop complaints when the delivery layer is configured for them. Set up correctly, bounce and complaint handling keep your list cleaning itself; set up carelessly, dead addresses accumulate and quietly erode everything.

How big can a MailWizz install scale?

MailWizz itself imposes no subscriber limit, so scale is a hardware-and-tuning question rather than a software one. The practical ceilings come from database performance and PHP processing time: a modest VPS comfortably serves on the order of a hundred thousand subscribers across multiple lists, a larger one handles a million or more including the segmentation queries that get heavy on big lists, and bare-metal hardware handles several million with concurrent multi-tenant sending. Past roughly five million subscribers, the architecture shifts to multiple MailWizz instances with sharded databases — a larger engineering exercise. The reassuring part is that most operators run a single well-tuned tier for years, and growth from a hundred thousand to a million usually fits one properly configured and indexed server. Sizing the deployment to your actual list, and tuning the database so segmentation stays fast, is part of hosting it well rather than just installing it.

The honest truth: MailWizz is a tool, not deliverability

Here is what the turnkey “PowerMTA plus MailWizz mailer” sellers will never tell you: the software does not get your mail into the inbox. MailWizz gives you excellent controls that support deliverability — authentication settings, bounce and suppression handling, segmentation for engagement — but inbox placement is decided by IP and domain reputation, list quality, consent and engagement, none of which any platform manufactures. A clean, permission-based list sent through a well-warmed delivery layer lands; a purchased or scraped list sent through the identical MailWizz install does not, and no configuration changes that. This is also where we draw a firm line: the MailWizz market is full of offers promising “unlimited sending,” “no suspension,” and bundled harvested address lists, and that is spam infrastructure that gets blocklisted and that we do not build. We host MailWizz for legitimate, permission-based marketing, and we are honest that the platform is a powerful instrument whose results depend entirely on how lawfully and cleanly you use it.

How we host and run MailWizz for you

With MCSNET, MailWizz hosting is the whole stack deployed properly and operated as one system. We install MailWizz on its own server — PHP and MySQL configured and tuned, cron jobs scheduled so the queues actually run, the license tier matched to your use, regular or extended for multi-tenant ESP operation. We stand up the delivery layer separately on PowerMTA or KumoMTA with your own IPs, wire the Delivery Server integration correctly, and set up stream separation, bounce handling and suppression. Then we run it as managed deliverability: reverse DNS and authentication on every IP, warming each one in sequence, and monitoring reputation, blocklists and bounces with action when something moves. You get a MailWizz platform you own, deployed the way a serious install should be, without having to be the administrator, the database tuner and the deliverability engineer yourself.

# mcsnet · mailwizz stack · brand.example
app server     mailwizz · php 8 · mysql tuned  ok
cron / queue   workers running · pcntl enabled  ok
license        extended (multi-tenant)
delivery       powermta · 2 listeners → 2 vmta pools
  · port 587   transactional pool (isolated)
  · port 2525  bulk marketing pool
bounce server  imap · suppression list active
ips            warm · ptr+auth on all · monitored
status         app + delivery separated · running clean

Why work with us?

Because we run every layer MailWizz depends on, as one coherent system. Anyone can install MailWizz on a cheap VPS; far fewer deploy it the way it is meant to run — application and delivery on separate servers, paired with a real MTA, on IPs whose reverse DNS we set because we own them, with port 25 open because we run a sending platform. We bring deep PowerMTA and MailWizz experience to the integration that most setups get wrong, and we run the warming, monitoring and remediation that keep it delivering. Your platform and data stay yours, resident in Canada under PIPEDA with a CASL-aware, permission-based approach. We host the legitimate version of MailWizz properly, and we run it so you can use it rather than administer it.

Who this is for, and who it is not

It is for operators who want to own their email-marketing platform and data — agencies, high-volume senders, and businesses building their own email-service offering on MailWizz’s multi-tenant capability — without running the infrastructure themselves. It is for anyone who has tried a DIY MailWizz install and discovered that collapsing the layers, or wrestling cron and PowerMTA integration alone, is harder than it looked. It is not for a small sender who would be better served by a simple SaaS platform — we will say so rather than over-build for you — and it is emphatically not for anyone wanting an “unlimited,” consequence-free spam mailer, which we do not host. MailWizz hosting pairs with the PowerMTA delivery layer it runs on, the warming and list hygiene that keep it landing, and the deliverability operations around it. Deployed as separate layers, paired with a real MTA, and run for legitimate permission-based sending, MailWizz becomes the owned, scalable marketing platform it is designed to be — and you get to use it instead of maintain it.