There can be some confusion on how and when to use Private Domain on Marketing Cloud vs a Sender Authentication Package. It took me some time to understand this myself, and I will share some key findings here below.
Private Domains allow you to send your mail from an authenticated domain (including SPF, Sender ID, Domain Keys and DKIM) or to brand your Cloud Pages.
Private Domains ensure your mail is authenticated or that your Cloud Pages are branded according to your company as opposed to Salesforce Marketing Cloud.
Private Domain does not wrap links and images within your account. If your want complete “branding” of your account, you will need to purchase a Sender Authentication Package.
Private Domain is not configured at the account level. Once a Private Domain has been configured, that domain can be used in any account by creating a user or sender profile using the domain in question.
Yes, an account can have as many authenticated sending domains as you would like (e.g. multiple brands who want to use separate From addresses operating within 1 account). An account can also have an unlimited number of Cloud Page domains configured to it. Keep in mind that multiple private domains for sending may not be DMARC compatible.
Private Domains are different from the account “branding” you get via SAP set-up. Private Domains WILL NOT include link and image wrapping within your account.
Absolutely. Private Domain does not include a Dedicated IP, it is only used as an authentication tool.
Private Domain changes require the purchase of a new Private Domain SKU.
1. You should ensure, that there is at least one remaining Private Domain in your license, which is not currently in use
2. Decide on what (sub)domain you want to use as your Private Domain. You can go with a subdomain (hi.example.com) which is a recommended approach. You can also use a TLD as your Private (example.com) domain. But this comes with limitations.
3. If you want Salesforce to manage the DNS for you, which is the easiest option, you will need to delegate the NS records to their name servers (as described here)
4. You can also choose to self-host. In this case, Salesforce will provide you with the relevant zone file, once the setup is done in their end
5. Once you have delegated the subdomain, you should log a support ticket, asking them to setup the subdomain as Private Domain. Please note which Business Units you need it on, and also whether this Private Domain should be used as a sender domain, or also a a Cloud Page domain.
6. When Salesforce has confirmed the setup, you cab verify this by viewing the domain list in From Address Management, to see if this is available there.
7. If you have chosen to use it in Cloud Pages too, you should additionally ask for SSL to be configured on that domain.
8. Once Cloud Page domain is ready, you can check it’s availability in the dropdown, when creating new Cloud Page.
I have verified my email address in From address management under Setup. Can’t I just use it to send from?
Marketing Cloud admin
There is indeed a method of verifying your email address in From Address Management under Setup, as seen in this screenshot:
The only verification happening here, is ensuring you have ownership of the specific email address, to prevent you from sending emails from Marc Benioff’s email address. This verification does not provide any authentication (SPF/DKIM) and will hence not guarantee your email does not trigger the spam filter on the receiving end. This is why I never really use this feature, but rely only on domains which are authenticated as either SAP or Private Domain. You can see these in the same list, just listed as a different type, for Private Domain:
Or for a domain being part of a Sender Authentication Package:
When should I use a Private Domain instead of a Sender Authentication Package (SAP)?
SAP is a bundle of products (Private Domain, Dedicated IP, RMM and URL wrapping)
- URL wrapping (commonly referred to as “account branding” is only available through a full SAP configuration)
- There is a limit of 1 SAP per Business Unit which means it only can be “branded” with 1 domain (if you need to have unique branding for multiple lines of business then you’ll need multiple BUs with an SAP per BU)
- The SAP cannot be broken into parts (i.e. Salesforce is unable to simply pull the Private Domain out of a purchased SAP). This means, that if you decide to start your SAP configuration on a shared IP, you will need to purchase a Dedicated IP later.
Private Domain is a single domain configuration (as opposed to a bundle of products). A single Private Domain can be used for 1 of 2 options:
- Private Domain for sending – authenticated for sending mail (Salesforce will sign the domain with SPF and DKIM for use in a From address) (unlimited # of Private Domains for sending per Business Unit)
- When using this Private Domain for sending, the URLs to images and click tracking will still be using SAP domain.
- Private Domain for Cloud Pages – the domain chosen can be used to uniquely brand Cloud Page URLs in a client account (unlimited # of Private Domains for Cloud Pages per Business Unit)
As with SAP, you will get the option of either self-hosting, or delegating the Private Domain to the name servers of Salesforce. If you are not sure whether you have successfully delegated your domain to Salesforce, there is an unofficial tool, which you can use to help you validate this. You can access the tool here, and I have provided an example domain, so you can see how the tool provides feedback in case the delegation is successful.
What is not included when you purchase a Private Domain, is the SSL certificate needed to secure it. Even though it is not mandatory, should you wish to use your Private Domain to brand your Cloud Pages, I will strongly advise you to purchase an SSL to secure the traffic between the browser and the pages. This is especially crucial, should you decide on hosting forms to capture personal information of your visitors.
A Private Domain used alone for branding your sending, does not require SSL certificates.
What is worth noting, when deciding on a new Private Domain on a Business Unit with an existing SAP, is the DMARC authentication. Let’s assume your are sending from email.example.com today:
- SAP domain populates the bounce domain: bounce.email.example.com
- Your new private domain populates the from domain: brand2.com
- DMARC fails because example.com does not equal brand2.com
What would work:
- SAP domain populates the bounce domain: bounce.email.example.com
- Private domain populates the from domain: brand2.example.com
- DMARC passes because in both cases they use the domain example.com
So in the past this was only safe if all domains involved were part of the same domain name – or if you did not implement DMARC on those domains. There is a new feature called multi-bounce domain. When that is enabled, the system will always change the bounce domain setting to be bounce.[from domain] – like this:
- From domain: brand2.com
- Bounce domain auto-set to: bounce.brand2.com
Hence you can use a PD different from your SAP domain. Multi bounce is enabled upon request, by submitting a support case requesting help setting up multi-bounce domain support for your new private domain.
Hi Lukas! What about RMM and a corporate domain used as a PD? There’s really nothing we can do here apart from handling responses ourselves, correct? Since we can’t include the MX record in there. Thank you!