* Marketing Cloud Growth & Advanced *

*** Important Security Update: Enforcement of IP Allowlisting in Marketing Cloud Engagement on September 23, 2026 ***As part of our commitment to strengthening the default security of the Marketing Cloud Engagement platform, Salesforce is requiring the use of the login IP allowlist in blocking mode for all accounts. We have identified that your instance doesn't use the login IP allowlist in blocking mode. On September 23, 2026, we will enable it on your behalf.

Next Steps & Timeline

To help minimize potential disruption, we reviewed your recent login activity and compiled a list of recommended baseline IP addresses to include on your login IP allowlist. On September 23, 2026, we will enable blocking mode for your instance. After this date, users can log in to your Marketing Cloud Engagement account from an IP address on the allowlist.

Configuration Impact and Customer Responsibility

No action is required before September 23, 2026. To ensure your configuration is applied correctly, we recommend waiting until after September 23, 2026, before making any changes to your login IP allowlist settings. If you have any concerns, contact Salesforce Support.

After September 23, 2026, you are responsible for reviewing and maintaining your login IP allowlist. Monitor your login IP allowlist access logs on an ongoing basis to identify new IP ranges to add.  See View the Access Log, Add IP Addresses to the Allowlist, and Edit an IP Range.

When we enable blocking mode in your account, you can expect these changes:

• We will apply a Salesforce-recommended baseline IP list consisting of standard /24 (256 address) IP ranges. These ranges are based on IPs observed to successfully authenticate to your instance over the last six months, excluding known malicious IPs.
• "Log Violations and Deny Access" (blocking) mode will be enabled at the EID level for both UI Login and API access, with the IP ranges uniformly applied to all Business Units (BUs).

Resources

• Mandatory IP Allowlisting in Marketing Cloud Engagement
• View the Access Log
• Enable the Login IP Allowlist
• Add IP Addresses to the Allowlist
• Edit an IP Range

#Marketing Cloud Engagement #Marketing Cloud

Hi Hello 

In addition to our current contract for Marketing Cloud Engagement, we have decided to add Marketing Cloud Engagement+ to our contract.

The main purpose of this additional contract is to utilize AI to build segments using natural language, such as specifying conditions with generative AI.

In order to establish this operation, we would like to organize the future data design and processing flow. From an architectural perspective, could you please advise us on the following three points regarding what preparations and tasks will be required based on our current configuration?

Questions

1. Data management location 
   Currently, the customer data used for message delivery is managed on the Marketing Cloud (MC) side. In order to use AI-powered natural language segmentation, is it necessary to migrate or consolidate this data into Data Cloud (DC)? Or is it acceptable to continue managing the data in MC as it is now?

2. Environment for creating AI segments 
   Specifically, in which environment or screen will AI-powered natural language segment creation be performed: MC or DC?

3. Environment for executing message delivery 
   When using the extracted and segmented data, will the actual message delivery, such as email or LINE, be executed from MC? Or will it be triggered directly from DC?

Thank you for your support.

Follow up on the recent thread about Contact Point Emails and Marketing Cloud Next consent (the one where François pointed to the multiple email addresses article, that article matches my use case closely: How should Contact Point Emails be | Salesforce Trailblazer Community). 

My situation is on Contacts rather than Leads. Stakeholders can have several email addresses, and the number is not fixed. Some have one, some have three or four, and (although it'd be rare) it can grow over time. So adding a fixed set of custom email fields on the Contact object (Second Email, Third Email etc) does not really work for us, as we cannot predict the ceiling.   

What we already have is core ContactPointEmail records against each Contact, which handles any number of addresses cleanly. The problem is these do not seem to be recognised by the consent layer. Looking at the Contact Point Email DMO in Data Explorer, the rows sourced from the standard Contact mapping have Party equal to the Contact Id, but the rows sourced from ContactPointEmail have Party equal to the core Individual Id, since that is what ContactPointEmail.ParentId points to. So they do not line up with the Individual DMO rows, which are keyed on Contact Id. 

My question: is it a supported approach to use a Data Transform to read the ContactPointEmail data and write it into a DLO mapped to the Contact Point Email DMO, with Party set to the Contact Id and a synthetic primary key (similar to the CONCAT approach in the article, but sourcing from real ContactPointEmail records instead of custom fields on the Contact)? 

That would give us an unlimited number of addresses per person while still following the Party = Contact Id convention the consent layer expects. 

Or is there a reason core ContactPointEmail records are deliberately not wired into the consent model, and the custom-field-plus-DLO pattern is the only intended route? 

Also, does Marketing Cloud Growth generate consent rows for custom Email-type fields on Contact, or only standard fields? 

One alternative I considered and would rather avoid is creating multiple Contact records for the same person with different email addresses. Apart from the obvious data quality problems, I do not think it would even work, our identity resolution matches on normalised email only, so two Contacts with different addresses would resolve as two separate Unified Individuals rather than one person with two addresses. Happy to be corrected if I have that wrong. 

Any guidance on the intended pattern here would be appreciated.

📬 Marketing Cloud Next takes care of your sending IPs automatically. But that doesn't mean you're off the hook for deliverability: https://mateuszdabrowski.pl/docs/salesforce/marketing-cloud/config/ip-warming-deliverability/

On @* Marketing Cloud Engagement * you have full control over deliverability, for good and for bad. On @* Marketing Cloud Growth & Advanced * the experience is more streamlined, but also controlled by Salesforce. You start on a shared pool of IPs, and you work your way out of it. 

Once you cross ~5M emails/type/month, Salesforce rewards your achievement with a dedicated IP, and warms it on its own. Not much to do for you. No schedule, no throttling, no configuration. Marketing Ops dream? Almost. 

There are still some important tasks on you: 

🔵 You still need basic configuration to enable your first sends. And it's a bit stricter than it was on MCE. 

🟠 IP reputation != Domain reputation.  A new sending domain (might) still need its own warming plan. 

🔴 Monitoring is a must. It already was. Then it got must-er with tighter ESP bounce & complaint rate requirements. And now it is must-est with lower control over IPs and the impact of being demoted to the Gray Pool.  

Full mechanics, the prerequisites checklist, and the monitoring options with setup guides are available now on my page.

🧱 It's time for MC Next Business Units Architecture! 

TL;DR: Default to a single BU until a hard requirement forces the split: 

https://mateuszdabrowski.pl/docs/salesforce/marketing-cloud/config/business-units/

The decision tree in the article has an "Are you sure?" step for a reason... New Business Units work differently to what you know from the good old @* Marketing Cloud Engagement *

On @* Marketing Cloud Growth & Advanced * a Business Unit is a thin marketing layer over exactly one Data 360 Data Space. The Data Space is the real wall - no hierarchy, no per-BU login, everything you can access in one view, with a badge telling you where you are. 

Three things to know before you click create: 

🔵 It's forever. A Business Unit can't be deleted, deactivation is permanent, and the Data Space it consumed can never serve another one. You get 2 included with Advanced Edition, and can pay your way up to 150 total since Summer '26. 

🟠 Splitting splits everything (duh!). Segments, flows, content and reporting all partition with the Data Space - cross-BU reuse means deployed copies (Data Kits, Common Assets), multiplied processing, and no consent sync! 

🔴 Governance has one blind spot for the recommended Single BU approach. Data 360 row-level visibility control holds almost everywhere - except segment and Calculated Insight runs. Region filters on segments stay manual. 

In the article, you will find a trade-off matrix (Data, Segments, Consent, Domains, Licensing, and more), architecture patterns, and the Global BU duplication tax.