… 33 unchanged lines …
  
  ## Gotchas
  
+ - **Journeys always use the contacts unsubscribe URL, whatever the journey targets.** A compliance profile with an external link exposes three fields — contacts, leads and customer profile — and journeys read only the first. A journey running on leads or on Customer Insights – Data profiles still sends the contacts URL. The other two fields, and any `{{contact.*}}` or `{{lead.*}}` tokens in them, apply to shared consent only. Clients who configured per-entity URLs will believe their consent system is receiving the right identity and it won't be.
+ - The `contextId` and `msdynmkt_trackingcontext` parameters on a generated unsubscribe link are internal to Customer Insights – Journeys. Don't let an external consent system key off them — append your own identifier via link personalisation. The exception is an unsubscribe page with an embedded Marketing form, which picks up `msdynmkt_trackingcontext` on its own.
+ - If consent is managed through contact point consent, `DoNotEmail`, `DoNotBulkEmail` and `DoNotTrack` are no longer the source of truth and relying on them alongside contact point consent gives you two answers to the same question.
  - The feature switch being off by default is the single biggest trap. A client migrating from outbound assumes `DoNotBulkEmail` still suppresses. It doesn't, until you turn it on.
  - Changing a purpose's enforcement model silently changes behaviour for every compliance profile that shares it. There is no per-profile override.
  - Tracking purposes cannot be linked to another profile after creation. Getting the profile set wrong on day one means duplicate tracking consent records for the same people, forever.
    … 10 unchanged lines …
  
  ---
  
- *Worth another look if Microsoft changes the feature-switch default or extends consent checks to leads and Data profiles.*
+ *Worth another look if Microsoft honours the per-entity unsubscribe URL fields in journeys, or extends consent checks to leads and Data profiles*