SFMC tip: Sending as the top level domain in Marketing Cloud
URL Copied
Not only did I stumble across this when reviewing Chris Zullo's capture and notes on my "Deliverability 201” domain and IP strategy deck for SFMC users, but it came up when consulting for a client recently. I thought it would be fun to capture and share this scenario, to help the next person who comes along.
The scenario is this. The client, like most Salesforce Marketing Cloud clients, has a custom subdomain configured. That custom subdomain is implemented by way of Sender Authentication Package, the feature that maps a whole bunch of DNS entries (more than a dozen) to the domain touchpoints for different features in Marketing Cloud. That leaves the client set up with a particular subdomain intended for use for sending via Marketing Cloud. Let's say, for the sake of discussion, that the subdomain is email.wombatmail.com. That means that SFMC is configured with the intent that Marketing Cloud users will send email campaigns and automations from Marketing Cloud using (something)@email.wombatmail.com as the from address.
But let's say you wanted to send mail as bob@wombatmail.com, instead of bob@email.wombatmail.com. That comes up a lot, actually. Why do people want to do that?
It lets them bypass the reply handler (called RMM/Reply Mail Management).
It guarantees that if a recipient caches a sender's from address in their address book, that the address is at the top level of the domain. This matters because in most cases, corporate email is already configured to accept mail sent to bob@wombatmail.com. Salesforce does not provide similar functionality for the subdomain, meaning mail to bob@email.wombatmail.com gets discarded. Salesforce Marketing Cloud does not route mail for your SFMC-pointing subdomain, except via the special system-generated "Reply Mail Management" addresses.
What is this about RMM? Yes, SFMC appends a reply-to email header with a uniquely encoded reply-to email address. If a subscriber emails THIS address, mail goes to the RMM processor and is handled using the configured RMM settings. But only for those special addresses – not just for whatever address you put in the to: email header. If a user hits reply, all good. If a user manually tries to send mail to bob@email.wombatmail.com (and this will happen), not so good.
The recommended fix here is for SFMC customers is to configure Marketing Cloud to be able to send mail as the top-level of your domain properly. Here's how you do that:
You've already got Sender Authentication Package set up with a subdomain of email.wombatmail.com
Add on the "Private Domain” feature for wombatmail.com (the top level of your own domain).
Tell Salesforce that you'll host the DNS for this yourself and that it will be a custom configuration; meaning you're going to implement only the DKIM record.
Salesforce support will provide you with a handful of DNS entries. This will include records for MX, SPF, DMARC and DKIM. Ignore them all, except for the DKIM record. The DKIM record will be either a TXT record or CNAME record that has a hostname of (something)._domainkey.(yourdomain).com.
Implement ONLY the DKIM TXT record.
Do NOT configure (implement) the other DNS records in the DNS settings for your domain. I CAN'T STRESS THIS BIT ENOUGH. PAY HEED HERE, TREAD CAREFULLY, AND DO NOT ADD THE OTHER RECORDS.
Do not replace or remove any other DNS records for your domain name.
Do not add the SPF or DMARC or MX record to your domain. IF YOU DO THIS, YOU WILL BREAK YOUR CORPORATE EMAIL HANDLING. THIS IS BAD.
Adding the DKIM record is safe. No problem at all. Just be careful to add ONLY this record to DNS.
And yes, you can have multiple DKIM records for your top level domain. This is quite common, as many companies send mail via multiple email systems, CRMs, ticketing systems, etc., and it is best practice (and in a lot of cases, required) that this mail all be authenticated with DKIM authentication. The different DKIM records will have different selectors; they do not inherently conflict.
This is different than SPF or DMARC. You can only have one SPF or DMARC record for a domain. Multiple ones are out of compliance with internet specifications and will cause unexpected results.
Salesforce (and I) consider this to be an expert level configuration option. Why Salesforce warns against this is because a well-meaning but non-savvy IT manager could accidentally disable corporate email if they accidentally delete any existing DNS records or incorrectly add new DNS records. Move slowly and carefully here.
After this private domain is fully implemented and tested, Marketing Cloud users can now send from the two different domains in this account: email.wombatmail.com and wombatmail.com. Sending from either domain will fully authenticate with SPF and DKIM, and will pass DMARC checks. (Test it, of course.)
What risk are there with this implementation? Besides the setup risk (be careful with DNS) noted above, domain reputation applies here. Meaning how Gmail, Microsoft and other providers treat your mail – do they reject it, do they accept it and deliver it to the spam folder, or do they deliver it to the inbox – is going to be based on their measures of whether or not this domain sends good mail or bad mail. The usual deliverability warnings and best practices apply here. Avoid purchased lists, avoid cold leads, stick to permission and best practices, and consult your friendly neighborhood deliverability consultant for assistance.
That warning aside, there are a LOT of companies out there with this configuration in place (I see hundreds of them when I scan the top ten million domains), and I helped many folks set this up over the years, without incident. Be careful when setting everything up, test email sending every possible way to ensure full Yahoo/Google compliance, and don't let your marketing people send spam, and it won't cause you any trouble.
Not only did I stumble across this when reviewing Chris Zullo's capture and notes on my "Deliverability 201” domain and IP strategy deck for SFMC users, but it came up when consulting for a client recently. I thought it would be fun to capture and share this scenario, to help the next person who comes along.
The scenario is this. The client, like most Salesforce Marketing Cloud clients, has a custom subdomain configured. That custom subdomain is implemented by way of Sender Authentication Package, the feature that maps a whole bunch of DNS entries (more than a dozen) to the domain touchpoints for different features in Marketing Cloud. That leaves the client set up with a particular subdomain intended for use for sending via Marketing Cloud. Let's say, for the sake of discussion, that the subdomain is email.wombatmail.com. That means that SFMC is configured with the intent that Marketing Cloud users will send email campaigns and automations from Marketing Cloud using (something)@email.wombatmail.com as the from address.
But let's say you wanted to send mail as bob@wombatmail.com, instead of bob@email.wombatmail.com. That comes up a lot, actually. Why do people want to do that?
What is this about RMM? Yes, SFMC appends a reply-to email header with a uniquely encoded reply-to email address. If a subscriber emails THIS address, mail goes to the RMM processor and is handled using the configured RMM settings. But only for those special addresses – not just for whatever address you put in the to: email header. If a user hits reply, all good. If a user manually tries to send mail to bob@email.wombatmail.com (and this will happen), not so good.
The recommended fix here is for SFMC customers is to configure Marketing Cloud to be able to send mail as the top-level of your domain properly. Here's how you do that:
And yes, you can have multiple DKIM records for your top level domain. This is quite common, as many companies send mail via multiple email systems, CRMs, ticketing systems, etc., and it is best practice (and in a lot of cases, required) that this mail all be authenticated with DKIM authentication. The different DKIM records will have different selectors; they do not inherently conflict.
This is different than SPF or DMARC. You can only have one SPF or DMARC record for a domain. Multiple ones are out of compliance with internet specifications and will cause unexpected results.
Salesforce (and I) consider this to be an expert level configuration option. Why Salesforce warns against this is because a well-meaning but non-savvy IT manager could accidentally disable corporate email if they accidentally delete any existing DNS records or incorrectly add new DNS records. Move slowly and carefully here.
After this private domain is fully implemented and tested, Marketing Cloud users can now send from the two different domains in this account: email.wombatmail.com and wombatmail.com. Sending from either domain will fully authenticate with SPF and DKIM, and will pass DMARC checks. (Test it, of course.)
What risk are there with this implementation? Besides the setup risk (be careful with DNS) noted above, domain reputation applies here. Meaning how Gmail, Microsoft and other providers treat your mail – do they reject it, do they accept it and deliver it to the spam folder, or do they deliver it to the inbox – is going to be based on their measures of whether or not this domain sends good mail or bad mail. The usual deliverability warnings and best practices apply here. Avoid purchased lists, avoid cold leads, stick to permission and best practices, and consult your friendly neighborhood deliverability consultant for assistance.
That warning aside, there are a LOT of companies out there with this configuration in place (I see hundreds of them when I scan the top ten million domains), and I helped many folks set this up over the years, without incident. Be careful when setting everything up, test email sending every possible way to ensure full Yahoo/Google compliance, and don't let your marketing people send spam, and it won't cause you any trouble.
Comments
Post a Comment
Comments policy: Al is always right. Kidding, mostly. Be polite, please and thank you.