GDPR-Compliant Unsubscribe & Data Request Pages

The footer's {{unsubscribe_url}} tag points at a real hosted page, not a mailto link — one form suppresses that address across every project you send from, and a second form lets a recipient ask you to correct or delete what you hold on them, arriving in your ticket inbox instead of vanishing into a black box.

Subject

Weekend sale — 20% off

Every send's footer includes a {{unsubscribe_url}} merge tag pointing at a real hosted page — a one-click, account-wide unsubscribe plus a second form for correcting or deleting the recipient's data, routed to you as a support ticket rather than deleted automatically.

A compliant unsubscribe link isn't a mailto: address someone has to write in by hand — it's a page that actually does something the moment it's confirmed.

One click, suppressed everywhere

Confirming unsubscribe on the hosted page blocks that address across every project you send from, not just the campaign it came from — checked automatically before every future send, with a badge and a Resubscribe action visible in Contacts afterward.

Not a granular preference picker — yet

Unsubscribe today is account-wide and blanket: one suppression list per owner, not a per-topic opt-in/opt-out picker. A recipient who unsubscribes stops receiving everything from that account across every project, not just marketing emails from one of them.

Data requests become a ticket, not a delete button

The same hosted page's "Correct or delete your data" form submits as a badged Privacy request support ticket in your own inbox. A single click can't safely delete a contact row on its own — doing so could break response attribution, void an order's audit trail, or ignore a legal reason to retain the record — so that judgment call stays with you as the controller.

Transactional mail plays by different rules

A send marked type: "transactional" (via the Send API) bypasses unsubscribe-suppression, since a receipt still needs to reach someone who opted out of marketing — but it never bypasses bounce-suppression, which always applies.

Getting started

Keep the {{unsubscribe_url}} tag in your footer preset, and review Privacy & data controls for exporting or deleting your own account's data alongside handling recipient requests as they arrive in your ticket inbox.

A typical build-and-send sequence

  1. 1

    Keep the unsubscribe merge tag in your footer

    The footer preset's {{unsubscribe_url}} tag points at a hosted page built from the recipient's own live-view token — no extra setup needed per send.

  2. 2

    A one-click unsubscribe suppresses account-wide

    Confirming on that page blocks the address across every project you send from, not just the campaign it came from — checked automatically before every future send.

  3. 3

    The same page offers a data request

    A "Correct or delete your data" form on the same hosted page lets a recipient ask for erasure or rectification, submitted as a badged Privacy request ticket in your own ticket inbox.

  4. 4

    Handle it, then reply through your ticket inbox

    You make the actual correction or deletion on your end and reply through the ticket — MailInApp routes the request but doesn't auto-delete a contact-list row on your behalf.

Frequently asked questions

Can recipients manage granular topic preferences (marketing vs. product updates) separately?

Not yet — unsubscribe today is account-wide and blanket: one suppression list per owner, not a per-topic opt-in/opt-out picker. A recipient who unsubscribes stops receiving everything from that account, across every project.

Does a "delete my data" request delete anything automatically?

No — it opens a ticket addressed to you, badged as a Privacy request. A single click can't safely delete a contact row without risking broken response attribution, a voided order audit trail, or ignoring a legal retention reason, so that judgment call stays with you as the data controller.

Does unsubscribing block transactional emails too?

Depends on the send's type: a marketing send respects unsubscribe suppression, but a transactional send (like a Send API call marked type: "transactional") bypasses it — though never bounce suppression, which always applies.

Is a bounced email treated the same as an explicit unsubscribe?

Yes for synchronous cases — an SMTP relay's synchronous rejection is treated as a bounce and suppressed the same way; native SES sending gets real asynchronous bounce/complaint webhooks too, feeding the same suppression list either way.

Can a recipient un-suppress themselves later?

No — resubscribing is an owner action, a Resubscribe button next to a bounced/unsubscribed contact in the Contacts view, meant for after you've confirmed directly with the recipient that they want back in.

Build this in the studio

Start on the free plan — every interactive block and the full fallback engine are included on every tier.