You might already know, that you can use either a Sender Authentication Package or Private Domain to brand your emails, so the sender email address reflects your brand. In almost all cases, this sender domain is a subdomain to your business domain. Assuming your website is based on example.com, the sender domain can be mail.example.com or e.example.com:
I want to send my emails from my “real” domain, which is example.com – how can I make sure they arrive from sales@example.com?
Marketing Cloud Administrator
There can be cases, where you want emails to arrive not from a subdomain, but from your top domain. The one domain you are also already using for your website, and corporate email addresses. Is this even possible? Yes, but there are few points you have to take into consideration. Let’s walk through all of them.
You will first of all not be able to use the same domain for your Sender Authentication Package. Meaning that having example.com as your corporate domain, you will still need to start with purchasing and implementing a Sender Authentication Package using a subdomain, e.g. e.example.com. This will create a Cloud Page domain of https://cloud.e.example.com, along with a.o. click tracking domain of https://click.e.example.com – this is unavoidable. You won’t be able to create Cloud Pages on https://www.example.com
When you configure your Sender Authentication Package (SAP), you can choose to either have this domain managed by Salesforce (meaning you will delegate the subdomain or manage the DNS settings yourself). The easiest option is to delegate it, and leave all the configuration and any ongoing updates to DNS settings to Salesforce.
Domain configuration
Once your SAP is configured, you can purchase and ask Salesforce to configure a Private Domain for your top domain (example.com). Here you don’t have other options than self-host the DNS records, as delegating it to Salesforce will break existing functionality for anywhere this domain is used (your website, corporate email, etc). To quote Salesforce material on this, what you need to do is Purchase, Ignore, Implement:
- Purchase Private Domain SKU from Salesforce. Assumes you already have Sender Authentication Package SKU. (If not, you need Sender Authentication Package SKU as well, as I also write above)
- Ignore the default DNS settings sent to you by SFMC Support. It includes extraneous detail not needed for this use case.
- Implement only the DKIM key DNS for the top level domain.
Once you have received DNS details, the only record you need is a CNAME record, holding the DKIM information:
Your will need your domain name, and the “stack” where the Marketing Cloud account is hosted. (In order to identify your stack, use this guide or reach out to Salesforce support)
- Assuming stack 50 with domain “example.com”, it will be:
- Create a DNS entry for 50dkim1._domainkey.example.com that is a CNAME that points to 50dkim1._domainkey.s50.exacttarget.com
- This DNS entry varies per stack. Ask Salesforce for help if unclear.
- Implement NO OTHER DNS entries. Do not add the SPF or DMARC or MX record to your domain. IF YOU DO THIS, YOU WILL BREAK YOUR CORPORATE EMAIL HANDLING.
No cheating! Implementing this DNS entry will not, by itself, allow you to start sending emails from whatever@example.com – you will still need to have Salesforce configure example.com as a Private Domain.
Based on great feedback from Al Iverson, my deliverability guru, I have removed the bit explaining how to update existing SPF record. Al explains why:
You don’t actually need to update the SPF record. SFMC sends with a return-path domain of bounce.e.example.com – this is the level at which the SPF record needs to reflect SFMC/ET ITs. At the example.com level above, the SPF record does not need SFMC/ET IPs. SPF bloat at this top level is in theory harmless but ends up contributing to so many folks having too many DNS lookups in their SPF record, violating spec. Great for people like me that work for companies with automated authentication solutions we’d love to sell you, but truly not necessary.
Reply mail management
You must observe, that creating a Private Domain on a different top domain from your SAP domain, might result in DMARC issues – but this can be solved with the multi-bounce domain feature.
You might want to disable RMM, so email replies will be sent directly to the email address set as sender, instead of being routed to SFMC. However this will potentially lead to many Out-of-office replies, unsubscribe requests etc. not being filtered. You need to check with the owner of this email address (e.g. sales@example.com) if they are OK with that. Otherwise it is also OK to leave RMM in place.
If you choose to leave RMM in place for your SFMC setup, you might experience issues with the email address of subscribers replying to your emails being altered. Imagine John Doe (john.doe@foobar.com) replying to an email sent from sales@example.com (sent by your SFMC). When John’s email arrives in the inbox of Sales, after being routed via RMM, the sending address is altered to something along the lines of: john.doe.foobar.com@example.com (while their reply-to address remains the same). This is something that can be resolved by asking Salesforce to enable DMARC Forward Reply Rewrite. Reason for this behaviour is due to the email from John Doe is sent by SFMC (RMM) to sales@example.com – and since SFMC is not allowed to send emails from foobar.com domain, as this will violate SPF/DKIM policy set in the DNS of foobar.com.
Combining with Dynamic Sender Profile
A really interesting use case for the above configuration, is combining it with Dynamic Sender Profile. This will allow you, especially in a multi-cloud scenario when working with both Sales and Marketing Cloud, send emails on behalf of your sales reps. Imagine a Contact (John Doe), belonging to an Account (Acme Inc.), who has Foo Bar as account manager. When sending email to John, you can use the Dynamic Sender Profile to make it look like if it was Foo Bar herself, who sent the email (as the from address will be foo.bar@example.com). Once John replies to this email, the reply will arrive directly to Foo’s inbox, despite being sent from SFMC. You can use Ampscript in your dynamic sender profile, to lookup the contact information of the account owner. This is best done using Lookup function on Synchronised Data Extensions.