MailWizz

MailWizz is a commercial software product. License is a one-time fee (no monthly subscription). You install it on your own server (LAMP stack: Linux, Apache or Nginx, MySQL, PHP). You run it. You own the data and the infrastructure.

Feature scope is comparable to Mailchimp or ActiveCampaign at the application layer:

• Subscriber and list management with custom fields
• Campaign creation with WYSIWYG editor and template library
• Automations and drip sequences
• Segmentation based on subscriber attributes and behaviour
• A/B testing
• Tracking (opens, clicks, unsubscribes, bounces, complaints)
• FBL processing for major receivers
• Bounce handling with classification (hard, soft, suppression)
• Compliance tools (unsubscribe, suppression lists, GDPR exports)
• Reseller mode for ESP-as-a-service operators

What it isn't: an MTA. MailWizz hands outgoing mail to a separate sending backend. Could be PHP's built-in mail(), Sendmail, Postfix, PowerMTA, or any SMTP-relay service. The backend choice is where the deliverability engineering actually happens.

Specific reasons:

• Cost at scale. SaaS ESPs charge per subscriber or per send. At 100K+ subscribers and millions of monthly sends, the per-month cost compounds. MailWizz license is one-time; sending costs are infrastructure costs (bandwidth, IPs).
• Data ownership. Your subscriber list lives on your server. You don't lose access if the SaaS provider terminates you. The list is portable, exportable, fully under your control.
• Custom workflows. SaaS ESPs constrain workflows to their UI. MailWizz can be extended with custom PHP, integrated with arbitrary internal systems, automated through its API in ways SaaS providers don't allow.
• Reseller business. Want to run your own ESP-as-a-service? MailWizz has built-in multi-tenant mode. Each customer gets their own login, their own lists, their own quota. You handle billing externally.
• Avoiding SaaS termination risk. Some sender categories (cold outreach, certain political mail, crypto, gambling) get terminated by SaaS ESPs without warning. Self-hosted means you cannot be terminated at the application layer (though you can still be terminated at the infrastructure layer if your hosting provider objects.

Standard production stack:

[Subscribers + customers]
       │
       ▼
[Load balancer / Reverse proxy]
       │
       ▼
[MailWizz application servers (PHP)]
       │           │
       ▼           ▼
[MySQL/MariaDB]   [Redis cache]
       │
       ▼
[Sending backend: PowerMTA cluster]
       │
       ▼
[Multiple sending IPs across pools]

Each layer has its own scaling considerations:

• Application servers are stateless once you offload sessions to Redis. Horizontal scaling is straightforward.
• MySQL is the bottleneck at scale. Heavy read-write workload from campaign tracking. Tune query cache, use read replicas for reporting, partition large tables.
• PowerMTA backend handles the actual sending. Multiple VMTA pools for IP segmentation, FBL processing per IP, bounce parsing.
• FBL inboxes are separate. MailWizz polls them via IMAP every few minutes.

MailWizz is well-engineered but it's a PHP application. Limits emerge at scale:

• Single-database architecture. All subscribers, campaigns, tracking events live in one MySQL database. At 50M+ subscribers or 10M+ tracking events per day, MySQL becomes the bottleneck. Sharding is possible but not officially supported.
• Tracking-heavy workload. Every open and click hits the database. High-volume campaigns can produce 100K+ tracking events per minute, which strains the typical setup.
• PHP processing overhead. Each campaign send goes through PHP processing. Modern hardware can push millions per hour but the per-message PHP overhead adds up.

Practical scaling thresholds:

• Up to 1M subscribers, 5M monthly sends: Standard MailWizz on adequate hardware works fine.
• 1-10M subscribers, 5-50M monthly sends: Needs tuning, possibly read replicas, possibly Redis for tracking.
• 10M+ subscribers, 50M+ monthly sends: Consider purpose-built ESP infrastructure (Postal, Mautic at scale, or custom-built). MailWizz can technically reach this but it's not its sweet spot.

Honest comparison:

• vs Mailchimp/ConvertKit (SaaS): MailWizz wins on cost at scale, data ownership, and customisation. SaaS wins on operational simplicity and built-in deliverability infrastructure.
• vs Mautic (self-hosted, open source): Mautic is more focused on marketing automation and B2B lead nurturing. MailWizz is more focused on bulk email sending. Different use cases.
• vs Postal (self-hosted, open source MTA): Postal is an MTA, not an ESP. Compares to PowerMTA, not MailWizz. You'd use MailWizz + Postal as a stack, similar to MailWizz + PowerMTA.
• vs Sendy (self-hosted): Sendy is cheaper and simpler but only sends through Amazon SES. MailWizz is more flexible on sending backend. If you're fine with SES, Sendy is a faster path. If you need control over sending infrastructure, MailWizz wins.
• vs custom-built: Building your own ESP makes sense at very large scale (50M+ subscribers, hundreds of millions monthly sends) where MailWizz's architectural choices don't fit. Below that scale, MailWizz is faster to deploy than building from scratch.

MailWizz competes in the self-hosted ESP control plane category against Mautic and Acelle Mail primarily. Each takes a different approach to the same operational problem (running campaign infrastructure on customer-controlled servers) and the choice between them shapes the long-term operational experience substantially.

MailWizz is built on CodeIgniter with a one-time license fee and predictable feature scope. The strengths are operational maturity (the product has been in production since 2014), stable upgrade paths between versions, and a feature set focused tightly on email campaign management rather than broader marketing automation. The weaknesses are the dated PHP framework (CodeIgniter has fallen behind Laravel and Symfony in terms of ecosystem support), the limited automation capabilities compared to Mautic, and the UI that reflects its 2014-era origins despite progressive updates.

Mautic is open-source marketing automation with a more ambitious feature scope: visual workflow building, deep CRM integration, multi-channel campaign orchestration. The strengths are the automation capabilities (Mautic does things that require custom development on MailWizz) and the active development community. The weaknesses are operational complexity (Mautic deployments commonly run into upgrade issues, performance problems at scale, and dependency-management complexity), and the steeper learning curve for operators new to the platform.

Acelle Mail sits between MailWizz and Mautic on the complexity dimension. Built on Laravel with one-time licensing similar to MailWizz, Acelle offers more modern UI and architecture than MailWizz with somewhat less ambitious feature scope than Mautic. The strengths are the modern PHP foundation (Laravel ecosystem support is substantially deeper than CodeIgniter), straightforward operational characteristics, and a feature set that covers most ESP use cases without the complexity of full marketing automation. The weaknesses are smaller community and ecosystem than either MailWizz or Mautic, and slower feature development cadence.

For most operators in this space, the choice depends on use-case specifics: MailWizz for simple high-volume ESP operations with stable workflows, Acelle for similar use cases preferring modern technology stack, Mautic for operators needing complex marketing automation workflows and willing to invest in the operational complexity. We have customers running all three across different use cases and the choice tends to be relatively durable once made.

MailWizz can run on a single server for low-volume operations but production deployments at scale benefit from multi-server architecture that separates concerns. The reference architecture below covers most production deployments.

The web tier runs the MailWizz application itself (PHP-FPM behind nginx is the standard pattern), the customer interface for campaign management, and the API endpoints for external integrations. A modest VPS (2-4 vCPU, 4-8 GB RAM) handles 50-100 concurrent active users comfortably; for operations with larger user bases, horizontal scaling through multiple application servers behind a load balancer is straightforward.

The MTA tier runs the sending infrastructure separate from the web tier. PowerMTA is the high-volume choice; Postfix is the open-source alternative for volume below 1-2M monthly. Separation matters because the operational characteristics of the two tiers differ: web tier is read-heavy with bursty user-driven traffic, MTA tier is write-heavy with steady volume that needs reliable disk I/O for queue persistence. Running both on the same hardware produces resource contention that degrades both.

The database tier (MySQL or MariaDB) needs careful tuning for MailWizz. Default MySQL settings are too conservative; production MailWizz deployments typically need increased buffer pool size, InnoDB optimisations for the campaign and subscriber tables, and dedicated database server hardware for operations above 500K subscribers. The most common database-tier issue is slow queries on the subscribers table during large list operations; appropriate indexing and query tuning address this but require attention during initial deployment.

The bounce processing and FBL tier handles inbound feedback: bounces from sending, complaint reports from feedback loops, unsubscribe processing. MailWizz includes built-in bounce processing that works well for moderate volume; high-volume operations benefit from external bounce processing (we offer this as a managed service) that handles classification and suppression with lower latency than the built-in MailWizz processor.

The total infrastructure footprint for a 1-5M monthly volume MailWizz deployment runs 4-8 servers depending on the specific architecture choices. The total cost runs 500-2000 USD monthly for self-hosted infrastructure; the operational overhead beyond infrastructure is typically 10-25 hours monthly for routine maintenance plus incident response time when issues occur.

MailWizz deployments at scale develop specific operational practices that the documentation does not capture but that production operators settle on after experience. The practices below reflect what we have observed across multiple production deployments.

Customer accounts and sub-account isolation: MailWizz supports a multi-customer model where each customer has isolated lists, campaigns, and reporting. Production ESP operators commonly run this with strict per-customer isolation including separate sending IPs per customer for reputation isolation. The mechanism is implemented through MailWizz delivery server assignments combined with PowerMTA VirtualMTA configuration; the integration is operationally clean once set up but requires planning during deployment.

List health management: MailWizz built-in tools for list management are functional but not comprehensive for production operations. Most operators supplement with external email verification before list import (Kickbox, ZeroBounce, Brite Verify, or self-hosted alternatives), per-campaign engagement scoring to identify unengaged segments, and sunset policies that suppress recipients who have not engaged in 90-180 days. The list-hygiene investment pays back substantially in deliverability and is worth the operational overhead.

Template management workflow: MailWizz template editor is functional but production operators commonly develop templates externally (in a proper code editor with version control) and import into MailWizz for sending. The external workflow handles template testing across email clients more reliably than the in-product preview, and the version control protects against accidental template damage during inline editing.

Campaign scheduling and warm-up management: high-volume MailWizz deployments use campaign segmentation patterns to manage warmup: a new sending domain or IP receives only the most-engaged segments initially, expanding to broader segments as reputation builds. The mechanism is implemented through MailWizz segment definitions plus careful campaign scheduling; the operational discipline matters substantially for senders bringing new infrastructure online without burning reputation.

API integration for external systems: MailWizz exposes a REST API that integrates with external CRM, e-commerce, and analytics systems. Production deployments typically have substantial API-driven automation: subscriber synchronisation from CRM, transactional sending triggered by external events, analytics export for warehouse-side reporting. The API is functional but has some rough edges (inconsistent error handling, occasional rate-limiting issues, documentation gaps); operators building API integrations should plan for additional testing and error-handling code beyond what naive documentation would suggest.

MailWizz follows a versioned release model with major versions every 12-18 months and minor releases monthly. The upgrade paths matter operationally because in-place upgrades sometimes fail in ways that require manual database intervention.

The recommended upgrade pattern: stage the new version in a parallel deployment, migrate database state through MailWizz built-in migration scripts, validate functionality through synthetic campaign tests, switch DNS to the new deployment once validated. The pattern handles the upgrade risk through isolation rather than through hoping the in-place upgrade succeeds cleanly. The operational cost is 2-3x the time of a naive upgrade, but the downtime risk is materially lower.

The version compatibility matrix matters specifically when integrating MailWizz with PowerMTA. Each MailWizz version has been tested with specific PowerMTA versions; mismatches usually work but occasionally produce subtle issues in accounting log parsing or bounce classification that take time to diagnose. The MailWizz release notes document tested PowerMTA combinations; production deployments should match the tested combinations rather than running newest-of-both versions.

The database schema migrations during upgrades sometimes hit performance issues on large installations. A subscribers table with millions of rows can take hours to migrate during major version upgrades; the migration locks the table during the operation, producing extended downtime if not planned for. The mitigation is to run migrations during planned maintenance windows with appropriate database resource allocation, and to test the migration timing on a copy of the production database before the production upgrade.

Plugin and addon compatibility breaks more frequently than core functionality across upgrades. Most production deployments customise MailWizz through plugins (custom delivery server types, custom segment conditions, custom report types); each plugin needs verification against the new MailWizz version before upgrade. The verification overhead is typically the largest cost component of major upgrades in plugin-heavy deployments.

MailWizz has been in production since 2014 and has matured into the most stable option for operators wanting a self-hosted ESP without ambitious automation features. The operational maturity matters because email infrastructure is a long-lived investment; software that disappears or changes substantially produces migration costs that often exceed initial deployment costs.

The 2026 ecosystem position: MailWizz continues active development under EnvyCMS with regular maintenance releases. The community around it is smaller than open-source alternatives like Mautic but more stable than several commercial alternatives that have come and gone over the years. The plugin ecosystem covers most common operational needs (custom delivery server types, integration with bounce processors, segment extensions, reporting customizations).

The licensing model (one-time perpetual license plus annual updates subscription) has remained stable since the products launch, which is unusual in the commercial software space where pricing models change frequently. Customers who licensed MailWizz years ago continue running their existing installations indefinitely; the perpetual license does not expire even if the customer stops paying for ongoing updates.

The operational compatibility with PowerMTA, Postfix, and other production MTAs has been progressively improved through 2020-2026. Modern versions handle the integration patterns that earlier versions required manual configuration for: VirtualMTA assignment per delivery server in PowerMTA contexts, transport_maps coordination in Postfix contexts, accounting log parsing for both. The integration patterns that work in 2026 are documented and tested across the major MTA combinations operators use in production.

For operators evaluating MailWizz versus open-source alternatives (Mautic, postal-related stacks) or other commercial alternatives (Acelle, Sendy, EmailOctopus self-hosted), MailWizz fits the case where operational stability matters more than automation sophistication and where the operator has stable workflows that map cleanly to template-and-send patterns. Operators needing complex automation are better served by Mautic despite its operational complexity; operators with simpler needs may find Sendy or Acelle simpler to operate.