SFMC tip: Salesforce Marketing Cloud and multi-bounce domain

Here's a tip that I think Salesforce Marketing Cloud users will find useful, especially in the context of the new Yahoo and Google sender requirements.

Multi-bounce domain: Enable this feature to fully ensure "domain alignment" when managing (sending from) more than one domain in a given SFMC business unit or account.

It's quite common for enterprise Salesforce Marketing Cloud clients to send from multiple domains inside of one or more business units (business units being the sub-accounts or child accounts in an enterprise account structure). Usually, the primary domain is configured via Sender Authentication Package, and if you allow Salesforce to host the DNS for that, everything you need for full authentication and compliance (SPF, DKIM and DMARC) will be in place when sending emails from Marketing Cloud using that "Sender Authentication Package" domain in the from address.

For the additional domains, which are usually configured as "private domains," it gets a little bit trickier. If configured properly, by default, they're going to pass DKIM authentication automatically. They may or may not pass DMARC checks – it depends on how the domain was configured, is it a subdomain of an existing domain that may already have a DMARC policy, or was one configured automatically by Salesforce during set up. Depending on when and what you requested, any of these could be the case. DMARC is a tricky pain in the rear in this scenario.

SPF is a bit easier to deal with, though. That's where "multi-bounce domain" comes into play. This is a Marketing Cloud feature that helps ensure SPF alignment, which gives you better coverage for authentication and DMARC compliance. SPF alignment, in this case, means that your bounce domain matches or is in the same domain as ("aligns with") your from domain. Without multi-bounce domain enabled, your bounce domain (aka SPF domain or return-path domain) is always going to be the bounce domain setting associated with your Sender Authentication Package domain. It will be static. With multi-bounce domain enabled, the bounce domain will be dynamic, it will always be configured to be the word bounce, followed by a dot, followed by your private domain name. If your private domain is aliverson.com, then it'll make the bounce domain bounce.aliverson.com. Both are part of the domain aliverson.com, thus this gives you SPF alignment.

To enable multi-bounce domain, an SFMC user must request that support turn it on. The switch to enable this feature is not visible to SFMC users.

There is mild risk with this configuration. Last time I checked, the SFMC platform won't actually check to make sure that bounce.(domain) exists in DNS. It will just assume it does. Which means that if you send as a private domain that lacks a bounce sub-domain, you're going to run into a deliverability issue, as many ISPs reject mail from domains and sub-domains that don't exist in DNS. (If/when this happens, note that it doesn't create a "lingering" deliverability issue; fix the DNS and the issue will go away, with no long term reputation issues.) Thus, if you're DNS savvy, use your favorite DNS tool to check DNS to make sure that there's an SPF record, MX record and A record for the bounce subdomain for every private domain you're utilizing, in any account or enterprise structure where you're planning to enable multi-bounce domain. This isn't exactly entry-level stuff, but it's not THAT hard, either, if you already know how to look up MX records on Wombatmail.

Fellow ex-SFMC'er Lukas Lunow has written about multi-bounce domain here and here. I recommend reading to learn more.

DMARC gets a bit trickier, as I don't think there is any default assignment of a DMARC record for private domains when configured in DNS by Salesforce (like there is for Sender Authentication Package domains). You'll want to check that out for yourself, and make sure that every domain you're sending from has a DMARC policy in place. Keep in mind that DMARC policies are most often implemented at the top level for a domain, and that they "trickle down" to subdomains. So if you have a private domain of email.aliverson.com, and you're trying to see if it has DMARC in place you'll need to check for a DMARC record both for email.aliverson.com AND aliverson.com. If you find one only for the latter, that's okay – by default, policy specified there applies to email.aliverson.com.

And a bonus tip: Do you miss the Reputation Audit? The Reputation Audit tool was something I built approximately (mumble) years ago, where you (usually an SFMC user) would send an email to a certain address, and a report gets generated, showing you, among other things, your IP reputation and authentication status. It was a handy tool for troubleshooting authentication-related configuration issues. Alas, I'm long gone from Salesforce, but that won't stop me from naming a spiritual successor to the Reputation Audit: Steve Atkins' Aboutmy.email. This tools has everything that I would have wanted to put into a modern 2024 version of Reputation Audit, with a particular focus on the new Yahoo/Google sender requirements. Steve really knocked it out of the park with this one, and he has kindly made this tool free for all to use. If you're looking for an online tool to help check to ensure your SFMC authentication settings are correct, or trying to confirm that you're all set as far as Yahoo and Google sender compliance, then this is the tool for you. (I've written more about that tool here.)

(Just to clarify, I had no hand in creating Aboutmy.email. I wish I had! But I don't want anybody to think that I'm trying to take credit for his fantastic work.)