Setting up a different marketing platform while working in Salesforce Marketing Cloud

Question

Currently I work in Salesforce Marketing Cloud

If I am working on a secondary marketing platform, can I use the same sub-domains in secondary platform (non-SFMC) that are currently being used in my Salesforce Marketing Cloud business units?

Like:

1. SFMC Parent BU: sub1.mydomain.com (IP - 1.1.1.1)
2. SFMC Child BU 1: sub2.mydomain.com (IP - 1.1.2.2)
3. SFMC Child BU 2: sub1.mydomain.com (IP - 1.1.1.1)

My understanding is that when my Salesforce Marketing Cloud account was configured, the sub-domains and I.Ps were setup where name servers were probably changes and pointed to Salesforce (I think NS entries).

1) So, if I want to use the exact same sub-domains in a secondary platform, can new name servers (NS records) be added while keeping everything functioning as-is with SFMC?

2) Another thing to clarify is - my understanding is that each sub-domain can have multiple I.P address that are configured for I.P warming (depending on the volume).

So, if same sub-domains can be configured in the secondary platform, it means same sub-domain will be setup with a different I.Ps? meaning new I.P addresses needs to be added to the sub-domain in order to configure them in the secondary platform?

3) Can anyone guide, what basis steps are needed for I.P warming in any marketing platform (assuming overall approach is pretty much the same)?

Like:

• Configure domain or sub domain
• Authentication like SFP / DKIM
• Setup sender profile (reply mgm)
• I.P warming by sending emails

Are these steps in correct order for setting up any marketing platform? to clarify, I am only asking high-level approach steps, not asking specific platform.

Answer 1

If you've delegated a subdomain to Salesforce using NS records, you'd not be able to do anything with the subdomain... ExactTarget.com's nameservers are the authority and manage the entire zone file for the subdomain, including not only SPF and DKIM TXT records, but also the various other records required to support Marketing Cloud features, like open and click reporting, image hosting, landing pages, Reply Mail Management... It's not realistically possible to create a different set of NS records to delegate to somewhere else for the same subdomain. You can add the records, but that would just lead to unpredictable resolution of DNS - a mess. You could potentially ask to revert to self-hosting the zone file in your own DNS, but I suspect you would be required to purchase a new Sender Authentication Package - you're essentially asking Salesforce to redo all the work previously carried out for SAP setup.

You can purchase supplementary IP addresses and have SFMC apply round-robin type routing of sends through your IP addresses or opt to manually select IP addresses for each send using Delivery Profiles. IP addresses involve the purchase of a SKU that is good for the term of your contract. It's renewable at the end of your term and can't be purchased for the IP warming period, only.

Theoretically, you could potentially send from your other Marketing platform using the same subdomain. You would need to investigate the configuration capabilities of that platform. If you hosted the zone file, you could certainly add SPF authentication for that platform. DKIM would be more doubtful as you'd need to be able to control signing of messages using the same private and public keys as used by SFMC. It's beyond the scope of this community to speculate on your other platform. What can't be shared between the two platforms is the likes of Reply Mail Management. MXs will be pointing to SFMC mail exchangers. Your other platform would likely need to be able to manage replies, also. If your other platform also expects to listen for replies on bounce.sub1.mydomain.com or reply.sub1.mydomain.com, these would clash with SFMC's MXs.

If you're looking to warm up SFMC IP address(es), my advice would be to not try and hack your DNS. Use a different subdomain for SFMC to the one used in your other platform. Reputation's primarily driven by IP address, not domain.