---
name: toddkasper/salesforce-marketing-cloud-email-specialist
source: https://app.decimal.ai/s/toddkasper-salesforce-marketing-cloud-email-specialist@1/SKILL.md
source_sha256: e4690d3af48e
---

# Salesforce Marketing Cloud Email Specialist — Skills Reference

## Overview

The **Salesforce Certified Marketing Cloud Email Specialist** (exam code **MC-202**) validates
proven knowledge, skills, and hands-on experience in email marketing best practices within the
Salesforce Marketing Cloud (SFMC) platform. The six exam domains are: Email Marketing Best
Practices, Email Message Design, Content Creation & Delivery, Marketing Automation, Subscriber &
Data Management, and Tracking & Reporting (see domain weights in
[references/study-resources.md](references/study-resources.md)) `[volatile — verify live]`.

This is the primary entry-level certification in the Marketing Cloud track. It is a prerequisite
for advanced credentials such as Marketing Cloud Consultant, Marketing Cloud Developer, and
Marketing Cloud Account Engagement Specialist. Salesforce recommends 6–12 months of hands-on
Marketing Cloud experience before attempting.

**When to reach for Marketing Cloud:** SFMC is the platform for *marketing* sends — campaigns, program updates, recruitment, lifecycle messaging — with engagement tracking, unsubscribe management, and journey automation. *Transactional* 1:1 mail (submit confirmations, password resets, magic-link delivery)
is often better served by a cheaper transactional email service (e.g. Amazon SES) unless a
Triggered Send is already justified by the broader MC adoption. The rules below let an agent make
the transactional-vs-marketing call, design a compliant journey, and avoid the deliverability and
data-model traps that bite teams integrating MC with a CRM.

**This file is an operational playbook, not an exam outline.** Each section states the actual rules
an agent must apply, the concrete limits, the decision criteria for picking a tool, and the
anti-patterns to catch in review.

> **Load this skill when…** designing or reviewing Salesforce Marketing Cloud email campaigns, Journey Builder flows, or Automation Studio pipelines; configuring deliverability (SPF/DKIM/DMARC, IP warming, bounce handling); working with data extensions, AMPscript personalization, or Marketing Cloud Connect; or diagnosing send failures, subscriber status issues, or inbox analytics.
> **Not this skill:** this is SFMC (Studio/Builder stack) — not core CRM email alerts or Pardot/Account Engagement; for CRM email activity tied to Sales or Service Cloud objects, see `salesforce-sales-cloud-consultant` or `salesforce-service-cloud-consultant`.

> **Deeper context:** Study resources (official Salesforce + community) live in [references/study-resources.md](references/study-resources.md) (loaded on demand). For org-specific applications of these rules, keep a per-org appendix in your own project, referenced from a CLAUDE.md. For NPSP/nonprofit-specific guidance, see [salesforce-nonprofit-cloud-consultant](../salesforce-nonprofit-cloud-consultant/SKILL.md).

> **Verify steps assume nothing about your tooling** — use your project's Salesforce MCP connection, the Salesforce CLI (`sf`), or the Salesforce setup UI, in that order of preference.

---

Credential logistics and study path: see [references/study-resources.md](references/study-resources.md).

---

## Uncertainty & Escalation

- **Always re-verify live:** volatile facts in this skill include CAN-SPAM penalty amounts, Gmail/Yahoo bulk-sender thresholds and enforcement dates, 10DLC registration requirements, Data Views default retention periods, IP warming ramp schedules, and any Einstein feature availability or prerequisite — verify against current RFC/FTC/ISP documentation and your SFMC org before acting.
- **Live wins:** when the live org or official documentation contradicts a statement in this file, trust the live source and log the discrepancy via the Feedback protocol below.
- **Escalate to a human before proceeding on:** any production send to an audience > ~50,000 contacts on a new or warmed-but-unvalidated IP; any send that re-activates a list segment not mailed in > 6 months without a re-permission step; enabling or modifying the Master Unsubscribe list; any compliance-related consent or data-erasure workflow.
- **Confidence taxonomy:** every fact in this file is considered stable unless tagged `[volatile — verify live]` or `[opinion — house style]`. If you act on an untagged fact and the live system disagrees, file feedback — do not silently trust this file over the live org.

---

## 1. Email Marketing Best Practices — Operational Rules

### Compliance is non-negotiable; build it into every send

- **Every commercial email MUST carry a physical postal address and a working one-click
  unsubscribe.** CAN-SPAM requires this; omitting it is a per-message violation (up to ~$53,088 per
  email in U.S. penalties `[volatile — verify live]`). In SFMC this lives in the email footer / Delivery Profile, not the body —
  set it at the Delivery Profile so it can't be forgotten per-send.
- **Honor unsubscribes within 10 business days** (CAN-SPAM). SFMC suppresses immediately, so never
  re-add an unsubscribed address via a fresh import — that re-subscribes them and is a violation.
- **Decision — which consent model:**

  | Audience / law | Required consent | Action |
  |---|---|---|
  | U.S. marketing (CAN-SPAM) | Implied OK; opt-out must work | Single opt-in acceptable; footer unsubscribe mandatory |
  | Canada (CASL) | **Express opt-in** required | Capture explicit consent + date/source; no purchased lists |
  | EU/UK (GDPR) | Lawful basis (usually consent) | Double opt-in; honor right-to-erasure; store consent proof |
  | New / risky list, deliverability-sensitive | — | Use **double opt-in (DOI)** regardless of law |

- **RED FLAG:** any plan to send to a *purchased or rented list*. Stop. It tanks sender reputation,
  hits spam traps, and violates CASL/GDPR. Build lists with Web Collect / Smart Capture / DOI only.

### Deliverability — protect the sending domain

- **Authenticate the sending domain with all three: SPF, DKIM, DMARC.** Missing DKIM/DMARC is the
  most common cause of Gmail/Yahoo bulk-sender rejection (both enforce SPF+DKIM+DMARC for senders
  >5,000/day `[volatile — verify live]`). Verify DNS before the first send, not after bounces appear.
- **Warm a new dedicated IP over ~30 days**, ramping volume gradually (e.g. day 1: ~50/send, doubling
  every few days). Blasting full volume on a cold IP gets you throttled or blocklisted.
- **Bounce handling — know the status transition:**

  | Bounce type | Cause | SFMC subscriber status result |
  |---|---|---|
  | **Hard bounce** | Permanent — invalid/nonexistent address | → **Bounced** (auto-suppressed) |
  | **Soft bounce** | Temporary — full mailbox, server timeout, message too large | retried; repeated soft → **Held** |
  | Spam complaint | Recipient hit "report spam" | → **Unsubscribed** |

- **Keep spam-complaint rate < 0.1% and hard-bounce rate low** — Gmail enforces a 0.3% complaint
  threshold `[volatile — verify live]`. Use **List Detective** to screen imports for role addresses (`info@`, `sales@`) and known
  spam-trap patterns before they enter a send.
- **RED FLAG in review:** sending to a list/DE that hasn't been mailed in 6–12+ months with no
  re-permission step → high bounce + complaint risk. Re-engage or suppress stale addresses first.

Email design rules (mobile-first, subject/preheader, A/B test discipline): [references/coverage-additions.md](references/coverage-additions.md).

---

## 1b. Email Message Design — Operational Rules

This is a standalone blueprint domain (13% of the exam `[volatile — verify live]`) covering the design, testing, and approval of email messages before send.

**Core rules to hold inline:**

- **A/B test one variable at a time** — subject line OR from-name OR send-time; define the winner metric (open vs. click vs. conversion) *before* launching; ensure test cells are large enough to be statistically significant. Do not stack multiple variables in a single test.
- **Approvals workflow:** if your SFMC account has the Approvals feature enabled, a send or journey activation that requires approval will be blocked until an approver acts. Build approval lead-time into the send schedule; a pending-approval block is the most common cause of a delayed send that "looks ready."
- **Template vs. free-form:** slot-based templates enforce brand compliance and are the correct choice for multi-author or multi-BU environments; free-form HTML emails are for one-off or developer-built sends. Never edit a template's locked slot structure per-send — that is the compliance control.
- **Rendering validation:** always run a cross-client render check (Litmus or Validate) before a major send. Outlook uses the Word rendering engine and is the most common source of broken layouts; test on Outlook explicitly.

Full email design rules (mobile-first, responsive layout, preheader best practices): [references/coverage-additions.md](references/coverage-additions.md) — the "Email design rules" and "Content Builder: slot-based templates" sections.

---

## 2. Content Creation & Delivery — Operational Rules

### Use Content Builder; treat Classic as legacy

- **Build all new content in Content Builder, not Classic Email Studio.** Content Builder is the
  modern cross-channel CMS (blocks, templates, shared folders). Classic is legacy — only touch it for
  existing assets you must maintain.
- Build reusable **content blocks** (image/text/button/free-form HTML) and **templates** to enforce
  brand consistency. A template change propagates; copy-pasted HTML does not — prefer templates.

### Personalization — pick the right tool

| Need | Use | Notes |
|---|---|---|
| Simple field merge (`First Name`) | **Personalization String** `%%FirstName%%` | Pulls from subscriber attribute / DE field |
| Conditional content, cross-DE lookups | **AMPscript** | `Lookup()`, `IF/THEN`, runs at send time |
| Repeatable row/loop content (e.g. donation list) | **GTL** (Guide Template Language) | Cleaner than AMPscript loops |
| Heavy integration / API calls in-email | **SSJS** | Last resort; slower, harder to debug |
| AI optimization | **Einstein** | See decision table below |

- **Always provide a default/fallback** for personalization strings. `Dear %%FirstName%%,` with a null
  field renders `Dear ,`. Use `IIF(empty(@FirstName), "Friend", @FirstName)` style fallbacks.
- **Einstein feature decision:**

  | Goal | Feature |
  |---|---|
  | Send each contact at their best individual time | Einstein **Send Time Optimization (ESTO)** |
  | Score who's likely to open/click/unsubscribe | Einstein **Engagement Scoring** |
  | Get subject-line copy suggestions | Einstein **Copy Insights** |

### Send configuration — three send types, know which one

| Send type | Trigger | Use when |
|---|---|---|
| **User-Initiated Send** | Manual / scheduled by a user | One-off or scheduled batch campaign (annual appeal) |
| **Triggered Send** | Real-time API/event call | Transactional 1:1 (confirmation, password reset, magic-link/upload email) |
| **Automated Send** | Automation Studio step | Recurring batch on a schedule (weekly digest) |

- **Sender Profile** = From Name / From Address / Reply-To. **Delivery Profile** = header/footer,
  private domain, IP assignment. **Send Classification** = the binding of a Sender + Delivery Profile
  to a CAN-SPAM publication list. Configure the Send Classification once; reuse it so every send
  inherits the compliant footer and correct IP.
- **Always validate before send:** Test Send + Subscriber Preview (render against a real subscriber
  record) + a rendering check (Litmus/Validate). Catch broken personalization and mobile breakage here.
- **RED FLAG:** sending to a list without a Suppression List applied → you may mail unsubscribed or
  bounced addresses. Confirm publication + suppression lists are both wired in the send pipeline.

### Triggered Sends

- A **Triggered Send Definition (TSD)** must be *started/active* to fire. Pausing queues messages;
  republishing is required after editing the email. **RED FLAG:** "the confirmation email stopped
  going out" → first check the TSD is in *Active*, not *Paused*, and was republished after the last edit.

---

## 3. Marketing Automation — Operational Rules

### Journey Builder vs. Automation Studio — the core decision

| Criterion | Journey Builder | Automation Studio |
|---|---|---|
| Pattern | 1:1, contact-centric, real-time orchestration | Batch, data-centric, scheduled processing |
| Best for | Welcome series, nurture sequences, event drip | Nightly data import, SQL segmentation, file transfer/extract |
| Multi-step waits & branching | Yes (Decision/Engagement/Random splits, Wait) | Limited (sequential steps) |
| Entry | Entry Source (DE, Salesforce Data, API, CloudPage…) | Schedule (cron-like) or File Drop (SFTP) |
| Decision rule | "react to each contact as they qualify" → JB | "process a batch on a cadence" → AS |

### Journey Builder

- **Choose the right re-entry mode — it changes who gets re-messaged:**

  | Mode | Behavior |
  |---|---|
  | **No Re-entry** | Contact can be in the journey only once, ever |
  | **Re-entry Any Time** | Contact can be in multiple instances simultaneously |
  | **Re-entry Only After Exiting** | Must finish/exit before qualifying again |

  Welcome series → usually **No Re-entry** (don't welcome a contact twice). Recurring reminder →
  **Re-entry Only After Exiting**.
- **Decision Split** branches on a contact *attribute*; **Engagement Split** branches on *opened/clicked*
  a prior journey email. Use Engagement Split to send a follow-up only to non-openers.
- Set a **Goal** to measure conversion and (optionally) auto-remove contacts who convert. Set **Exit
  Criteria** to pull contacts out when they no longer qualify (e.g. donor unsubscribed).
- **Path Optimizer** tests up to **10** path variants and auto-promotes the winner.
- **Versioning trap:** editing a *running* journey requires a **new version**; in-flight contacts stay
  on the old version until they exit. Stopping a journey ejects in-flight contacts. **RED FLAG:**
  "I changed the email but contacts still get the old one" → they're on the prior published version.

### Automation Studio

- Build automations from these activities: **SQL Query** (run SQL against DEs/Data Views → target DE),
  **Import File** (SFTP CSV → DE), **Data Extract** (export tracking → SFTP file), **File Transfer**
  (move/decrypt SFTP files), **Filter** (Data Filter → Filtered DE), **Send Email**, **Wait**.
- **Execution order:** activities placed in the *same step* run **in parallel**; **steps** run
  **sequentially**. So put dependent work (Import → SQL → Send) in *separate steps* in order, never
  side-by-side. **RED FLAG:** an Import and the SQL that reads it sitting in the same step → race
  condition; the SQL may run against stale data.
- The typical segment-send chain: **SQL Query** (build the audience DE) → **Send Email** (to that DE),
  often preceded by **Import File** (load fresh CRM/SFTP data) and an opening **Wait** for timing.

---

## 4. Subscriber & Data Management — Operational Rules

### Data Extensions over Lists (almost always)

- **Default to Data Extensions, not Subscriber Lists.** Lists are the older, flat, attribute-limited
  model; DEs are relational, column-defined, scalable, and required for sendable segmentation and SQL.
  Use a List only for simple publication/subscription grouping.
- **DE types:**

  | Type | What it is | Use when |
  |---|---|---|
  | **Standard** | Manually defined schema | Most cases — your own data structure |
  | **Filtered** | Subset of a parent DE via a Data Filter | Reusable segment that auto-refreshes from parent |
  | **Random** | Random sample of a parent DE | A/B holdouts, statistical sampling |

- **Design the schema deliberately:** pick correct data types (Text, Number, Decimal, Date, Boolean,
  EmailAddress, Phone, Locale), set a **Primary Key** (prevents duplicate rows on Add/Update), and mark
  nullable fields. A **Sendable DE** must have a field relating it to the Subscriber Key.
- **Subscriber Key** = the unique subscriber identifier across all business units. Decide it once
  (often the CRM Contact ID via MCC) and never change it — it's the spine of all tracking.
- **Mirror source field lengths when designing DE column widths.** When syncing CRM fields into a DE,
  size the DE column to match the source field length so imports don't silently truncate.

### Subscriber status lifecycle — and unsubscribe scope

- Four statuses: **Active**, **Bounced** (hard bounce), **Held** (undeliverable after repeated soft
  bounces), **Unsubscribed**.
- **Unsubscribe scope — one wrong word changes blast radius:**

  | Scope | Effect |
  |---|---|
  | **List Unsubscribe** | Off one specific list/publication only |
  | **Global Unsubscribe** | Off *all* lists in the **business unit** |
  | **Master Unsubscribe** | Off **everything across the entire MC account** (all BUs) |

  **RED FLAG:** processing a one-list opt-out as a Master Unsubscribe → you silently kill that
  contact's eligibility for every future send org-wide.

Profile Attributes vs. Preference Attributes, Subscription Center configuration, Web Collect vs. Smart Capture, and Double Opt-In setup: [references/coverage-additions.md](references/coverage-additions.md).

### Data import — pick the update mode

| Mode | Effect | Use when |
|---|---|---|
| **Add/Update** | Insert new, update existing (matched on PK) | Default for ongoing syncs |
| **Add Only** | Insert new, skip existing | Append-only feeds |
| **Update Only** | Update existing, skip new | Enriching known records |
| **Overwrite** | **Truncate the DE, then load** | Full nightly snapshot replacement — destructive |
| **Delete** | Remove matching rows | Targeted removal |

- **RED FLAG:** using **Overwrite** on a DE that another process appends to → you wipe their data
  every run. Overwrite is for full-snapshot DEs only.

### Segmentation — Data Filters vs. SQL

- **Data Filter** for simple AND/OR on attributes (drag-and-drop, produces a Filtered DE).
- **SQL Query Activity** for anything relational, aggregated, or cross-Data-View (e.g. "subscribers
  with no `_Click` in 90 days"). SQL writes to a *target DE*; it cannot send directly.
- **Key queryable Data Views (read-only system tables):** `_Sent`, `_Open`, `_Click`, `_Bounce`,
  `_Unsubscribe`, `_Complaint`, `_Job`, `_Subscriber`, `_ListSubscribers`. Data Views retain ~6 months
  of data by default `[volatile — verify live]` — for longer history, extract to a DE on a schedule.

### Marketing Cloud Connect (MCC) — the CRM bridge

MCC deep-dive (Synchronized Data Sources vs. Salesforce Send, integration user FLS verification, custom object exposure): [references/coverage-additions.md](references/coverage-additions.md).

Core rule to hold inline: **verify the CRM objects you intend to segment on are actually synced AND that the MCC integration user has FLS Read on every field** before building a journey — a synced field with no FLS returns blank, not an error.

---

## 5. Tracking & Reporting — Operational Rules

Key metric definitions (Delivered, Open Rate, CTOR, Click Rate, Bounce Rate, Unsubscribe Rate, Spam Complaint Rate), the report-selection table (Account Send Summary, Campaign Email Tracking, Email Performance by Domain, Bounce Summary, etc.), and guidance on Tracking Extracts and Data View SQL for re-engagement suppression: [references/analytics-reports.md](references/analytics-reports.md) — load when building dashboards, diagnosing deliverability trends, or writing engagement-suppression queries.

Core rule to hold inline: **lean on clicks/CTOR, not opens** — open tracking is pixel-based and unreliable since Apple Mail Privacy Protection pre-fetches pixels.

---

## Operational Rules Quick Reference

- **DO** put a physical postal address + working unsubscribe in every commercial email (set at the
  Delivery Profile / Send Classification, not per-send).
- **DO** authenticate the sending domain with SPF + DKIM + DMARC before the first send.
- **DO** warm a new dedicated IP over ~30 days with a gradual volume ramp.
- **DO** default to **Data Extensions** over Subscriber Lists; set a Primary Key to avoid dupes.
- **DO** use **Triggered Sends** for 1:1 transactional, **Journey Builder** for 1:1 real-time
  orchestration, **Automation Studio** for scheduled batch.
- **DO** apply a Suppression List to every send and validate with Test Send + Subscriber Preview first.
- **DO** provide a fallback for every personalization string (no `Dear ,`).
- **DO** put dependent automation activities in *separate sequential steps* (same-step = parallel).
- **DO** lean on **clicks/CTOR** over open rate (pixel opens are unreliable post-MPP).
- **DO** verify CRM objects are actually synced — and FLS-readable to the integration user — via MCC
  before building journeys on them.
- **DON'T** ever mail a purchased or rented list — reputation, spam traps, CASL/GDPR violation.
- **DON'T** re-import an unsubscribed/bounced address — it silently re-subscribes them (violation).
- **DON'T** confuse unsubscribe scope: List ≠ Global (whole BU) ≠ Master (whole account).
- **DON'T** use **Overwrite** import on a DE that another process appends to — it truncates first.
- **DON'T** edit a running Journey and expect in-flight contacts to switch — publish a new version.
- **DON'T** trust open rate alone for re-engagement/suppression decisions (Apple MPP inflates it).
- **DON'T** leave a Triggered Send Definition Paused or un-republished after an email edit, then wonder
  why nothing sends.
- **DON'T** put an Import and the SQL that reads it in the same automation step (race condition).
- **DON'T** treat soft and hard bounces alike: hard → Bounced/suppressed; repeated soft → Held.

> For org-specific applications of these rules, see a per-org appendix you maintain in your own project, referenced from a CLAUDE.md.

---

## 6. Coverage Additions

Extended rules for Content Builder slot-based templates, Automation Studio File Drop / Run Once,
AMPscript `Lookup()` empty-return, Marketing Cloud Intelligence (Datorama), and publication vs.
suppression list wiring: [references/coverage-additions.md](references/coverage-additions.md).

---

## Executable Workflows

### 1. Build a welcome journey (data extension → entry source → sends → verify)

1. Create a Sendable Data Extension with a Subscriber Key field and any personalization fields (FirstName, etc.). Set a Primary Key. → **gate: DE appears in Email Studio; `SELECT COUNT(*) FROM <DE>` returns rows after a test import.**
2. In Content Builder, build the welcome email with a fallback for every personalization string (e.g. `IIF(empty(@FirstName), "Friend", @FirstName)`). Test Send to a seed address. → **gate: seed receives the email; personalization renders; no blank fields.**
3. In Journey Builder → New Journey: select the DE as the Entry Source. Set Entry Schedule (when to evaluate) and re-entry mode (**No Re-entry** for a welcome series). → **gate: entry source shows record count > 0 in preview.**
4. Add Send Email activity; link to the welcome email and the appropriate Send Classification. Add a Wait step if a follow-up email is needed. → **gate: Validate the journey — no red errors.**
5. Activate the journey. → **gate: Journey History shows contacts entering; Email Tracking shows sends and at least one open/click after sending to a seed.**

### 2. Set up an Automation Studio batch pipeline (import → SQL → send)

1. Upload the source CSV to the SFTP Marketing Cloud folder. → **gate: confirm file is present in SFTP with expected row count.**
2. In Automation Studio → New Automation: add **Step 1** — Import File activity (source: SFTP file path, destination: Contacts DE, mode: Add/Update). → **gate: run Step 1 alone; query the DE — row count matches the file.**
3. Add **Step 2** (new step, not same step) — SQL Query activity. Write the SQL selecting the audience from the DE joined to any Data Views needed. Target DE = the send audience DE. → **gate: run the SQL in Query Studio first; confirm row count and no syntax errors.**
4. Add **Step 3** — Send Email activity pointing at the target DE and the correct Send Classification (Sender + Delivery Profile + suppression list wired). → **gate: test the full automation in a sandbox BU before the first production run.**
5. Schedule the automation (cron-like schedule or File Drop trigger). → **gate: Activity History after first scheduled run shows all three steps as "Complete" with no errors.**

### 3. Harden deliverability (SPF/DKIM/DMARC + IP warming + bounce handling)

1. Verify DNS records for the sending domain: SPF `include:` entry for SFMC, DKIM CNAME pointing to SFMC, DMARC `p=quarantine` (or `reject` once stable). Use a DNS-lookup tool (e.g. MXToolbox). → **gate: all three pass with no lookup errors.**
2. Confirm the Sender Authentication Package (SAP) is configured in SFMC: Setup → Account Settings → Sender Authentication Package. `[volatile — verify live]` → **gate: SAP shows the domain and DKIM signing is active.**
3. Plan the IP warming ramp: start ~50 sends/day on the new IP, doubling every few days over ~30 days, targeting highest-engagement contacts first. → **gate: no block-listing alerts (monitor via SFMC Deliverability dashboard or external tools) in the first two weeks.**
4. Apply List Detective to every new import: Admin → List Detective → run before activating any new send list. → **gate: List Detective report shows 0 known spam-trap or role-address hits in the audience.**
5. Monitor bounce handling post-send: query SFMC Bounce Summary report or SQL `SELECT * FROM _Bounce WHERE EventDate > DATEADD(day,-1,GETDATE())`. Confirm hard-bounce addresses are suppressed (status = Bounced), soft-bounce addresses show retry logic. → **gate: hard-bounce rate < 2% on warm lists; any spike triggers a list-hygiene review before the next send.**

---

## Decision Scenarios

### Scenario 1 — Automation step ordering

**Situation:** A nightly automation imports a fresh CSV from SFTP into a Contacts DE, then runs a SQL
query that joins that DE with `_Click` to build today's re-engagement audience. A developer places
both activities side-by-side in Step 1 to "save time."

**Competent move:** Separate the Import and the SQL into sequential steps — Import in Step 1, SQL in
Step 2. Activities in the same step run in parallel, so the SQL executes concurrently with the import
and reads stale or partially loaded data. Moving them to separate steps guarantees the import commits
before the SQL starts.

**Tempting-but-wrong:** Assuming SFMC runs activities left-to-right within a step. It does not; same-
step activities are parallel by design. Adding a Wait activity inside the same step does not fix it —
Wait is a step-level construct, not an intra-step sequencer.

**Verify:** In Automation Studio, open the automation and confirm the Import activity and SQL Query
activity are in *different numbered steps*, with the Import step preceding the SQL step. Check the
Activity History after a run — both activities show a start timestamp; if they match to the second,
they ran concurrently.

---

### Scenario 2 — Unsubscribe scope error

**Situation:** A subscriber replies "remove me from your volunteer list." A support agent opens SFMC
and clicks the subscriber record's global "Unsubscribe" button to process the request quickly.

**Competent move:** Use a **List Unsubscribe** scoped to the volunteer publication list only, not the
global action. The global unsubscribe removes the contact from every send in the entire business unit —
they will also stop receiving donation receipts, event confirmations, and any other publication.
Instead, navigate to the subscriber's list subscriptions, find the volunteer list, and change their
status on that list to Unsubscribed.

**Tempting-but-wrong:** Using the "Unsubscribe" button on the subscriber profile page, which applies a
Global Unsubscribe at the BU level. It looks like the right action — it's prominently placed and the
label says "Unsubscribe" — but it silently kills delivery eligibility across all programs.

**Verify:** After processing, check the subscriber's **Subscription Summary**: they should show
*Unsubscribed* on the volunteer list and *Active* on all other publication lists. If they appear
globally unsubscribed, reverse by setting their All Subscribers status back to Active and reprocessing
as a list-scoped opt-out.

---

### Scenario 3 — Journey re-entry mode for a recurring reminder

**Situation:** An organization sends a recurring "membership renewal reminder" journey. Contacts who renewed last year should re-enter the journey again when their next renewal window opens.

**Competent move:** Set re-entry mode to **Re-entry Only After Exiting**. This lets a contact re-enter
after they have fully exited the journey (renewal cycle completed), while preventing them from being
in two concurrent instances of the same journey. Configure an Exit Criteria tied to "membership
renewed = true" so contacts leave as soon as they act, not after sitting through all wait steps.

**Tempting-but-wrong:** Setting **Re-entry Any Time**, which allows a contact to be in multiple
simultaneous instances. In a renewal journey, that means a contact who qualifies for two consecutive
cycles could receive two parallel sequences of renewal emails — duplicate messaging that damages trust.
Alternatively, leaving it as **No Re-entry** means a contact who renewed last year never receives
another renewal journey, which defeats the recurring purpose.

**Verify:** In Journey Builder, open the Journey Settings panel and confirm the re-entry mode. After
a contact exits and re-qualifies, check Journey History to confirm a new entry record was created
for that contact (distinct journey entry ID) in the new cycle.

---

Scenarios 4–5 (TSD left paused after email edit; AMPscript `Lookup()` blank return without error): [references/scenarios.md](references/scenarios.md) — load for Triggered Send and AMPscript debugging gotchas.

---

## Study resources & relevance

Study resources and recommended study plan: [references/study-resources.md](references/study-resources.md). For NPSP/nonprofit-specific guidance, see [salesforce-nonprofit-cloud-consultant](../salesforce-nonprofit-cloud-consultant/SKILL.md).

---

## Feedback protocol

Using this skill and hit a wall? If you find a claim contradicted by the live system or official docs, a missing rule that cost you a wrong attempt, or a decision this skill gave no criteria for — append an entry **in the moment** to `.skill-feedback/salesforce-marketing-cloud-email-specialist.md` at the project root (create it if absent):

`date | skill last-reviewed | claim or gap | what you observed instead | evidence (error text / doc URL / query output) | suggested fix`

These are harvested back into the skill via the learning loop. When the live system and this file disagree, trust the live system.

## Changelog

- **2026-06-10** — Cycle-4 curation (inbox): (1) Passing score corrected 67%→65% (~39/60) with `[volatile — verify live]` tag in study-resources.md. (2) Domain weights updated to official six-domain blueprint: Best Practices 15%, Email Message Design 13%, Content Creation & Delivery 18%, Marketing Automation 19%, Subscriber & Data Management 28%, Tracking & Reporting 7% — all marked `[volatile — verify live]`; study-resources.md domain table, study-plan, and Trailhead module list all updated. (3) New §1b "Email Message Design" added (inline A/B testing rules, Approvals workflow, template vs. free-form guidance, rendering validation); pointer to existing coverage-additions.md for full rules. (4) §5 renamed from "Insights & Analytics" to "Tracking & Reporting" throughout SKILL.md, analytics-reports.md, and study-resources.md; Overview updated to list all six current exam domains. `last-reviewed` updated to 2026-06-10. Eval probes 13–14 added.
- **2026-06-09** — Conformed to the 12-dimension skill standard: task-vocab description + Scope block, Uncertainty & Escalation guidance with inline `[volatile — verify live]` marks, executable workflows, tool-agnostic verify steps, and the feedback protocol above. Exam logistics relocated to references/study-resources.md; `last-reviewed` set to 2026-06-09. Section 5 (Insights & Analytics detail) moved to references/analytics-reports.md to keep body within word budget.

---

*Independent educational content to upskill AI agents. Not affiliated with or endorsed by Salesforce;
all trademarks belong to their respective owners. Guidance only — verify against official documentation
and live orgs before acting. No certification outcome is implied or guaranteed.*