consent-management-marketing

# Consent Management — Marketing Cloud Email

This skill activates when a practitioner needs to configure subscriber consent, opt-out handling, or compliance infrastructure in Marketing Cloud Engagement for email channels. It covers the end-to-end consent lifecycle: capturing opt-ins, presenting self-service unsubscribe mechanisms, enforcing CAN-SPAM and GDPR at send time, and processing data subject requests through Privacy Center.

---

## Before Starting

Gather this context before working on anything in this domain:

- **MC Edition and Connect status:** Subscription Center behavior and unsubscribe sync to CRM differ between standalone MC and MC with Connect installed. Without MC Connect configured with tracking, MC unsubscribes do NOT automatically write back to Salesforce Contact or Lead records.
- **Regulatory scope:** CAN-SPAM applies to all commercial email sent to US recipients and is enforced by MC automatically via Send Classification and Delivery Profile. GDPR requires additional steps: documented lawful basis, consent timestamping, and erasure workflows via Privacy Center.
- **Existing publication list architecture:** Before designing a Preference Center, map all active publication lists. Subscribers can opt out of individual lists while remaining a global subscriber on All Subscribers. A global opt-out on All Subscribers overrides all publication list opt-ins.
- **Key limit:** All Subscribers list is the authoritative opt-out store. `HasOptedOutOfEmail = true` at the All Subscribers level cannot be overridden by a publication list opt-in.

---

## Core Concepts

### All Subscribers List and Global Opt-Out

Every Marketing Cloud account has a single All Subscribers list. When a subscriber opts out globally, their `HasOptedOutOfEmail` field is set to `true` at this list level. This global opt-out is absolute: Marketing Cloud will not send any commercial email to that address regardless of which publication list they may appear on or what status that list records. The All Subscribers record is the final gate before delivery.

Global opt-outs sourced from MC do not sync back to Salesforce CRM `Contact.HasOptedOutOfEmail` or `Lead.HasOptedOutOfEmail` unless MC Connect is configured and the Synchronized Data Sources are set up to write back opt-out status. Assuming the sync is automatic is the single most common compliance failure in cross-platform deployments.

### Publication Lists

Publication lists let subscribers manage preferences at a granular level, for example opting out of "Monthly Newsletter" while staying subscribed to "Product Alerts." Each publication list has its own subscriber status (`Active`, `Unsubscribed`, `Held`). A subscriber who is `Unsubscribed` from a specific publication list will not receive sends targeted to that list, but can still receive sends targeted to other lists they remain subscribed to — unless they are globally opted out.

Publication lists are shown in the Subscription Center so subscribers can self-manage. Designers should model publication lists around content categories that a subscriber would meaningfully distinguish. Creating dozens of narrowly scoped lists increases management overhead with diminishing preference value.

### CAN-SPAM Auto-Enforcement

The US CAN-SPAM Act requires every commercial email to contain: a physical mailing address, a clearly identified sender, no deceptive subject lines, and a functional one-click mechanism to opt out that is honored within 10 business days. Marketing Cloud enforces CAN-SPAM automatically through **Send Classification** linked to a **Delivery Profile**. The Delivery Profile carries the physical mailing address. If a Send Classification with a properly configured Delivery Profile is not assigned to a send, MC will block the send.

Starting in 2024, Google and Yahoo bulk sender requirements extended the one-click expectation: the unsubscribe link must process the opt-out immediately without requiring an additional confirmation page. MC's native Subscription Center `%%unsubscribe%%` token satisfies this requirement. Custom Preference Centers built on CloudPages must be designed to process the opt-out in the page's AMPscript or Server-Side JavaScript without adding a "confirm your unsubscribe" screen.

### GDPR Consent Requirements in Marketing Cloud

For EU subscribers, GDPR requires:
- **Lawful basis documentation:** typically consent for marketing email, documented with timestamp and capture source.
- **Consent record:** MC does not natively store consent records with timestamps inside the core subscriber model. Practitioners must build a Data Extension to record consent events (email address, consent timestamp, capture source, lawful basis, consent version).
- **Right to erasure:** handled through **Privacy Center**, MC's tool for processing data subject requests. Erasure removes the subscriber from Data Extensions, suppression lists, and engagement records. Note: erasure from All Subscribers does not delete historical engagement data unless Privacy Center is configured to include engagement records.
- **Data portability:** Privacy Center can generate a data export for an individual subscriber.
- **Double opt-in (confirmed opt-in):** not required by CAN-SPAM but strongly recommended for GDPR to create an auditable consent record. Requires a confirmation email send and a CloudPage landing page that activates the subscriber on confirmation click.

### Subscription Center vs. Preference Center

| Feature | Subscription Center | Preference Center |
|---|---|---|
| Hosting | MC-hosted | CloudPages (custom) |
| Branding | Limited | Fully branded |
| Dev effort | None | Requires AMPscript/SSJS dev |
| Publication list display | All lists subscriber is on | Developer-controlled |
| One-click unsubscribe | Built-in | Must be coded explicitly |
| Double opt-in flow | Not supported natively | Can be built |

---

## Common Patterns

### Pattern: Granular Publication List Preference Center

**When to use:** Brand requires a custom-branded unsubscribe page, or subscribers should see only a curated subset of publication lists rather than all lists they belong to.

**How it works:**
1. Create publication lists in MC for each distinct content category (e.g., `Newsletter`, `Product Updates`, `Event Invitations`).
2. Build a CloudPage with AMPscript to retrieve the current subscriber's status on each publication list using `LookupRows` against the `_ListSubscribers` system Data Extension.
3. Render checkboxes for each list. On form submit, use AMPscript `UpdateSingleSalesforceObject` or `InvokeCreate` (for MC API calls) — or more commonly, use a CloudPage POST to an AMPscript-powered page that calls `UpdateData` against publication list subscriber status.
4. Add a "Unsubscribe from all" option that calls `AttributeValue("emailaddr")` and processes a global opt-out via the `%%(un)subscribe%%` functions.
5. Link to this CloudPage from the email footer using a personalization string that passes the subscriber key.

**Why not the alternative:** The default Subscription Center shows every publication list the subscriber is on, which may include internal operational lists and is not brandable. It also cannot support double opt-in re-activation flows.

### Pattern: Double Opt-In (Confirmed Opt-In) for GDPR

**When to use:** Subscriber acquisition for EU audiences where a documented, timestamped consent record is required, or any acquisition flow where re-confirmation of consent is valuable.

**How it works:**
1. On form submit (web form or CloudPage), add the subscriber to a "Pending Confirmation" Data Extension with a GUID token and a `ConsentCapturedDate` timestamp.
2. Trigger a transactional (non-commercial) confirmation email with a link to a CloudPage containing the GUID in the query string.
3. On the CloudPage, use AMPscript to look up the pending record, activate the subscriber on the target publication list (`UpsertDE` or MC API), record the confirmed consent timestamp in a consent-tracking DE, and display a confirmation message.
4. If the subscriber does not click within N days, remove from the pending DE and do not send commercial email.

**Why not the alternative:** Adding subscribers directly to a send list without confirmed consent creates GDPR exposure. If a complaint or erasure request is received, there is no auditable proof of consent.

---

## Decision Guidance

| Situation | Recommended Approach | Reason |
|---|---|---|
| US-only commercial email, no branding requirements | Use MC Subscription Center + Send Classification with Delivery Profile | Zero dev effort; CAN-SPAM auto-enforced |
| Brand requires custom unsubscribe page | Build CloudPage Preference Center; ensure immediate opt-out processing | Native Subscription Center is not brandable |
| EU subscribers requiring GDPR compliance | Add double opt-in flow + consent-tracking DE + Privacy Center setup | GDPR requires auditable consent record; erasure requires Privacy Center |
| MC and CRM must stay in sync on opt-out | Configure MC Connect Synchronized Data Sources with writeback enabled | Without Connect config, MC unsubscribes are not reflected in CRM |
| Subscriber wants granular list-level preferences | Use publication lists + Subscription Center or Preference Center | Publication lists allow per-category opt-out without global unsubscribe |
| Need to process erasure (right to be forgotten) request | Use Privacy Center to submit erasure job | Manual DE deletion alone does not cover engagement records or suppression lists |

---

## Recommended Workflow

Step-by-step instructions for an AI agent or practitioner working on this task:

1. **Confirm regulatory scope and MC Connect status.** Determine whether the deployment must satisfy CAN-SPAM only, or also GDPR/CCPA. Confirm whether MC Connect is installed and whether unsubscribe writeback to CRM is required. This shapes every downstream decision.
2. **Audit or design publication list architecture.** List all intended publication lists. Ensure each list maps to a content category that a subscriber would meaningfully distinguish. Validate that no operational/internal lists will surface in the subscriber-facing Subscription Center or Preference Center.
3. **Configure Send Classification and Delivery Profile.** Every commercial send job must use a Send Classification linked to a Delivery Profile that contains the physical mailing address. Verify this is set as the default for all user-initiated and triggered sends. Without this, MC will block sends for CAN-SPAM non-compliance.
4. **Choose and build subscriber self-service mechanism.** If the default Subscription Center is acceptable, verify the `%%subscription_center_url%%` token is in all email footers. If a custom Preference Center is required, build the CloudPage and ensure the unsubscribe path processes the opt-out immediately on page load or form submit without a confirmation interstitial.
5. **Implement GDPR-specific controls if required.** Create a consent-tracking Data Extension (fields: `EmailAddress`, `ConsentTimestamp`, `CaptureSource`, `LawfulBasis`, `ConsentVersion`, `IsConfirmed`). Build or configure double opt-in flow if needed. Configure Privacy Center for erasure and access requests.
6. **Test opt-out end-to-end.** Send a test email to a test subscriber, click the unsubscribe link, verify `HasOptedOutOfEmail = true` on All Subscribers in MC, verify the subscriber does not receive subsequent sends, and — if MC Connect is in scope — verify the CRM record is updated.
7. **Document and review.** Record the lawful basis, publication list map, and Preference Center/Subscription Center URL in the project documentation. Run through the review checklist below before go-live.

---

## Review Checklist

Run through these before marking work in this area complete:

- [ ] Every commercial email template includes `%%subscription_center_url%%` or a custom Preference Center link in the footer
- [ ] Every commercial email template includes a physical mailing address via the Delivery Profile
- [ ] Send Classification with correct Delivery Profile is assigned as default for all send types
- [ ] Global opt-out (All Subscribers `HasOptedOutOfEmail = true`) is tested and confirmed to block delivery
- [ ] If GDPR scope: consent-tracking Data Extension is populated on acquisition; double opt-in flow tested end-to-end
- [ ] If GDPR scope: Privacy Center is configured and erasure job tested against test subscriber
- [ ] If MC Connect in scope: opt-out writeback to CRM Contact/Lead `HasOptedOutOfEmail` is verified
- [ ] Preference Center (if custom): unsubscribe processes immediately without confirmation interstitial (Google/Yahoo 2024 requirement)
- [ ] Publication lists reviewed; no internal/operational lists exposed to subscribers

---

## Salesforce-Specific Gotchas

Non-obvious platform behaviors that cause real production problems:

1. **Global opt-out does not sync to CRM automatically** — A subscriber who unsubscribes via MC Subscription Center has `HasOptedOutOfEmail = true` on All Subscribers, but the corresponding Salesforce Contact or Lead record is not updated unless MC Connect is configured with opt-out writeback. This means CRM-based sends (e.g., Pardot, Sales Cloud email) may continue reaching the subscriber. Impact: regulatory exposure and brand damage.
2. **Publication list opt-in does not override global opt-out** — If a subscriber is globally opted out on All Subscribers, re-adding them to a publication list as "Active" does not re-enable delivery. The global flag wins unconditionally. Practitioners who manually import subscribers into publication lists to "fix" opt-outs are creating compliance violations.
3. **Privacy Center erasure does not delete All Subscribers record by default** — The erasure workflow removes the subscriber from Data Extensions and can be configured to remove engagement data, but the All Subscribers record (and the opt-out flag) may be retained as a suppression record. If the opt-out record is deleted, MC loses the suppression signal and may re-add the address from a CRM sync, resulting in illegal sends to an opted-out subscriber.
4. **One-click unsubscribe (Google/Yahoo 2024) requires no confirmation screen** — Custom CloudPages Preference Centers built before 2024 often include a "Are you sure?" confirmation page before processing the opt-out. This pattern violates Google and Yahoo bulk sender requirements and can result in deliverability penalties. The opt-out must be processed on the initial URL visit.
5. **Send Classification must be explicitly assigned; it does not inherit from account defaults for triggered sends** — For Triggered Sends and Journey Builder email activities, each activity must have the correct Send Classification assigned. It does not automatically use the account-level default in all contexts. Missing this causes CAN-SPAM non-compliance at the activity level.

---

## Output Artifacts

| Artifact | Description |
|---|---|
| Subscription Center configuration | MC-hosted self-service page linked via `%%subscription_center_url%%` showing all publication lists a subscriber is on |
| Preference Center CloudPage | Custom-branded CloudPages implementation of subscriber preference management with AMPscript opt-out processing |
| Consent-tracking Data Extension | DE recording acquisition consent: email, timestamp, source, lawful basis, confirmation status |
| Send Classification + Delivery Profile | MC configuration objects that enforce CAN-SPAM physical address and sender identity on every send |
| Double opt-in flow | Confirmation email + CloudPage landing combination that creates auditable GDPR consent records |
| Privacy Center erasure configuration | Configuration for processing right-to-erasure data subject requests against MC data stores |

---

## Related Skills

- security/gdpr-data-privacy — For managing GDPR consent in Sales/Service Cloud using ContactPointTypeConsent and ContactPointConsent objects; use alongside this skill when both MC and CRM consent must be synchronized