MC Administrator Interview Questions
25 expert-curated questions on account hierarchy, SAP, Contact Builder, data retention, and API administration.
MC Administrator Interview Questions
Enterprise 2.0 (E2.0) is Marketing Cloud's multi-tenant account structure. It consists of a parent Business Unit (BU) and one or more child BUs. The parent BU controls enterprise-level settings and can lock configurations (send classifications, sender profiles, delivery profiles) so child BUs cannot override them.
Data sharing between BUs:
— Shared Data Extensions: Data extensions created in the parent BU can be shared (read-only or read/write) to child BUs via the Sharing settings on the DE.
— Shared Content: Content Builder assets in the parent BU can be shared to all child BUs as global content (locked) or shared content (editable).
— Subscriber data: The AllSubscribers list and Contact Builder contacts are shared at the Enterprise level. A contact unsubscribed in one BU is not automatically unsubscribed in another BU (unless a global unsubscribe is used).
— Reports and tracking: Each BU has its own tracking data; parent admins can view reports across all BUs in Enterprise Analytics.
Data sharing between BUs:
— Shared Data Extensions: Data extensions created in the parent BU can be shared (read-only or read/write) to child BUs via the Sharing settings on the DE.
— Shared Content: Content Builder assets in the parent BU can be shared to all child BUs as global content (locked) or shared content (editable).
— Subscriber data: The AllSubscribers list and Contact Builder contacts are shared at the Enterprise level. A contact unsubscribed in one BU is not automatically unsubscribed in another BU (unless a global unsubscribe is used).
— Reports and tracking: Each BU has its own tracking data; parent admins can view reports across all BUs in Enterprise Analytics.
System roles (out-of-the-box):
— Administrator: Full access to all features and administration settings.
— Analyst: Read-only access to reports and tracking data.
— Content Creator: Can create and edit emails and content blocks; cannot send.
— Channel Manager: Can create, approve, and send emails and other channel messages.
— Security Administrator: Manages user access, roles, and SSO configuration.
Custom roles: Administrators can create custom roles by selecting granular permissions at the product, feature, and action level (View, Edit, Publish, Delete). Custom roles are useful for organisations with specific access requirements not met by system roles (e.g., a role that can send emails but cannot modify content blocks).
SSO: Marketing Cloud supports SSO with a connected Salesforce org via MC Connect, allowing users to log in with their Salesforce credentials.
— Administrator: Full access to all features and administration settings.
— Analyst: Read-only access to reports and tracking data.
— Content Creator: Can create and edit emails and content blocks; cannot send.
— Channel Manager: Can create, approve, and send emails and other channel messages.
— Security Administrator: Manages user access, roles, and SSO configuration.
Custom roles: Administrators can create custom roles by selecting granular permissions at the product, feature, and action level (View, Edit, Publish, Delete). Custom roles are useful for organisations with specific access requirements not met by system roles (e.g., a role that can send emails but cannot modify content blocks).
SSO: Marketing Cloud supports SSO with a connected Salesforce org via MC Connect, allowing users to log in with their Salesforce credentials.
The Sender Authentication Package (SAP) is a premium add-on that bundles several authentication and branding features into a single configuration:
1. Private (Custom) Domain: A dedicated sending domain (e.g.,
2. Dedicated IP Address: An IP address reserved exclusively for your sends. Provides control over IP reputation.
3. Sender Authentication: Configures SPF and DKIM records on your private domain so emails pass authentication checks aligned to your From domain.
4. Reply Mail Management (RMM): Processes replies and out-of-office messages sent to the reply-to address; can forward replies, trigger automatic unsubscribes on reply keywords, and suppress auto-replies from being counted.
5. Custom Tracking Domain: Click and open tracking links use your private domain (e.g.,
1. Private (Custom) Domain: A dedicated sending domain (e.g.,
email.yourcompany.com) instead of the default @exacttarget.com or shared domain. Required for DKIM alignment with your From domain.2. Dedicated IP Address: An IP address reserved exclusively for your sends. Provides control over IP reputation.
3. Sender Authentication: Configures SPF and DKIM records on your private domain so emails pass authentication checks aligned to your From domain.
4. Reply Mail Management (RMM): Processes replies and out-of-office messages sent to the reply-to address; can forward replies, trigger automatic unsubscribes on reply keywords, and suppress auto-replies from being counted.
5. Custom Tracking Domain: Click and open tracking links use your private domain (e.g.,
click.email.yourcompany.com) instead of Salesforce domains — improving deliverability and brand trust.
Setting up a private domain requires the following DNS records on your domain:
CNAME for tracking domain: Maps your custom tracking subdomain (e.g.,
CNAME for landing pages: Maps your CloudPages/landing page subdomain to the Salesforce-hosted endpoint.
TXT record for SPF: Adds
CNAME records for DKIM selectors: Two CNAME records pointing the DKIM selector subdomains (e.g.,
DNS propagation can take up to 48 hours. Salesforce provides specific CNAME/TXT values during the SAP provisioning process in Setup.
CNAME for tracking domain: Maps your custom tracking subdomain (e.g.,
click.email.yourcompany.com) to click.mailing.exacttarget.com — enables branded click/open tracking links.CNAME for landing pages: Maps your CloudPages/landing page subdomain to the Salesforce-hosted endpoint.
TXT record for SPF: Adds
include:cust-spf.exacttarget.com to your domain's SPF record to authorise Marketing Cloud's sending IPs.CNAME records for DKIM selectors: Two CNAME records pointing the DKIM selector subdomains (e.g.,
s1._domainkey.email.yourcompany.com) to the Marketing Cloud DKIM key hosting endpoints. Marketing Cloud manages the private key; you only publish the CNAME.DNS propagation can take up to 48 hours. Salesforce provides specific CNAME/TXT values during the SAP provisioning process in Setup.
RMM (Reply Mail Management) is the SAP component that manages inbound replies to marketing emails. When a subscriber hits "Reply" on an email, instead of going directly to an inbox, the reply is processed by Marketing Cloud's RMM system first.
Reply-to address types:
— No-Reply address: Replies are processed by RMM; out-of-office and auto-replies are discarded. Human replies can be forwarded to a specified mailbox.
— Profile reply-to: The reply goes to the email address defined in the Sender Profile.
— Custom reply-to address: A specific email address defined per email or send classification.
Automatic unsubscribe actions: RMM can scan reply email subjects/bodies for unsubscribe keywords (e.g., "unsubscribe", "remove me") and automatically unsubscribe the replying contact, ensuring compliance even for subscribers who reply instead of clicking the unsubscribe link.
Out-of-office filtering: Auto-reply messages (vacation responders) are identified and discarded to avoid cluttering the forwarding mailbox.
Reply-to address types:
— No-Reply address: Replies are processed by RMM; out-of-office and auto-replies are discarded. Human replies can be forwarded to a specified mailbox.
— Profile reply-to: The reply goes to the email address defined in the Sender Profile.
— Custom reply-to address: A specific email address defined per email or send classification.
Automatic unsubscribe actions: RMM can scan reply email subjects/bodies for unsubscribe keywords (e.g., "unsubscribe", "remove me") and automatically unsubscribe the replying contact, ensuring compliance even for subscribers who reply instead of clicking the unsubscribe link.
Out-of-office filtering: Auto-reply messages (vacation responders) are identified and discarded to avoid cluttering the forwarding mailbox.
Data Retention Policies can be configured on individual Data Extensions to automate data lifecycle management:
Retention options for individual records:
— Keep all records and data extension: No automatic deletion — default.
— Delete individual records: Delete records older than N days, or delete records before a specific date.
— Delete all records and data extension: Deletes the entire DE (records and schema) after a specified period.
Timing: Retention jobs run daily at a system-scheduled time, not at a precise user-defined time.
Best practice: Set retention policies on high-volume send logs, tracking DEs, and temporary import DEs to prevent unbounded growth. Always retain records long enough for suppression, compliance, and analytics needs — typically at least 6 months for send tracking DEs.
Contact Builder consideration: Data retention on a DE does not automatically delete contact records from Contact Builder; use the Contact Delete API for GDPR-compliant erasure.
Retention options for individual records:
— Keep all records and data extension: No automatic deletion — default.
— Delete individual records: Delete records older than N days, or delete records before a specific date.
— Delete all records and data extension: Deletes the entire DE (records and schema) after a specified period.
Timing: Retention jobs run daily at a system-scheduled time, not at a precise user-defined time.
Best practice: Set retention policies on high-volume send logs, tracking DEs, and temporary import DEs to prevent unbounded growth. Always retain records long enough for suppression, compliance, and analytics needs — typically at least 6 months for send tracking DEs.
Contact Builder consideration: Data retention on a DE does not automatically delete contact records from Contact Builder; use the Contact Delete API for GDPR-compliant erasure.
Contact Builder is the identity resolution and data modelling layer in Marketing Cloud. It links data from multiple sources into a unified contact profile.
Attribute Groups: A named collection of related attribute sets (DEs) that share a relationship to the contact. For example, an "E-commerce" group might contain Purchase History, Product Views, and Cart Abandonment DEs, all linked to the contact via ContactKey.
Attribute Sets: Individual Data Extensions linked into Contact Builder. Each attribute set must be linked to a contact via a shared key field (e.g., ContactKey, Email).
Populations: Named groups of contacts with common characteristics defined by a filter. Types:
— Individual: One contact per person (most common).
— Household: Groups contacts by a household key.
— Account: Groups contacts by an account/company key.
Contact count vs Sendable contact count: Contact Builder counts all contacts in the system (billable); sendable contacts are those with a valid email address on a sendable DE who are not globally unsubscribed.
Attribute Groups: A named collection of related attribute sets (DEs) that share a relationship to the contact. For example, an "E-commerce" group might contain Purchase History, Product Views, and Cart Abandonment DEs, all linked to the contact via ContactKey.
Attribute Sets: Individual Data Extensions linked into Contact Builder. Each attribute set must be linked to a contact via a shared key field (e.g., ContactKey, Email).
Populations: Named groups of contacts with common characteristics defined by a filter. Types:
— Individual: One contact per person (most common).
— Household: Groups contacts by a household key.
— Account: Groups contacts by an account/company key.
Contact count vs Sendable contact count: Contact Builder counts all contacts in the system (billable); sendable contacts are those with a valid email address on a sendable DE who are not globally unsubscribed.
The AllSubscribers list is the master subscriber repository in Marketing Cloud. Every contact who receives an email is added here.
Subscriber Key best practices:
— Use a persistent, unique identifier (CRM ID, customer ID) as the subscriber key rather than email address.
— Email addresses change; a CRM ID never changes — this prevents duplicate subscriber records when a customer updates their email.
— In a connected Salesforce org, use the Salesforce Contact or Lead ID as the subscriber key for seamless sync.
— The subscriber key should match the
Subscriber statuses:
— Active: Eligible to receive emails.
— Unsubscribed: Globally opted out; no commercial sends.
— Held: Automatically placed on hold after bouncing multiple times; requires admin review to reactivate.
— Bounced: Has received at least one hard bounce.
Subscriber Key best practices:
— Use a persistent, unique identifier (CRM ID, customer ID) as the subscriber key rather than email address.
— Email addresses change; a CRM ID never changes — this prevents duplicate subscriber records when a customer updates their email.
— In a connected Salesforce org, use the Salesforce Contact or Lead ID as the subscriber key for seamless sync.
— The subscriber key should match the
ContactKey used in Contact Builder for unified data linkage.Subscriber statuses:
— Active: Eligible to receive emails.
— Unsubscribed: Globally opted out; no commercial sends.
— Held: Automatically placed on hold after bouncing multiple times; requires admin review to reactivate.
— Bounced: Has received at least one hard bounce.
Subscriber list (standard list): A basic collection of subscribers used as a send audience. Subscribers can be added manually, via import, or via a form. Supports basic segmentation.
Publication list: A special list type used for preference centre management. Represents an email topic or category (e.g., "Weekly Newsletter", "Product Updates"). Subscribers can opt out of individual publication lists without globally unsubscribing. Used with Commercial send classification — a subscriber unsubscribed from a publication list will not receive emails associated with that list but will still receive emails from other publication lists.
Suppression list: A list of subscribers who should never receive a specific email or any emails. Can be applied at the BU level or at the individual send level. Suppression lists are checked at send time — even if an address appears in the send audience, it is excluded if on the suppression list. Used for legal holds, competitor suppression, and do-not-contact lists.
Publication list: A special list type used for preference centre management. Represents an email topic or category (e.g., "Weekly Newsletter", "Product Updates"). Subscribers can opt out of individual publication lists without globally unsubscribing. Used with Commercial send classification — a subscriber unsubscribed from a publication list will not receive emails associated with that list but will still receive emails from other publication lists.
Suppression list: A list of subscribers who should never receive a specific email or any emails. Can be applied at the BU level or at the individual send level. Suppression lists are checked at send time — even if an address appears in the send audience, it is excluded if on the suppression list. Used for legal holds, competitor suppression, and do-not-contact lists.
Dedicated IP allocation: Requested through Salesforce Support and provisioned to a specific BU. Multiple dedicated IPs can be assigned to a single BU for load distribution.
IP Groups (pools): Multiple IPs can be grouped into a pool. When an IP group is assigned to a delivery profile, Marketing Cloud distributes sends across all IPs in the group — useful for high-volume senders to spread load and protect individual IP reputation.
IP warming tracking: Admins track warm-up progress manually or via inbox placement tools. Marketing Cloud does not have a built-in IP warming schedule; admins must manually segment audiences by engagement level during warm-up.
IP reputation monitoring: Use third-party tools such as Validity (formerly Return Path) or Sender Score to monitor IP reputation, blacklist listings, and inbox placement rates. Marketing Cloud does not include native IP reputation monitoring.
Blacklist check: If an IP is blacklisted (e.g., by Spamhaus, Barracuda), request delisting after identifying and resolving the root cause (e.g., spam complaints, spam traps, high bounce rates).
IP Groups (pools): Multiple IPs can be grouped into a pool. When an IP group is assigned to a delivery profile, Marketing Cloud distributes sends across all IPs in the group — useful for high-volume senders to spread load and protect individual IP reputation.
IP warming tracking: Admins track warm-up progress manually or via inbox placement tools. Marketing Cloud does not have a built-in IP warming schedule; admins must manually segment audiences by engagement level during warm-up.
IP reputation monitoring: Use third-party tools such as Validity (formerly Return Path) or Sender Score to monitor IP reputation, blacklist listings, and inbox placement rates. Marketing Cloud does not include native IP reputation monitoring.
Blacklist check: If an IP is blacklisted (e.g., by Spamhaus, Barracuda), request delisting after identifying and resolving the root cause (e.g., spam complaints, spam traps, high bounce rates).
Sender Profile: Defines the identity of the sender as seen by the recipient:
— From Name (display name in inbox)
— From Email Address (must be an authenticated domain with SAP)
— Reply-to Email Address (optional override; used with RMM)
Multiple sender profiles can exist per BU for different brands, products, or sub-brands. Profiles can be locked at the parent BU so child BUs cannot change the From address.
Delivery Profile: Defines the infrastructure and compliance settings for the send:
— Physical mailing address (required by CAN-SPAM)
— IP address or IP pool to use for sending
— Header/footer content (can include standard unsubscribe links)
— Encoding
Both are combined in a Send Classification. When creating an email send, the send classification (or individually selected sender/delivery profiles) determines how the message is authenticated, which IP it comes from, and what compliance elements are included.
— From Name (display name in inbox)
— From Email Address (must be an authenticated domain with SAP)
— Reply-to Email Address (optional override; used with RMM)
Multiple sender profiles can exist per BU for different brands, products, or sub-brands. Profiles can be locked at the parent BU so child BUs cannot change the From address.
Delivery Profile: Defines the infrastructure and compliance settings for the send:
— Physical mailing address (required by CAN-SPAM)
— IP address or IP pool to use for sending
— Header/footer content (can include standard unsubscribe links)
— Encoding
Both are combined in a Send Classification. When creating an email send, the send classification (or individually selected sender/delivery profiles) determines how the message is authenticated, which IP it comes from, and what compliance elements are included.
Journey Builder is a separately licenced product in Marketing Cloud. Licence requirements:
Journey Builder licence: Required to create, edit, and run journeys. Without this licence, the Journey Builder app is not accessible in the MC navigation.
Email Studio licence: Required to send email messages from within Journey Builder. Journey Builder email activities will not function without Email Studio access.
Contact Builder: Included with the Marketing Cloud platform — no separate licence needed. Contact Builder is the data infrastructure underlying Journey Builder's contact data.
Mobile Studio (SMS/Push): Required to add SMS or push notification activities to journeys.
Advertising Studio: Required to add advertising audience activities (Facebook, Google sync) to journeys.
Einstein features: Einstein Send Time Optimisation and Einstein Engagement Frequency require the Einstein Engagement Scoring add-on licence.
Licences are managed at the Enterprise level and allocated per BU as needed.
Journey Builder licence: Required to create, edit, and run journeys. Without this licence, the Journey Builder app is not accessible in the MC navigation.
Email Studio licence: Required to send email messages from within Journey Builder. Journey Builder email activities will not function without Email Studio access.
Contact Builder: Included with the Marketing Cloud platform — no separate licence needed. Contact Builder is the data infrastructure underlying Journey Builder's contact data.
Mobile Studio (SMS/Push): Required to add SMS or push notification activities to journeys.
Advertising Studio: Required to add advertising audience activities (Facebook, Google sync) to journeys.
Einstein features: Einstein Send Time Optimisation and Einstein Engagement Frequency require the Einstein Engagement Scoring add-on licence.
Licences are managed at the Enterprise level and allocated per BU as needed.
MobileConnect (SMS/MMS):
— Short codes: 5–6 digit numbers (e.g., 12345) used for high-volume SMS marketing. Pre-approved by carriers, highest throughput (up to 100 SMS/second), requires carrier approval process (6–12 weeks). Best for promotions and marketing campaigns.
— Long codes (10DLC): Standard 10-digit phone numbers registered with The Campaign Registry (TCR) for A2P (Application-to-Person) messaging. Lower throughput, lower cost, suitable for transactional and conversational messaging. Requires brand and campaign registration.
— Toll-free numbers: 1-800 style numbers that can send SMS. Mid-range throughput. Require verification. Suitable for transactional messages and moderate-volume marketing.
MobilePush (push notifications): Requires configuring an app in MobilePush with:
— iOS: APNs (Apple Push Notification service) certificate or key
— Android: FCM (Firebase Cloud Messaging) server key
Contact-level opt-in/opt-out is managed per device registration, not per subscriber key, since a subscriber can have multiple devices.
— Short codes: 5–6 digit numbers (e.g., 12345) used for high-volume SMS marketing. Pre-approved by carriers, highest throughput (up to 100 SMS/second), requires carrier approval process (6–12 weeks). Best for promotions and marketing campaigns.
— Long codes (10DLC): Standard 10-digit phone numbers registered with The Campaign Registry (TCR) for A2P (Application-to-Person) messaging. Lower throughput, lower cost, suitable for transactional and conversational messaging. Requires brand and campaign registration.
— Toll-free numbers: 1-800 style numbers that can send SMS. Mid-range throughput. Require verification. Suitable for transactional messages and moderate-volume marketing.
MobilePush (push notifications): Requires configuring an app in MobilePush with:
— iOS: APNs (Apple Push Notification service) certificate or key
— Android: FCM (Firebase Cloud Messaging) server key
Contact-level opt-in/opt-out is managed per device registration, not per subscriber key, since a subscriber can have multiple devices.
CloudPages are hosted on Salesforce-managed infrastructure with the following security options:
SSL: All CloudPages served over HTTPS by default on Salesforce domains. For custom domains, you provide an SSL certificate (or Salesforce provisions one via Let's Encrypt) and configure a CNAME DNS record pointing your custom domain to the CloudPages endpoint.
Custom domain setup: In CloudPages Setup, add a custom domain, verify DNS ownership via a TXT or CNAME record, then associate it with a CloudPages collection. Custom domains improve brand trust and deliverability of CloudPages links in emails.
WAF (Web Application Firewall) and DDoS protection: Salesforce provides platform-level WAF and DDoS protection for all CloudPages. Customers cannot configure custom WAF rules at the application layer but can contact Salesforce Support for IP allowlisting.
Access control: CloudPages do not have native authentication (login walls) out of the box. Use AMPscript token validation, query string parameters, or Marketing Cloud personalisation strings to control who can view content on a page.
SSL: All CloudPages served over HTTPS by default on Salesforce domains. For custom domains, you provide an SSL certificate (or Salesforce provisions one via Let's Encrypt) and configure a CNAME DNS record pointing your custom domain to the CloudPages endpoint.
Custom domain setup: In CloudPages Setup, add a custom domain, verify DNS ownership via a TXT or CNAME record, then associate it with a CloudPages collection. Custom domains improve brand trust and deliverability of CloudPages links in emails.
WAF (Web Application Firewall) and DDoS protection: Salesforce provides platform-level WAF and DDoS protection for all CloudPages. Customers cannot configure custom WAF rules at the application layer but can contact Salesforce Support for IP allowlisting.
Access control: CloudPages do not have native authentication (login walls) out of the box. Use AMPscript token validation, query string parameters, or Marketing Cloud personalisation strings to control who can view content on a page.
Advertising Studio is a Marketing Cloud product that enables you to sync Marketing Cloud audience segments to advertising platforms for targeted or suppressed advertising.
Supported platforms: Facebook/Instagram Custom Audiences, Google Customer Match, LinkedIn Matched Audiences, Twitter (X) Tailored Audiences.
Sync process:
1. Connect Advertising Studio to the ad platform's ad account via OAuth.
2. Create an Audience in Advertising Studio linked to a Marketing Cloud data extension or subscriber list.
3. Advertising Studio hashes PII (email, phone) before sending to the ad platform; the platform matches hashed records to its user base — raw data never leaves Salesforce.
Minimum audience sizes: Facebook requires at least 100 matched users; Google requires 1,000. Audiences below these thresholds are not activated on the ad platform.
Journey Builder integration: An Advertising Audience activity in Journey Builder can add or remove a contact from an ad audience as they progress through a journey (e.g., remove from retargeting after purchase).
Supported platforms: Facebook/Instagram Custom Audiences, Google Customer Match, LinkedIn Matched Audiences, Twitter (X) Tailored Audiences.
Sync process:
1. Connect Advertising Studio to the ad platform's ad account via OAuth.
2. Create an Audience in Advertising Studio linked to a Marketing Cloud data extension or subscriber list.
3. Advertising Studio hashes PII (email, phone) before sending to the ad platform; the platform matches hashed records to its user base — raw data never leaves Salesforce.
Minimum audience sizes: Facebook requires at least 100 matched users; Google requires 1,000. Audiences below these thresholds are not activated on the ad platform.
Journey Builder integration: An Advertising Audience activity in Journey Builder can add or remove a contact from an ad audience as they progress through a journey (e.g., remove from retargeting after purchase).
SFTP setup: Each Marketing Cloud account includes an Enhanced FTP (EFTP) server. Access is configured in Setup under Data Management > FTP Accounts. Username and password authentication is supported; SSH key-based authentication (preferred for security) requires uploading the public key in the FTP account settings.
Directory structure: The EFTP server has standard directories:
File Drop trigger: Automation Studio's File Drop trigger monitors a specific EFTP directory and file name pattern; when a matching file is detected, the automation starts automatically.
Best practices:
— Use SSH key authentication instead of passwords.
— Rotate FTP credentials regularly.
— Use unique file naming conventions with timestamps to avoid collisions.
— Implement file import activities with error notification alerts.
— Delete or archive imported files after processing to keep the EFTP tidy.
Directory structure: The EFTP server has standard directories:
/Import for files to be imported, /Export for data extract outputs, /Triggered Sends for triggered send batches.File Drop trigger: Automation Studio's File Drop trigger monitors a specific EFTP directory and file name pattern; when a matching file is detected, the automation starts automatically.
Best practices:
— Use SSH key authentication instead of passwords.
— Rotate FTP credentials regularly.
— Use unique file naming conventions with timestamps to avoid collisions.
— Implement file import activities with error notification alerts.
— Delete or archive imported files after processing to keep the EFTP tidy.
API access is managed via Installed Packages in Marketing Cloud Setup (Platform > Apps > Installed Packages).
Component types:
— Server-to-Server: OAuth 2.0 client credentials flow. Used for back-end integrations. Provides client_id and client_secret.
— Public App: OAuth 2.0 with PKCE. For front-end or mobile apps that cannot store secrets.
— Web App: OAuth 2.0 authorisation code flow. For web apps with server-side components.
Common OAuth scopes:
—
—
—
—
—
—
IP allowlisting: Restrict API access to specific IP addresses or CIDR ranges in the Installed Package settings for additional security.
Token management: Access tokens expire in 1,080 seconds (18 minutes). Cache and reuse — do not request a new token per API call.
Component types:
— Server-to-Server: OAuth 2.0 client credentials flow. Used for back-end integrations. Provides client_id and client_secret.
— Public App: OAuth 2.0 with PKCE. For front-end or mobile apps that cannot store secrets.
— Web App: OAuth 2.0 authorisation code flow. For web apps with server-side components.
Common OAuth scopes:
—
email:read/write/send — Email Studio access—
data:read/write — Data Extension access—
list:read/write — Subscriber list management—
contacts:read/write — Contact Builder—
journeys:read/write — Journey Builder—
assets:read/write/publish — Content BuilderIP allowlisting: Restrict API access to specific IP addresses or CIDR ranges in the Installed Package settings for additional security.
Token management: Access tokens expire in 1,080 seconds (18 minutes). Cache and reuse — do not request a new token per API call.
Datorama (rebranded as Marketing Cloud Intelligence) is a cross-channel marketing analytics platform that aggregates data from multiple sources into unified dashboards and reports.
Marketing Cloud connection: A native Marketing Cloud data stream connector syncs Email Studio tracking data (sends, opens, clicks, bounces, unsubscribes) automatically. Configuration requires OAuth credentials from an Installed Package with appropriate scopes.
Data streams: Pre-built connectors for Marketing Cloud, Salesforce CRM, Google Ads, Facebook Ads, Google Analytics, and hundreds of other sources. Data is harmonised into a unified data model (Dimensions and Measures).
Widget creation: Dashboards are built using a drag-and-drop widget builder. Widgets can display bar charts, line charts, scorecards, tables, and maps using calculated metrics (e.g., ROAS, CPL, conversion rate).
Cross-channel analytics: The value of Datorama is combining email performance, paid media, and web analytics into a single view to attribute revenue and optimise marketing spend across channels.
Marketing Cloud connection: A native Marketing Cloud data stream connector syncs Email Studio tracking data (sends, opens, clicks, bounces, unsubscribes) automatically. Configuration requires OAuth credentials from an Installed Package with appropriate scopes.
Data streams: Pre-built connectors for Marketing Cloud, Salesforce CRM, Google Ads, Facebook Ads, Google Analytics, and hundreds of other sources. Data is harmonised into a unified data model (Dimensions and Measures).
Widget creation: Dashboards are built using a drag-and-drop widget builder. Widgets can display bar charts, line charts, scorecards, tables, and maps using calculated metrics (e.g., ROAS, CPL, conversion rate).
Cross-channel analytics: The value of Datorama is combining email performance, paid media, and web analytics into a single view to attribute revenue and optimise marketing spend across channels.
Social Studio (now transitioning to Sprinklr as Salesforce sunsets the product) is the social media listening, publishing, and engagement tool in Marketing Cloud. Administrator configuration tasks include:
Social account connection: Connecting Twitter, Facebook, Instagram, LinkedIn, and YouTube accounts via OAuth. Each account can be assigned to one or more workspaces.
Workspace management: Workspaces group social accounts, publishing permissions, and team members. Admins create workspaces per brand or region and assign user roles (Viewer, Member, Admin).
Topic profiles: Keyword-based social listening configurations that monitor mentions, hashtags, and competitor names across social networks in real time. Admins configure keywords, exclusions, and source filters.
Sentiment analysis: Automated sentiment scoring (positive/neutral/negative) on social posts. Admins can train the model with custom sentiment rules for brand-specific terminology.
Macros and automation rules: Automated responses or routing rules triggered when specific keywords or conditions are detected in social posts.
Social account connection: Connecting Twitter, Facebook, Instagram, LinkedIn, and YouTube accounts via OAuth. Each account can be assigned to one or more workspaces.
Workspace management: Workspaces group social accounts, publishing permissions, and team members. Admins create workspaces per brand or region and assign user roles (Viewer, Member, Admin).
Topic profiles: Keyword-based social listening configurations that monitor mentions, hashtags, and competitor names across social networks in real time. Admins configure keywords, exclusions, and source filters.
Sentiment analysis: Automated sentiment scoring (positive/neutral/negative) on social posts. Admins can train the model with custom sentiment rules for brand-specific terminology.
Macros and automation rules: Automated responses or routing rules triggered when specific keywords or conditions are detected in social posts.
In Marketing Cloud E2.0, contacts are managed at the Enterprise level in Contact Builder. All BUs share the same contact pool — a contact is the same individual across all BUs, identified by ContactKey.
Contact count (billable contacts): The total number of unique contacts in the Enterprise's Contact Builder — every contact record that has ever been created, regardless of subscription status or whether they have a sendable attribute. This is the number Salesforce bills on.
Sendable contact count: Contacts who have a valid email address on a sendable data extension AND are not globally unsubscribed. Only sendable contacts can actually receive email sends. The sendable count is always less than or equal to the total contact count.
BU-level contacts: Each child BU has its own AllSubscribers list and can have its own sendable DEs, but the underlying contact records are shared at the Enterprise level. Unsubscribing a contact from one BU does not unsubscribe them from other BUs unless a global unsubscribe is triggered.
Contact count (billable contacts): The total number of unique contacts in the Enterprise's Contact Builder — every contact record that has ever been created, regardless of subscription status or whether they have a sendable attribute. This is the number Salesforce bills on.
Sendable contact count: Contacts who have a valid email address on a sendable data extension AND are not globally unsubscribed. Only sendable contacts can actually receive email sends. The sendable count is always less than or equal to the total contact count.
BU-level contacts: Each child BU has its own AllSubscribers list and can have its own sendable DEs, but the underlying contact records are shared at the Enterprise level. Unsubscribing a contact from one BU does not unsubscribe them from other BUs unless a global unsubscribe is triggered.
Marketing Cloud Connect's Synchronized Data Sources create read-only DEs in Marketing Cloud that mirror CRM object data:
Supported objects for sync: Contact, Lead, User, Account, Campaign, Campaign Member, and configurable custom objects.
Sync frequency: Contact and Lead records sync near-real-time (within minutes of CRM updates) via streaming events. Other objects may sync on a scheduled basis.
Configuration: In Marketing Cloud Setup, select which CRM fields to sync for each object. Fields selected appear as columns in the corresponding synchronized DE (e.g.,
Usage in Journey Builder: The Salesforce Data entry source can use synchronized DEs as the entry audience. Records matching filter criteria on the CRM-synced DE enter the journey automatically.
Limitations: Synchronized DEs are read-only — you cannot write back to CRM via the DE. Use the Sales/Service Cloud Activity or a Flow-based integration to update CRM records. Large orgs with millions of records should carefully plan initial sync time and the ongoing delta sync window.
Supported objects for sync: Contact, Lead, User, Account, Campaign, Campaign Member, and configurable custom objects.
Sync frequency: Contact and Lead records sync near-real-time (within minutes of CRM updates) via streaming events. Other objects may sync on a scheduled basis.
Configuration: In Marketing Cloud Setup, select which CRM fields to sync for each object. Fields selected appear as columns in the corresponding synchronized DE (e.g.,
Contact Salesforce Data).Usage in Journey Builder: The Salesforce Data entry source can use synchronized DEs as the entry audience. Records matching filter criteria on the CRM-synced DE enter the journey automatically.
Limitations: Synchronized DEs are read-only — you cannot write back to CRM via the DE. Use the Sales/Service Cloud Activity or a Flow-based integration to update CRM records. Large orgs with millions of records should carefully plan initial sync time and the ongoing delta sync window.
Commercial send classification: Used for marketing and promotional emails. This type respects the global unsubscribe list — subscribers who have opted out will not receive the email even if they appear in the send audience. Required for CAN-SPAM compliance for commercial messages. Also respects publication list opt-outs.
Transactional send classification: Used for order confirmations, shipping notifications, password resets, and other operationally necessary emails. This type bypasses the global unsubscribe list — a subscriber will receive the email regardless of their opt-out status. Under CAN-SPAM, transactional emails are largely exempt from opt-out requirements because they contain information the recipient needs.
Why it matters: Using the wrong classification causes serious problems:
— Using Commercial for a transactional message: unsubscribed customers miss critical order updates.
— Using Transactional for a promotional email: you send marketing messages to people who have opted out, violating CAN-SPAM and GDPR, and risking high spam complaint rates.
Always audit send classifications during MC admin reviews.
Transactional send classification: Used for order confirmations, shipping notifications, password resets, and other operationally necessary emails. This type bypasses the global unsubscribe list — a subscriber will receive the email regardless of their opt-out status. Under CAN-SPAM, transactional emails are largely exempt from opt-out requirements because they contain information the recipient needs.
Why it matters: Using the wrong classification causes serious problems:
— Using Commercial for a transactional message: unsubscribed customers miss critical order updates.
— Using Transactional for a promotional email: you send marketing messages to people who have opted out, violating CAN-SPAM and GDPR, and risking high spam complaint rates.
Always audit send classifications during MC admin reviews.
Marketing Cloud does not include native IP warming tracking tools or IP reputation scores. Administrators must use a combination of:
Internal tracking: Manually track warm-up volume by day in a spreadsheet or DE, comparing planned vs actual sends. Monitor bounce rates, complaint rates, and delivery rates in MC Email Studio Tracking or Automation Studio activity logs.
Third-party tools:
— Validity (Return Path): Provides inbox placement monitoring, blacklist monitoring, and sender reputation scores (Sender Score 0–100). Requires registering your IPs with Validity.
— GlockApps: Seed list testing tool that shows inbox/spam placement across 50+ email clients and ISPs for each send.
— MXToolbox: Free blacklist checker — verify your IPs are not listed on major blacklists after any deliverability incident.
MC tracking reports: Use the Email Studio Tracking > Overview and Send Summary to monitor send-level delivery rate, bounce breakdown, and complaint rate (via ISP FBL integration for participating ISPs like Comcast, Yahoo).
Internal tracking: Manually track warm-up volume by day in a spreadsheet or DE, comparing planned vs actual sends. Monitor bounce rates, complaint rates, and delivery rates in MC Email Studio Tracking or Automation Studio activity logs.
Third-party tools:
— Validity (Return Path): Provides inbox placement monitoring, blacklist monitoring, and sender reputation scores (Sender Score 0–100). Requires registering your IPs with Validity.
— GlockApps: Seed list testing tool that shows inbox/spam placement across 50+ email clients and ISPs for each send.
— MXToolbox: Free blacklist checker — verify your IPs are not listed on major blacklists after any deliverability incident.
MC tracking reports: Use the Email Studio Tracking > Overview and Send Summary to monitor send-level delivery rate, bounce breakdown, and complaint rate (via ISP FBL integration for participating ISPs like Comcast, Yahoo).
Marketing Cloud supports two SSO approaches:
1. Salesforce CRM SSO (MC Connect): When Marketing Cloud Connect is configured, users with matching Salesforce CRM user accounts can log into Marketing Cloud using their Salesforce credentials. This requires the user's Salesforce username to match their Marketing Cloud username. Users are provisioned and linked in Marketing Cloud Setup under Users > Salesforce Users.
2. SAML-based SSO (External Identity Provider): Marketing Cloud can be configured as a SAML Service Provider. An external IdP (Okta, Azure AD, Ping Identity) authenticates the user and passes a SAML assertion to Marketing Cloud. Configuration requires:
— SAML metadata exchange between the IdP and MC
— Username/attribute mapping in the MC SSO settings
— Just-in-time (JIT) provisioning can automatically create MC user accounts on first login
User activation/deactivation: When employees leave, promptly deactivate their MC user account (cannot delete — only deactivate). Deactivated users cannot log in and are excluded from active user counts.
1. Salesforce CRM SSO (MC Connect): When Marketing Cloud Connect is configured, users with matching Salesforce CRM user accounts can log into Marketing Cloud using their Salesforce credentials. This requires the user's Salesforce username to match their Marketing Cloud username. Users are provisioned and linked in Marketing Cloud Setup under Users > Salesforce Users.
2. SAML-based SSO (External Identity Provider): Marketing Cloud can be configured as a SAML Service Provider. An external IdP (Okta, Azure AD, Ping Identity) authenticates the user and passes a SAML assertion to Marketing Cloud. Configuration requires:
— SAML metadata exchange between the IdP and MC
— Username/attribute mapping in the MC SSO settings
— Just-in-time (JIT) provisioning can automatically create MC user accounts on first login
User activation/deactivation: When employees leave, promptly deactivate their MC user account (cannot delete — only deactivate). Deactivated users cannot log in and are excluded from active user counts.
A structured MC setup checklist for a new BU or client org includes:
1. Account structure: Determine BU hierarchy — single BU, Enterprise with child BUs, or separate Enterprise accounts per brand.
2. Authentication: Provision SAP (private domain, dedicated IP, SPF/DKIM, RMM). Configure DNS records and verify in MC Setup.
3. IP warming: Plan a 4–6 week warming schedule before launching full-volume sends. Identify engaged segments for initial sends.
4. Users and roles: Create user accounts with least-privilege roles. Configure SSO if the client uses Salesforce CRM or an IdP.
5. Data model: Set up Contact Builder attribute groups and sendable DEs. Define subscriber key convention.
6. Compliance: Configure publication lists, preference centre CloudPage, suppression lists, and GDPR consent tracking DEs.
7. Automation: Set up SFTP access, import automations for CRM data, and data retention policies on import DEs.
8. API access: Create Installed Package with minimal required scopes. Restrict to known IP ranges. Document client_id/client_secret in a secrets manager.
1. Account structure: Determine BU hierarchy — single BU, Enterprise with child BUs, or separate Enterprise accounts per brand.
2. Authentication: Provision SAP (private domain, dedicated IP, SPF/DKIM, RMM). Configure DNS records and verify in MC Setup.
3. IP warming: Plan a 4–6 week warming schedule before launching full-volume sends. Identify engaged segments for initial sends.
4. Users and roles: Create user accounts with least-privilege roles. Configure SSO if the client uses Salesforce CRM or an IdP.
5. Data model: Set up Contact Builder attribute groups and sendable DEs. Define subscriber key convention.
6. Compliance: Configure publication lists, preference centre CloudPage, suppression lists, and GDPR consent tracking DEs.
7. Automation: Set up SFTP access, import automations for CRM data, and data retention policies on import DEs.
8. API access: Create Installed Package with minimal required scopes. Restrict to known IP ranges. Document client_id/client_secret in a secrets manager.