Tracking Domain Design

Scope and design

This guide treats MailWizz as an orchestration layer. Delivery, identity, feedback, and reputation controls remain explicit responsibilities of the surrounding infrastructure.

Requirements

• Documented application and database versions
• Backups verified by restore testing
• Known cron owner and schedule
• Named delivery and bounce-server owners
• Change window and rollback plan

Implementation workflow

1. Capture the current effective configuration.
2. Make one logical change at a time.
3. Validate from the application and transport sides.
4. Observe logs, queues, bounces, and complaints.
5. Record the result and rollback state.

# Example verification checklist
php -v
mysql --version
crontab -l
systemctl status php-fpm
systemctl status nginx

Operational guidance

Define ownership, service-level indicators, alert thresholds, and an emergency stop procedure. Avoid scaling volume until telemetry is trustworthy.

Common failure modes

• Duplicate or missing cron execution
• Incorrect SMTP credentials or source identity
• Bounce mailbox authentication failure
• Queue growth hidden by campaign status
• DNS or TLS mismatch after migration

Validation and rollback

Validate one controlled campaign, one bounce, one complaint path, one tracking link, and one unsubscribe before increasing volume. Preserve the previous configuration until the observation window closes.