MailWizz Nginx and Apache Configuration — Web Server Setup, Rewrites, and Performance Tuning

MailWizz requires specific web server configuration for correct URL routing, file upload handling, and performance at scale. Incorrect web server configuration is a common cause of campaign tracking failures, import errors, and administration interface problems.

Nginx Configuration for MailWizz

server {
    listen 443 ssl http2;
    server_name yourdomain.com;
    root /var/www/mailwizz;
    index index.php;
    
    # SSL
    ssl_certificate /etc/letsencrypt/live/yourdomain.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/yourdomain.com/privkey.pem;
    
    # File upload limits (for subscriber imports)
    client_max_body_size 512M;
    
    # URL rewriting for MailWizz
    location / {
        try_files $uri $uri/ /index.php?$query_string;
    }
    
    # PHP-FPM handler
    location ~ \.php$ {
        fastcgi_pass unix:/run/php/php8.1-fpm.sock;
        fastcgi_param SCRIPT_FILENAME $realpath_root$fastcgi_script_name;
        include fastcgi_params;
        fastcgi_read_timeout 300;
        fastcgi_buffers 16 16k;
        fastcgi_buffer_size 32k;
    }
    
    # Protect sensitive directories
    location ~ /(apps|protected|framework) {
        deny all;
    }
    
    # Cache static assets
    location ~* \.(css|js|png|jpg|gif|ico|woff2?)$ {
        expires 30d;
        add_header Cache-Control "public, immutable";
    }
}

PHP-FPM Configuration for MailWizz

# /etc/php/8.1/fpm/pool.d/mailwizz.conf
[mailwizz]
user = www-data
group = www-data

# For dedicated MailWizz server
pm = dynamic
pm.max_children = 50
pm.start_servers = 10
pm.min_spare_servers = 5
pm.max_spare_servers = 20
pm.max_requests = 500

# Timeouts for large imports
request_terminate_timeout = 600

Apache .htaccess for MailWizz

# /var/www/mailwizz/.htaccess
Options -Indexes
RewriteEngine On

# Redirect HTTP to HTTPS
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}/$1 [R=301,L]

# MailWizz URL rewriting
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)$ index.php/$1 [L,QSA]

# File upload limits
php_value upload_max_filesize 512M
php_value post_max_size 512M
php_value memory_limit 512M
php_value max_execution_time 300

Troubleshooting Common Issues

Production MailWizz deployments encounter predictable issues at predictable stages. Understanding the diagnostic workflow for the most common problems in this configuration area saves time and prevents the escalating complexity that comes from applying fixes to a misdiagnosed problem. The diagnostic approach is always the same: identify the symptom precisely (not just "it's not working"), isolate the layer where the failure occurs (MailWizz application, delivery server connection, DNS, ISP rejection), and fix at the correct layer.

Systematic Diagnosis Approach

Check MailWizz logs first (available in Backend → Misc → Application Logs), then check the delivery server SMTP logs, then check the PowerMTA accounting log. Most issues surface in one of these three places. A problem that does not appear in any of these logs is almost always a configuration issue — the system is not attempting what you expect it to attempt.

# MailWizz diagnostic log locations:
# Application logs: Backend → Misc → Application Logs
# Delivery logs: Backend → Campaigns → [Campaign] → Delivery Logs
# Bounce logs: Backend → Bounce Servers → [Server] → Logs

# Server-side logs:
# MailWizz application: /path/to/mailwizz/apps/common/runtime/application.log
# PowerMTA delivery: /var/log/pmta/pmta.log
# PowerMTA accounting: /var/log/pmta/accounting.csv

Performance Optimization for Production Scale

MailWizz performance at scale depends on three infrastructure layers: the web application server (PHP/nginx or Apache), the database (MySQL — query optimization is critical at high subscriber counts), and the delivery infrastructure (PowerMTA connection pool sizing). Performance problems in any of these layers manifest as slow campaign sends, delayed processing, or timeouts that appear unrelated to the specific configuration area being managed.

The most common performance constraint in production MailWizz environments is MySQL query efficiency. As subscriber lists grow beyond 500,000 records, unoptimized database queries for segmentation, bounce processing configuration, and campaign statistics become significant bottlenecks. Ensure that subscriber tables have appropriate indexes on email, status, date_added, and any custom field columns used for segmentation.

# MySQL optimization for large MailWizz installations
# Check slow query log:
SHOW VARIABLES LIKE 'slow_query_log%';
SET GLOBAL slow_query_log = 'ON';
SET GLOBAL long_query_time = 1;  # Log queries over 1 second

# Key indexes to verify exist:
SHOW INDEX FROM mailwizz_lists_subscribers;
# Should have indexes on: email, status, date_added, list_id

# Add missing index if needed:
ALTER TABLE mailwizz_lists_subscribers 
  ADD INDEX idx_email_status (email, status);
  
# Campaign sends table — index on campaign_id + subscriber_id:
ALTER TABLE mailwizz_campaigns_tracking_opens
  ADD INDEX idx_campaign_sub (campaign_id, subscriber_id);

Security Considerations

MailWizz installations handling production sending volumes are valuable targets. Key security practices: use HTTPS for all MailWizz access (including tracking and unsubscribe links), restrict Backend access to authorized IP ranges via web server configuration, rotate API keys periodically and revoke unused keys, maintain regular database backups (automated, offsite), and ensure PHP and MailWizz are kept current with security patches.

The tracking domain (used for open and click tracking) requires special attention: it must have a valid SSL certificate (Let's Encrypt is acceptable), and its DNS records must point exclusively to your MailWizz server. A compromised tracking domain can redirect recipients to malicious sites or reveal subscriber click data to third parties.

Campaign Analytics Integration

Track this MailWizz configuration area through two complementary metric layers: MailWizz campaign statistics (open rate, click rate, bounce rate, unsubscribe rate) and PowerMTA accounting log data (ISP-specific deferral rate, bounce classification, queue depth). Gaps between the two layers reveal delivery problems invisible to MailWizz statistics alone — high MailWizz "sent" counts with elevated PowerMTA deferral rates indicate a queue buildup that campaign dashboards don't surface.

Review campaign metrics against your own historical baselines rather than industry benchmarks. Your list composition, acquisition source, and engagement history define what normal looks like for your environment. Use rolling 7-day and 30-day averages to distinguish trend changes from campaign-specific variance.

Implementation Checklist

Before deploying this configuration to production MailWizz, verify: delivery server connection test passes in Backend → Servers → Delivery Servers, cron jobs are running on the correct schedule, bounce server mailbox is accessible and IMAP credentials are valid, tracking domain has valid SSL and loads within 500ms, and PHP memory limit is set to at least 256MB.

After deploying, send a test campaign to a controlled list of seed addresses across Gmail, Outlook, and Yahoo. Verify Authentication-Results headers show dkim=pass and spf=pass in the received messages. Check that open and click tracking are registering correctly in MailWizz statistics. Confirm bounce processing is updating subscriber status within 15 minutes of a test bounce event.

For managed MailWizz environments operated by Cloud Server for Email, these verification steps are performed automatically after any configuration change. The managed service includes continuous monitoring of delivery server health, cron job execution, and tracking domain availability. Contact infrastructure@cloudserverforemail.com for information about managed MailWizz hosting.

Web Server Configuration for MailWizz Performance

Critical Nginx settings: client_max_body_size 64M for large list imports, fastcgi_read_timeout 300 for long-running campaign operations, gzip compression enabled for HTML/CSS/JS responses. PHP-FPM pool limits should be set based on available RAM — each worker uses 50-100MB. Too many simultaneous PHP workers exhaust memory during large campaign sends, producing 503 errors.

Tracking URL Performance

Open tracking pixel requests hit the web server synchronously during open events. For a 500,000-recipient campaign with 25% open rate, the web server handles 125,000 requests within a short burst window after send. Configure Nginx worker_processes to match CPU count and worker_connections to 2048 minimum. Consider a CDN or dedicated tracking server for campaigns above 200,000 recipients.