I'm having a hard time finding a concrete answer to this. Every Marketing Cloud implementation that I've worked on had an email address as something like email.marketing.companyname.com as the "authenticated" send-from email address in SAP (Sender Authentication Package) as well as in the "Sender Profile". I've read that it's not considered best practice to use the root company website domain (@companyname.com). Is there any reason to this?

3 Answers 3


This isn't actually Marketing Cloud related nor isn't it always even a best practice method, but the reason why it's usually done this way comes down to the Email authentication method known as DKIM (DomainKeys Identified Email) and Email validation protocol known as SPF (Sender Policy Framework) which are the most common methods which govern the deliverability of Emails.

To give you a quick overview, DKIM lets a domain associate its name with an email message by adding a signature to it. Verification by recipient Email provider or service is done by using signer's public key published in the DNS.

Essentially meaning if the key is wrong or missing, the Email might be spoofed, edited or come from untrustworthy source. Email providers will generally block these emails or mark them as spam.

The domain that you need to provide for the SAP will always need to be an unused one, which is the reason you cannot use the company domain for it in 99.99% of cases.

That being said, many Marketing Cloud clients actually do use their company Email when sending out Emails from Marketing Cloud, but this is done via Private Domain add-on.

Once purchased, you can use that Private Domain for a specific functionality in Marketing Cloud, including as a Sender Profile address. However noting that this feature does not ever include the option for Link and Image wrappings.

Salesforce will be generating a zone file which the company domain holder will use to add DKIM key and SPF manually to the DNS. The authentication after adding the keys and notifying Salesforce Deliverability Team will generally take less than 24h and this way the company domain will show up under authenticated domains in your Marketing Cloud.


Typically it has to do with deliverability and abiding by best practice regarding SPF records. A SPF record is a DNS entry that authorizes a specific IP address to sending mail from that domain. The SPF record for @companyname.com is most trusted when it has two or fewer authorized email senders. If it starts to get too many, some spam filters may see this as suspicious.

The IT Ops folks at @companyname.com probably want to allow only one or two SPF entries for their email at the top level domain, and that's typically restricted to the company mail servers, like Exchange.

However, they can create a subdomain and enter a SPF record for a different email system. This aids the subscriber in knowing that there's a relationship between the top level domain and the new subdomain, and it also provides an insulated domain so that any activities that might blacklist one server have less of a chance of affecting the other. Deliverability takes into account IP address as well as domain, but every inbox provider weighs them differently.

  • Thanks @Matt. You've been super helpful with some my questions. I got thrown into supporting deliverability concerns when I have next to no experience with deliverability (only really Marketing Cloud implementations). Salesforce has a team dedicated to handling deliverability and since I'm with a different company now (not Salesforce anymore), we do not have a Deliverability Consultant. Thanks again!
    – Mike Marks
    Commented Oct 17, 2018 at 19:07

Yes, there is a good reason - security and deliverability.

1) If you use the corporate domain, you are authenticating SFMC to send as an authenticated sender for your corporate domain, which is less distinguishable as Marketing Communication. InfoSec departments feel less comfortable allowing a Cloud platform to email as a corporate domain for reasons that such Comms and monitoring fall outside their control i.e. someone could maliciously spoof and email send from SFMC as though the CEO and communicate anything. InfoSec typically keep corporate Comms internally managed, controlled and monitored

2) If you were ever to blacklist your deliverability, then you are likely to also impact your corporate sending

3) DNS, I believe it's not possible to have corporate email and cloud email services pointed in the same DNS file

Best practice is to either use a subdomain, or specific marketing domain.

Subdomain doesn't have to be email.company.com - though most of the time this is what Salesforce recommend. I've suggested alternatives :

Comms.company.com Mktg.company.com e.company.com

If you register a domain, then you can technically have anything (if the domain is available). However the familiarity and customer experience is less with a domain than a subdomain as any person can register and own domain e.g. mktg-company.com

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .