Understand the Email Preference Center
Learn how per-list unsubscribe, global marketing opt-out, signed links, and stale-link protection work for canonical contacts.
Opening the preference center does not unsubscribe the contact
For current canonical sends with a valid membership context, the visible unsubscribe link opens the Email Preference Center. A normal browser GET is a preference-management view, not an automatic global unsubscribe action.
The contact can save per-list preferences, unsubscribe from the originating list, or explicitly choose Unsubscribe from all marketing emails.
Per-list unsubscribe is the default
A normal unsubscribe is bound to the originating contact membership. Unsubscribing from List A does not automatically unsubscribe the same canonical contact from List B.
K2Mailer signs the URL with the contact, list, and current subscription generation. If the contact later explicitly resubscribes and the membership generation changes, an old unsubscribe link becomes an idempotent no-op instead of affecting the newer consent state.
One-click unsubscribe and global opt-out
- RFC 8058 one-click
- For campaign sends where one-click headers are enabled, mailbox-provider POST requests use the signed membership-scoped URL and unsubscribe only the originating membership when that context exists.
- Unsubscribe from all marketing emails
- An explicit global action sets the contact-level marketing opt-out and a tenant-wide suppression backstop while preserving list membership history.
- Historical links
- Old links without trustworthy list context keep their historical global behavior rather than guessing which list the recipient meant.
Which sending paths carry membership context
Current canonical visible-unsubscribe generation carries membership subscription-version context through Campaigns, Drips, Trigger schedules, Auto follow-ups, and Split tests. Existing prepared campaign or split-test batches created before that field existed resolve the current membership generation at send time. This membership-context coverage should not be read as a claim that every legacy automation pipeline has identical RFC 8058 header or tracking-pixel implementation; validate those pipeline-specific transport features separately.
Was this guide enough?
Contact support if your screen or result is different.