Using a sub-domain for SPF/DKIM/DMARC authentication - to tighten security

[Dan_Stevens_]

We were recently notified by our security team that they are not allowing any email sent by third-party providers (like Marketo) to authenticate as our primary domain (avanade.com) - to mitigate against any spoofing, phishing attempts, Marketo getting hacked, etc.  Instead, we need create a subdomain - like "marketing.avanade.com" when configuring SPF/DKIM/DMARC.  This is also in alignment with our parent company, Accenture (and Microsoft).  I just wanted to get some thoughts from the experts in the community around this topic (e.g., Sanford Whiteman​) before I give the go-ahead to proceed with this.  I guess what's most concerning is when we use tokens - like "sales owner email" to populate the FROM and REPLY-TO fields of an email.  We will constantly need to ask IT to map any new email addresses to one that has this new sub-domain.

Interested to hear what others have to say about this - especially those that use this approach today.  Anything we need to be aware of, gotchas, etc.?

[SanfordWhiteman · Accepted solution]

Dan, as you've identified, the major pain point is procedural.

There are no technical hurdles to sending from a subdomain, as long as you don't try to use an existing subdomain (that is, don't send from your branding or landing domains, choose a new one). SPF and DKIM work perfectly well in this scenario, as does DMARC alignment. (I've argued recently that granting Marketo-generated emails an SPF Pass, if you are deeply concerned about spoofing across a multitenant platform, isn't a good move.  Better to go with SPF Unknown and concentrate on DKIM.)

But the main thing is that aliases that are unfamiliar on the receiving side, like dan.stevens@marketing.avanade.com, have to become familiar in Marketo. If you tokenize everything, that at least takes the decision out of the hands of the Marketo user, but like you said you have to make sure the alias exists (unless the entire domain is aliased). And in turn, recipients will have the opportunity to add these unfamiliar addresses to their address books and send them mail (even if you set Reply-To: user@avanade.com, you will get some incoming to user@marketing.avanade.com). So the subdomain ends up in wider circulation than just in Marketo. Comes with the territory....

[Dan_Stevens_]

This is helpful, Sandy - thanks.  Regarding the second point (on new aliases when we send on behalf of a user vs. a generic emailbox) - today, we do this using tokens on the lead record.  We have specific fields for this - like "Sales Person Email" (which is needed when a record only exists in Marketo and not CRM).  So let's say we include my email - in the FROM/REPLY-TO field - with the revised domain (dan.stevens@marketing.avanade.com) and this hasn't been mapped yet by our IT team to resolve against my actual email.  Will this impact the deliverability of the email since it's not really a valid email address?  Or is the key - from a deliverability/authentication standpoint - the sub-domain that's used?

[SanfordWhiteman]

Will this impact the deliverability of the email since it's not really a valid email address?

The emphasis of my answer depends on whether you're using brander sender (i.e. so your subdomain is used in the envelope MAIL FROM as well as in the From: header).

If you're using branded sender: Yes. You must not use MAIL FROM addresses that cannot receive mail.

If you're not using branded sender: still Yes but less fatal.  Header addresses aren't likely to be checked for deliverability. However, the backscatter eventually caused by non-deliverable OoO messages and manual replies will hurt you. Don't start off on this bad foot!

[Dan_Stevens_]

Setting up branded sender is another enhancement we're making as well (Marketo gave this to us as part of our renewal).  So if i'm understanding you properly, we should standardize on common email addresses that are legit (e.g., info@marketing.avanade.com) and refrain from using actual ones that will now contain just the primary domain (and not the new subdomain)?

I guess this also means we should disable the "send Marketo email" from MSI (and the Outlook plug-in) - since those use actual email addresses.

[SanfordWhiteman]

So if i'm understanding you properly, we should standardize on common email addresses that are legit (e.g., info@marketing.avanade.com)

Yep.

[Dan_Stevens_]

The other scenario that will be prohibited is to dynamically pull in the Sales/Account Exec's email address from CRM (via tokens in the FROM/REPLY-TO fields).  Would velocity script help here?  Basically taking an @avanade.com and transforming it to @marketing.avanade.com. 

[SanfordWhiteman]

Sure.

[Dan_Stevens_]

As a velocity guru, care to share what the code might look like?  Basically take {{lead.Lead Owner Email Address}} (which all contain @avanade.com" as the email domain) and transform the domain to @marketing.avanade.com. 

[Casey_Grimes]

Just a quick side note here since Sandy's covered most of the points: it's pretty straightforward to set subdomain forwarding in Exchange as a rule that handles all inboxes, especially if you don't need any SMTP use. I wouldn't let that be a hang up in this particular case.