MailWizz is a self-hosted PHP email marketing application popular with developers, agencies, and cost-conscious high-volume senders who want full control over infrastructure without SaaS subscription costs. The unsubscribe mechanism uses the [UNSUBSCRIBE_URL] merge tag auto-injected into every campaign footer, and MailWizz supports RFC 8058 header injection at the sending delivery server configuration level. Consent is tracked per list in the self-hosted MySQL database. Deployment requires PHP hosting, MySQL, and SMTP relay configuration. This guide covers the tag, the self-hosted deployment model, and how to verify the setup end to end.
MailWizz unsubscribe link
| Tag syntax | [UNSUBSCRIBE_URL] |
| Placement | Auto-embedded in every campaign footer |
| Scope | Per-list opt-out in self-hosted database |
| Config path | Backend > Servers > Delivery servers > Additional headers |
| RFC 8058 one-click | Manual configuration at delivery server level |
How to add the unsubscribe tag in MailWizz
Place the merge tag exactly as shown below in the email template. MailWizz replaces it at send time with a signed URL scoped to the recipient and campaign.
[UNSUBSCRIBE_URL]For custom HTML templates, wrap the tag in an anchor to render a proper hyperlink in the delivered email:
<a href="[UNSUBSCRIBE_URL]">Unsubscribe from this list</a>Auto-embedded in every campaign footer
Manual configuration at delivery server level The recipient's mailbox provider (Gmail, Yahoo) uses the List-Unsubscribe-Post header to expose the native one-click button on the message. Requires domain authentication with DKIM and DMARC.
MailWizz self-hosted deployments require the operator to configure RFC 8058 List-Unsubscribe headers manually at the delivery server (SMTP relay) level under Backend > Servers > Delivery servers > Additional headers. Missing this configuration silently falls out of one-click compliance for Gmail and Yahoo bulk senders. Audit each delivery server configuration when scaling infrastructure.
Testing your MailWizz unsubscribe link
- Send a test message to a controlled Gmail address you own via the MailWizz campaign preview action
- Click the footer unsubscribe link and confirm the opt-out on the landing page
- Check the subscriber or contact record: the status should be Unsubscribed within seconds
- Verify the RFC 8058 headers in Gmail: open the message, click three dots, then Show original. Look for
List-UnsubscribeandList-Unsubscribe-Post: List-Unsubscribe=One-Click
Want the full 222-platform reference?
See the pillar guide with the compliance landscape, the RFC 8058 deep dive, and the unsubscribe tag for every ESP: How to add an unsubscribe link: the complete 2026 guide →
How to add the MailWizz unsubscribe link (step by step)
MailWizz default templates include the unsubscribe link in the footer, but custom HTML templates require the tag inserted manually.
- Open your MailWizz campaign or template in the customer backend.
- Add or edit a text block in the footer where the unsubscribe link should appear.
- Insert the merge tag
[UNSUBSCRIBE_URL]. MailWizz replaces it at send time with a signed URL scoped to the list subscriber. - Wrap it in an anchor:
<a href="[UNSUBSCRIBE_URL]">Unsubscribe</a>. - Configure the delivery server List-Unsubscribe headers under Backend > Servers > Delivery servers > Additional headers for RFC 8058 compliance.
- Send a test to a seed address and verify the rendered link routes to the MailWizz-hosted unsubscribe confirmation page.
Self-hosted deployment and RFC 8058 configuration
MailWizz self-hosted deployments require the operator to configure RFC 8058 List-Unsubscribe headers manually at the delivery server (SMTP relay) level under Backend > Servers > Delivery servers > Additional headers. Missing this configuration silently falls out of one-click compliance for Gmail and Yahoo bulk senders. Audit each delivery server configuration when scaling infrastructure. For agencies running multiple delivery servers with different clients or brand allocations, use configuration templates to keep RFC 8058 headers consistent across the pool.
Per-list opt-out and MySQL database
MailWizz applies unsubscribes at the list level, stored in the self-hosted MySQL database. A subscriber who opts out of List A remains subscribed to List B unless the account-wide blocklist is used. Cross-list suppression is available via the Central blocklist feature which blocks matched email addresses from all future sends regardless of list. Data ownership is complete: as a self-hosted application, all subscriber data, opt-out history, and complaint feedback stays on customer infrastructure.
Agency multi-tenant and delivery server pools
MailWizz agency deployments typically run multi-tenant with each client as a customer account under one MailWizz instance. Delivery server pools segregate client sends by IP reputation, allowing per-client IP allocation without infrastructure duplication. Cross-tenant suppression is off by default, keeping client opt-out pools isolated. For high-volume agencies, monitor the MySQL database size and archive old campaign data periodically to maintain query performance on the subscribers and blocklist tables.
Frequently Asked Questions
What is the MailWizz unsubscribe tag?
The merge tag is [UNSUBSCRIBE_URL]. MailWizz replaces it at send time with a signed URL scoped to the list subscriber. Use it inside an anchor: <a href="[UNSUBSCRIBE_URL]">Unsubscribe</a>.
Does MailWizz support one-click unsubscribe for Gmail and Yahoo?
Only when the delivery server is configured for RFC 8058 headers. Configure List-Unsubscribe headers under Backend > Servers > Delivery servers > Additional headers. Missing this configuration silently falls out of one-click compliance.
Where is MailWizz opt-out data stored?
In the self-hosted MySQL database on customer infrastructure. Data ownership is complete: all subscriber data, opt-out history, and complaint feedback stays on customer infrastructure with no third-party cloud dependency.
Can agencies isolate client opt-out pools in MailWizz?
Yes. Multi-tenant deployments keep client opt-out pools isolated by default. Delivery server pools also segregate client sends by IP reputation, allowing per-client IP allocation without infrastructure duplication.
Is MailWizz suitable for high-volume production sending?
Yes with proper infrastructure. High-volume MailWizz deployments benefit from tuned MySQL performance (indexes on subscribers and blocklist tables), archived old campaign data, and multiple delivery servers with load balancing across SMTP relays.
About the Author
Alaa · LinkedIn
Email infrastructure specialist with 8+ years of hands-on experience in SMTP, deliverability, and email verification. I’ve configured and troubleshot mail systems across Postfix, Exchange, and cloud relays, managed IP reputation and warmup campaigns, and built verification pipelines processing millions of addresses. My work spans DNS authentication (SPF, DKIM, DMARC, BIMI), bounce handling, blocklist monitoring, and compliance frameworks including CAN-SPAM and GDPR. I write every article on SMTPedia to give email professionals, developers, and marketers the accurate, RFC-grounded reference they need.
About SMTPedia
SMTPedia is an independent email industry reference covering SMTP, IMAP, POP3, email deliverability, marketing platforms, DNS authentication, and email verification. Every article is researched from official provider documentation, IETF RFCs, and industry best practices. Settings and configurations are verified quarterly.
We are cited as a source by ChatGPT, Microsoft Copilot, and thousands of email professionals worldwide. Learn more about our editorial process.
