MC Config gotchas: setup decisions you only get to make once | Cleon

Most Marketing Cloud documentation treats configuration as a checklist: Business Units, Sender Authentication, Subscriber Key, Send Classifications, Installed Packages, Data Extension schema. Setup once, never look back. The production reality is the opposite — every choice you make at tenant bootstrap is something you live with for years, because the surfaces that depend on it (Send Definitions, Automations, Journey Builder, sub-BUs, downstream reporting) make "just change the config" into a multi-week migration.

Ten configuration choices that bit Cleon during multi-tenant rollouts. Each is paired with the question to answer before making the choice and the cost of getting it wrong. The framing isn't "what's the right answer" — it's "what's the question you have to be ready to defend."

The gotchas

1. Subscriber Key vs Email Address as the primary identifier — set wrong on first send, painful to change

Marketing Cloud's All Subscribers list keys recipients by SubscriberKey by default, but the option to key by Email Address still exists on older tenants. Once the first send fires, every subsequent send is keyed the same way, every DE that joins to subscribers depends on the keying, every Journey wires itself accordingly. Changing later means rebuilding the All Subscribers list, re-keying every audience DE, re-pointing every Send Definition.

The defense: SubscriberKey, always. Email addresses change (recipient updates their email; you migrate from a CRM where Email was unique to one where User ID is unique); SubscriberKey is designed to be stable across the recipient's lifetime. Before the first send fires, verify MC Setup → All Subscribers → "Subscribers identified by" reads SubscriberKey. If it says Email Address on a tenant about to ship its first send, fix it now.

2. Business Unit hierarchy is mostly one-way

MC's multi-Business-Unit setup lets you create child BUs under a parent for separation (brand, geography, regulatory). Decisions you make at the parent BU propagate down; decisions you make at a child BU are mostly local. Moving an asset (DE, Send Definition, Automation, Journey) between BUs requires recreation, not a move. There is no mv operation in MC.

Common BU patterns:

- One BU per brand     → clean if brands are truly independent
- One BU per region    → clean for data-residency + locale defaults
- One BU per product   → blurry when products share the audience
- Parent + sandbox BU  → useful for staging if your tenant supports it

Before creating any BU, ask: what audience does this BU send to, and is it truly disjoint from the audience of any other BU? If two BUs send to overlapping audiences, you'll need cross-BU sharing logic (Shared DEs, Enterprise 2.0 features) and the model gets complex fast. Decide the hierarchy with a multi-year horizon.

3. Subscriber Attribute profile changes ripple across every email

The All Subscribers profile attributes (AttributeValue("FirstName") reads from these) are shared across all BUs. Adding a new attribute is fine. Renaming an existing attribute breaks every email that references it by the old name — no broken-link warning, no compile error, just blank renders next time the affected emails send.

Before adding a Subscriber Attribute:

- Pick a name you won't want to change in 3 years.
- Avoid generic names ("Tier", "Status", "Region") that collide
  with DE column names — see AMPscript gotcha #4.
- Document the attribute's source-of-truth (which system writes
  it, how often it updates, what NULL means).

The hand-off failure: a previous admin added LastInteraction as a profile attribute three years ago, no documentation. Today nobody knows what writes to it, whether it's still being updated, or if removing it breaks anything. The attribute stays forever because the cost of finding out is higher than the cost of carrying it.

4. Send Classifications determine CAN-SPAM / CASL / GDPR behavior — easy to misconfigure

Send Classifications are MC's hook for distinguishing Commercial from Transactional mail. Commercial sends honor unsubscribe lists, append physical-address footers, and respect global opt-out flags. Transactional sends skip those. Tagging a marketing send as Transactional is a CAN-SPAM violation; tagging a true transactional send (password reset, receipt) as Commercial means recipients can unsubscribe from the password reset email.

The defense: default everything to Commercial at the Send Definition level. Explicitly carve out a small list of pre-approved transactional senders (password resets, receipts, account verification, support replies) and document each one with legal sign-off. Treat Transactional classification as a privilege requiring justification, not a setting people pick for "I want this to deliver better".

5. Data Extension architecture is the schema that outlasts every other choice

Every other system in MC reads or writes Data Extensions. Once 50 DEs exist with inconsistent naming, no documented purpose, and unclear primary keys, the tenant is permanently harder to operate. The SQL Style Guide's prefix convention (DE_, de_stg_, de_log_, de_lookup_, TS_, J_, etc.) is intended for tenant bootstrap, not for retrofitting after the fact.

The question to answer before the first DE is created: what naming convention applies, and who enforces it? Without an enforcer (a senior dev who reviews every new DE name, or a Salesforce admin who can rename in batch), the convention drifts. Drift on this scale compounds for years.

6. The "Available in this Business Unit" toggle on Installed Packages is easy to miss

Installed Packages (API integrations, the credentials Cloud-writes use, custom Lightning components) have an Available in this Business Unit toggle in the Components tab. The package can be installed at the parent BU, but if the toggle is off for a child BU, every API call from that child returns Unauthorized — see AMPscript Cloud-write debugging — step 5, and SSJS WSProxy auth debugging — step 5.

After installing or modifying any Installed Package:

1. Open Setup → Installed Packages → <your package>.
2. Components tab → review every BU listed.
3. For each BU that should be able to use the package: toggle ON.
4. For each BU that should NOT: toggle explicitly OFF (don't leave
   ambiguous defaults).
5. Document the per-BU enablement in the team's infrastructure
   runbook.

The hand-off failure: a Cloud-write was working in BU A for months; the team adds BU B and expects the same behavior; every Cloud-write from BU B returns 0; someone spends a day debugging the AMPscript before realizing the toggle was off. Default the toggle for new BUs before activating them for sending.

7. IP warming requires gradual ramp — there is no shortcut

A new MC tenant ships with un-warmed IPs. Sending 50,000 emails on day 1 from a cold IP gets you flagged by every major mailbox provider as a likely spammer, and the reputation hit takes weeks to months to recover from. Marketing Cloud's documentation calls this out, but timelines and gradual-ramp schedules are often treated as suggestions during the rush to launch.

Reasonable warming schedule for a new sending domain:

Week 1: 1,000 emails/day max, your most engaged subscribers
Week 2: 5,000/day, expanding to recently-active subscribers
Week 3: 15,000/day
Week 4: 35,000/day
Week 5: 75,000/day or full audience

The exact numbers depend on your audience engagement and which providers you're sending to (Gmail tolerates faster ramps than corporate Exchange). The non-negotiable: start small, monitor delivered % and complaint rate at each step, hold the next step until the current step shows healthy metrics. Jumping ahead is the most common deliverability disaster Cleon has unwound for new tenants.

8. The Audit Trail retention is short by default

MC's Audit Trail captures who-did-what across the tenant — Send Definition edits, DE schema changes, Installed Package updates, user permission changes. Retention is 6 months by default and the data lives in MC's own UI, not exportable in bulk without manual effort. When a six-month-old incident needs an audit ("who changed the Sender Profile?"), the trail may already be gone.

The defense: enable Audit Activities (the paid feature that exports the Audit Trail to a Data Extension) on any production tenant. Once it's exporting to a DE, your de_log_audit becomes queryable indefinitely, joinable against other log DEs, and surviving the 6-month UI retention.

9. Tracking domain defaults to `*.exacttargetapps.com` until SAP

Before the Sender Authentication Package is configured (see SAP setup), every clickable link in every email routes through *.exacttargetapps.com. Some recipients' corporate spam filters block that domain category outright. The result: emails deliver, recipients see them, recipients click — and the click goes nowhere.

The defense: complete SAP setup before the first production send. Most tenants do the opposite — they send a "test" production campaign while SAP is in flight, see decent metrics on Gmail recipients, ship to the full audience, and discover the corporate Exchange recipients have a 0% click rate because their filter blocked the redirect domain. The fix isn't AMPscript or tracking — it's SAP completion.

10. Lists are legacy; Data Extensions are the only durable audience source

Marketing Cloud supports two audience source types: the legacy List (the old "publication list" model) and Data Extensions. Lists work, but they're deprecating: the platform's modern features (Journey Builder, modern Send Activity, automation triggers, Einstein) all expect DEs. Some older tenants have hundreds of Lists from when Lists were the default, and every send from a List is a piece of legacy debt.

The defense for a new tenant: never use Lists for sendable audiences. Configure every sendable as a DE with explicit columns and a primary key. For an inherited tenant with existing Lists, plan a migration that converts each List to a Sendable DE in a controlled rollout (one program at a time, never all at once).

List-to-DE migration shape:

1. Identify the List's downstream Send Definitions, Journeys,
   Automations.
2. Create the equivalent DE (matching columns + a SubscriberKey PK).
3. Build a parallel Send Definition / Journey / Automation against
   the new DE.
4. Run one cycle in parallel; verify metrics match the List-based
   version.
5. Switch downstream consumers to the DE; deactivate the List-based
   originals.
6. Document the migration in the runbook; archive the List for audit
   but don't delete (CAN-SPAM holds you to its subscriber state).

Closing

These ten are the configuration choices Cleon has seen bite hardest across multi-tenant Marketing Cloud rollouts. The shared theme: MC makes the easy choice easy and the right choice tedious. Defaulting to SubscriberKey, ramping IPs slowly, enforcing DE naming, completing SAP before production — none of them are difficult individually, but each requires explicit attention at exactly the moment the launch team is most eager to skip ahead.

The discipline that prevents most of these failures is a tenant bootstrap checklist that's reviewed by someone who's done a Marketing Cloud rollout before, with veto power over launch dates if the checklist isn't complete. Cleon's bootstrap checklist lives in the team runbook; the items in this article are the heart of it.

If you spot a config gotcha that bit your team and isn't here — write to hello@wearecleon.com. We add it, with credit.

Reference: