What it does

Consent in real-time journeys is held against the contact point — the email address or phone number — rather than against the contact record. A compliance profile groups the purposes and topics you consent people to, holds the physical address and unsubscribe behaviour that goes into every message, and either points at a hosted preference centre or at an external URL you own.

Key facts

• Two compliance profile types: one with a built-in preference centre hosted by Journeys, and one that redirects to an external link. You pick this when you create the profile.
• A new profile is created with three default purposes: Commercial, Transactional and Tracking. These are product defaults, not legal advice, and the client owns the mapping to a lawful basis.
• Purposes carry one of three enforcement models: Restrictive (send only where an opt-in consent record exists), Non-restrictive (send unless an opt-out exists), or Disabled (consent is not checked at all).
• The enforcement model is a property of the purpose, not the profile. Change it and every compliance profile using that purpose changes with it.
• Topics sit under exactly one purpose and inherit its enforcement model. A message tagged with a topic sends only when the contact point has valid consent for both the purpose and the topic.
• Compliance profiles, purposes and topics cannot be deleted. You can only set them to Inactive, and deactivated records are still used by journeys and messages that already reference them.
• Purposes can be shared between profiles. Commercial and transactional purposes can be linked to another profile at any time; tracking purposes can only be shared via the "Use previously captured consent" option when the profile is created. There is no later fix.
• Real-time journeys do not evaluate the contact's DoNotEmail, DoNotBulkEmail or DoNotTrack fields by default — that sits behind the "Check contact consent in real-time journeys" feature switch at Settings > Overview > Feature switches. With it on, a commercial-purpose email needs both DoNotEmail and DoNotBulkEmail false and a transactional one needs only DoNotEmail false. Contacts only: leads, Data profiles, text and custom channels ignore those fields entirely.
• The preference centre updates contact point consent records only, never DoNotEmail or DoNotBulkEmail — there is no mapping between purposes and those legacy fields. Its default page exposes the Commercial purpose against the recipient's email address, and Tracking is not on it, so a restrictive tracking purpose plus an untouched preference centre means nobody can ever opt in to tracking.
• Unsubscribe links expire six months after creation (in force since 10 October 2024). Long-lived evergreen sends will accumulate dead links.

When to use / skip

Every implementation needs at least one compliance profile, so the real question is how many. One profile per brand or line of business, or one per region where the legal position genuinely differs — that's the honest test. Multiple profiles also let you run differently designed and differently worded preference centres, which is the usual driver in practice.

Skip the multi-profile design if the client is a single brand in a single jurisdiction. Extra profiles multiply the consent records you have to reason about, and because nothing can be deleted, a speculative profile is with you forever.

Push back hard on the Disabled enforcement model. It exists, it is occasionally the correct answer for genuinely transactional traffic, and it is far more often chosen because someone wanted a test send to work.

Configuration decisions

• Profile type per brand: hosted preference centre or external link into the client's existing consent platform. If they already run a consent management platform, external link is usually the honest answer and avoids two sources of truth.
• Enforcement model per purpose, agreed with the client's legal or privacy function, not chosen by the project team. Restrictive for commercial in an opt-in jurisdiction is the normal starting point.
• The purpose and topic taxonomy: how granular the client actually wants preferences to be, and whether topics are per-newsletter, per-product-line, or per-frequency.
• Whether the legacy DoNotEmail / DoNotBulkEmail fields are authoritative. If the client has years of outbound or Sales-era opt-outs in those fields, turn the feature switch on and say so in the design.
• Whether existing consent is migrated in, and whether new profiles are created with "Use previously captured consent" to inherit purposes — decided before anyone creates a profile, because tracking purposes cannot be shared afterwards.
• Which physical postal address goes on the profile, per brand. It appears in every message footer.

Gotchas

• 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.
• Nothing here deletes. A test compliance profile created during discovery will sit in the list for the life of the environment, and its purposes will show up in preference centre configuration.
• A restrictive purpose with no consent records means zero recipients and a journey that looks broken rather than compliant. Check consent record counts before blaming the segment.

Consultant notes

• Get the client's privacy owner in the room for the purpose and enforcement decisions and record the outcome in the design document. This is the one area where "the consultant chose it" is not an acceptable answer later.
• Demo the preference centre early with real branding. Clients underestimate how much wording work it needs, and the wording is the part their legal team will actually review.
• Add Tracking to the preference centre if you set tracking to restrictive, otherwise you'll be explaining why open and click data is empty.
• Before go-live, send a test through each purpose, confirm the unsubscribe link resolves to the right profile, and confirm one-click unsubscribe headers are present for bulk sending.
• Warn the client about the six-month unsubscribe link expiry if they intend to run always-on journeys with archived copies of emails.

---

Worth another look if Microsoft changes the feature-switch default or extends consent checks to leads and Data profiles.