MailWizz is the most widely deployed self-hosted email marketing application for production email infrastructure, typically paired with PowerMTA or Postfix as the underlying MTA. Unlike SaaS ESPs, MailWizz provides complete control over every aspect of the email sending stack — delivery servers, bounce handling, warmup planning, suppression list management, and campaign scheduling. This control comes with responsibility: the deliverability outcomes of a MailWizz deployment depend entirely on the configuration decisions made by the operator. This guide documents the specific MailWizz settings and configurations that produce reliable deliverability at production scale.
MailWizz Overview and Architecture
MailWizz is a PHP-based email marketing application that manages subscriber lists, campaign creation, scheduling, delivery, and reporting. It does not include its own SMTP delivery engine — it relies on an external delivery server (SMTP relay) for actual message transmission. The standard production architecture: MailWizz manages the campaign management layer (subscriber lists, campaign templates, scheduling, reporting) and forwards email for delivery to a PowerMTA instance (which provides the SMTP delivery, bounce processing, and accounting log capabilities). MailWizz connects to PowerMTA through PowerMTA's built-in SMTP submission interface, allowing MailWizz to inject campaigns into PowerMTA's queue for delivery.
The MailWizz architecture separates concerns clearly: MailWizz handles what to send (campaign content, subscriber targeting, delivery scheduling), PowerMTA handles how to send (connection management, retry logic, per-domain rate limiting, bounce classification). This separation means MailWizz configuration focuses on campaign management and API integration, while deliverability optimisation at the SMTP level is configured in PowerMTA.
Delivery Server Configuration
The delivery server in MailWizz is the SMTP relay that accepts outgoing email from MailWizz and delivers it to the Internet. Configure delivery servers in MailWizz Backend → Servers → Delivery servers → Add new.
For PowerMTA integration, the delivery server configuration points to PowerMTA's submission port (25 or 587) on localhost or the PowerMTA server's private IP. Key settings:
# MailWizz Delivery Server settings for PowerMTA: Type: SMTP Hostname: 127.0.0.1 (if PowerMTA on same server) Port: 25 (or 587 for submission with auth) Protocol: TLS (required for MAGY compliance) Username/Password: (if PowerMTA requires auth on submission) From email: noreply@sending-domain.com From name: Your Brand Name Reply-to email: reply@brand.com (separate address for replies) # Sending quota settings (important for warmup): Hourly quota: 500 (initial warmup setting) Daily quota: 3000 (initial warmup setting) Total quota: 0 (unlimited) or specific total for warmup # Advanced: Force sender: Yes (use the From address defined here, not subscriber-level overrides) Force reply-to: Yes
Delivery server assignment to campaigns and lists: MailWizz supports assigning specific delivery servers to specific customer groups (for multi-tenant agency setups) or to specific lists. This assignment capability is how agencies implement per-client delivery server isolation — each client's lists are assigned to the delivery server that corresponds to that client's PowerMTA VMTA and IP pool.
DKIM Signing Configuration in MailWizz
DKIM signing in a MailWizz + PowerMTA stack is handled by PowerMTA's built-in DKIM signing capability, not by MailWizz itself. MailWizz injects messages to PowerMTA via SMTP; PowerMTA adds the DKIM signature before delivering to the destination. The MailWizz-level DKIM configuration is therefore: ensure the From domain in MailWizz's campaign settings matches the domain for which PowerMTA has a DKIM signing key configured. If MailWizz sends from campaign@client-brand.com, PowerMTA must have a DKIM key configured for client-brand.com in its domain block configuration.
MailWizz 2.x includes a DKIM configuration section in the delivery server settings (Backend → Servers → Delivery servers → Edit → DKIM tab). This setting stores DKIM key information for MailWizz's own header injection — use this if MailWizz is signing messages before injection to PowerMTA rather than relying on PowerMTA for signing. The recommended approach for production: let PowerMTA handle DKIM signing at the MTA layer (more reliable, applies to all messages regardless of the injection path) rather than relying on MailWizz's application-level signing.
The verification that DKIM is correctly applied: send a test campaign to a Gmail seed address and view the full message headers. The header should show: dkim=pass header.i=@sending-domain.com. The d= value in the DKIM-Signature header must match the From: domain or its organisational parent for DMARC alignment. If dkim=pass shows header.i=@mailwizz-server-hostname.com rather than the sender's domain, DKIM is not aligned and DMARC will not pass.
Bounce Server and FBL Configuration
Bounce handling is the most critical MailWizz configuration for list quality protection. MailWizz supports multiple bounce handling modes — the correct configuration depends on the stack architecture:
PowerMTA accounting log mode (recommended for PowerMTA integration): PowerMTA processes bounce classifications directly from SMTP responses and writes them to the accounting log. A custom script reads the PowerMTA accounting log and posts bounce events to the MailWizz API endpoint for suppression. This is the most reliable bounce handling approach because PowerMTA processes bounce classifications in real time from the SMTP response — not from email parsing of bounce notification messages.
# MailWizz API endpoint for PowerMTA bounce reporting: # Script reads PowerMTA accounting log and calls: curl -X POST https://mailwizz.yourserver.com/api/campaigns/bounce -H "X-MW-PUBLIC-KEY: YOUR_API_KEY" -d "campaign_uid=CAMPAIGN_UID&subscriber_uid=SUB_UID&bounce_type=hard"
Email bounce server mode: MailWizz polls a dedicated bounce mailbox (bounce@sending-domain.com) for Delivery Status Notification (DSN) bounce messages. Configure a separate email address for bounce processing in MailWizz Backend → Servers → Bounce servers. MailWizz periodically connects to this mailbox via IMAP/POP3 and processes incoming bounce notifications. This mode works without PowerMTA integration but is slower (bounce processing depends on the mailbox polling interval) and less reliable (some ISPs send malformed DSN messages that MailWizz's parser may not correctly classify).
Feedback loop server configuration: For ISPs that send ARF-format complaint reports (Yahoo FBL, Microsoft JMRP), configure a MailWizz feedback loop server that polls the FBL mailbox and automatically unsubscribes complainers from the relevant list. Backend → Servers → Feedback loop servers → Add new. The FBL server configuration requires a dedicated email address enrolled in each ISP's FBL programme and accessible via IMAP from the MailWizz server.
Warmup Plans in MailWizz 2.x
MailWizz 2.x introduced built-in Warmup Plans — a campaign scheduling feature that gradually increases the sending volume of a campaign or campaign series over a defined period. The Warmup Plan feature is available in Backend → Warmup Plans → Add new.
The two Warmup Plan types in MailWizz 2.x: (1) "Total" type distributes the campaign volume evenly across the warmup period — sending approximately equal daily volumes with a flat distribution. (2) "Targeted" type sends incrementally increasing volumes — a smaller volume on day 1 that grows each day until the final target volume is reached on the last day. The Targeted type is the correct warmup approach — graduated increase from small to large, building reputation progressively.
Key Warmup Plan settings:
# MailWizz 2.x Warmup Plan configuration: Name: New IP Warmup - Brand.com Type: Targeted (incremental increase) Duration: 14 days (minimum for 50K/day target) Sending limit: 50000 (maximum daily sends on the final day) Start date: [warmup start date] # The "Sending limit" represents the daily cap on day N (the final day) # NOT the total over the warmup period # With Targeted type, earlier days receive proportionally smaller volumes
Assign a Warmup Plan to a campaign in the campaign settings when creating a new campaign. The campaign respects the Warmup Plan's daily volume limits — if the plan limits day 3 to 5,000 messages, MailWizz will not inject more than 5,000 messages that day even if the campaign has 500,000 total recipients queued. The Warmup Plan is the mechanism that enforces the graduated volume increase at the campaign management layer, complementing the PowerMTA-level domain block rate limits that also control delivery pace.
Global Suppression Lists and Blacklisting
MailWizz maintains a global suppression list (email addresses that should never receive email from the system regardless of which campaign or list they appear in) and per-list suppression. The global suppression list is the single most important list quality protection mechanism in MailWizz — configure and enforce it correctly.
The global suppression list should contain: all hard bounce addresses (MailWizz adds these automatically when bounce handling is correctly configured), all FBL complaint addresses (added automatically by the FBL server configuration), all explicit unsubscribe addresses (added automatically when subscribers click the unsubscribe link), and any manually added addresses (spam traps identified through blocklist monitoring, addresses added from DMARC forensic reports, addresses from legal opt-out requests).
Blocking rules in MailWizz (Backend → Email blacklist rules): configure pattern-matching rules that automatically block specific email address patterns, domains, or TLDs. Common blocking rules for production deployments:
# MailWizz blacklist patterns (examples): # Block known disposable email domains: *@mailinator.com *@guerrillamail.com *@yopmail.com *@sharklasers.com # Block role addresses (often monitored, generate complaints): postmaster@* abuse@* noreply@* spam@* # Block TLDs associated with high spam/abuse rates: *@*.xyz (use with caution — legitimate .xyz domains exist)
Campaign Settings for Deliverability
Campaign-level settings in MailWizz that affect deliverability:
Max send at once: The maximum number of messages MailWizz injects per cron job run. Set this to a value that matches the delivery server's comfortable throughput — too high causes PowerMTA queue backup; too low causes campaigns to deploy very slowly. For PowerMTA at 50,000 messages/hour throughput, a max-send-at-once of 10,000-20,000 per cron run (with 5-minute cron intervals) provides good throughput without overwhelming the queue.
Send interval: The pause between batches in a campaign. Setting a send interval creates artificial pacing that can help avoid triggering ISP rate limits during the initial hours of a large campaign deployment. For a large list (500K+), setting a 1-2 second send interval paces the injection to PowerMTA's queue without creating a sudden spike that might exhaust per-domain rate limits set in PowerMTA's domain blocks.
Tracking domain: Campaign click and open tracking URLs should use a branded custom tracking domain (click.yourdomain.com) rather than MailWizz's default server hostname. A custom tracking domain keeps tracking links on the sender's own domain, which avoids the brand inconsistency of links from unknown MailWizz server hostnames appearing in email content — a content signal that some spam filters flag as suspicious.
MailWizz Monitoring and Reporting
MailWizz provides per-campaign delivery reporting through the Campaign Overview dashboard. Key metrics to monitor per campaign: delivery rate (delivered ÷ total sent), hard bounce rate (should be below 0.5%), soft bounce rate, open rate (with MPP caveat), click rate, and unsubscribe rate. MailWizz stores these per-campaign metrics in its database — review them after each campaign deployment to identify any metric that exceeds threshold.
The MailWizz reporting gap vs PowerMTA: MailWizz's native reporting does not show per-ISP delivery breakdown (what percentage delivered to Gmail vs Yahoo vs Microsoft) or per-ISP deferral rates. This per-ISP breakdown is available only from PowerMTA's accounting log. For production operations, supplement MailWizz's campaign reporting with daily PowerMTA accounting log analysis that shows per-ISP delivery rates — this combined view provides the complete picture that neither system provides alone.
MailWizz, configured correctly in combination with PowerMTA, provides a production-grade email marketing platform with the configuration control that commercial deliverability management requires. The configuration details in this guide represent the settings that distinguish a MailWizz deployment that achieves consistent High Gmail reputation and reliable inbox placement from one that generates repeated deliverability problems from misconfigured bounce handling, missing DKIM alignment, or unoptimised campaign pacing.
MailWizz's power is its configurability — but configurability requires correct configuration. An out-of-the-box MailWizz installation with default settings will not achieve the deliverability outcomes a properly configured installation achieves. Bounce handling defaults are often set to conservative global suppression levels that are too slow for production at scale. DKIM alignment requires explicit verification that PowerMTA's signing matches MailWizz's From domains. Warmup plan configuration requires understanding the distinction between Total and Targeted distribution types. Each of these settings, correctly configured, moves the MailWizz deployment from adequate to excellent deliverability performance. The time investment in the configuration review documented in this guide pays for itself in the first campaign that achieves High Gmail reputation on the production IP pool.
Review the configuration against the checklist in this guide quarterly — MailWizz updates regularly, and new features and configuration options are added with each release. The MailWizz community forums and documentation at mailwizz.com are the primary resources for staying current with configuration best practices as the application evolves. This guide provides the deliverability-focused configuration baseline; the MailWizz documentation provides the feature-complete reference for the full range of settings available in the current version.