IT won't let me set up SPF / DKIM on top level domain...

[Anonymous]

Has anyone else run into this situation where IT won't allow SPF / DKIM on the top level domain? I was under the assumption that setting up DKIM / SPF in Marketo for the TLD was pretty standard.. Is this not the case? Has anyone else run into this situation / how did you resolve it?

We send out automated emails from individuals who we'd like to have appear sent from their personal email addresses without setting up aliases that clearly indicate that they are automated... This is not going to be possible, and definitely won't scale if we need to set up aliases for everything.

Any advice welcome!

[SanfordWhiteman]

First: you don't mean TLD. You mean second-level domain, or more generally "shortest private suffix." TLDs are like "com" and "info."

Anyway, my question would be why, specifically, they're making this restriction. If it's arbitrary, we can argue against it. If it's well-reasoned, it's not a winnable battle.

It's accurate for them to say using a subdomain ensures they won't be DKIM-signing spam at the main corp domain, for example, but inaccurate to claim signed messages can't be distinguished by DKIM selector (even at the same domain) and inaccurate to think the main domain couldn't be placed on URI blacklists for sins of the subdomain.

[Dan_Stevens_]

We just went through something similar with our Data Security team.  We had to create a new DKIM record using a sub-domain, reserved solely for this (marketing.avanade.com).  You can read the full discussion here: Re: Using a sub-domain for SPF/DKIM/DMARC authentication - to tighten security (where Sanford helped us significantly in our final solution).

As you mentioned, this will now require all FROM email addresses to contain this sub-domain (in our case, "@marketing.avanade.com").  Since the REPLY-TO can still contain the working email address, it wasn't that big of an impact.  When personalized emails are sent out that use the salesperson's email address (a custom field in Marketo), we've created a velocity script token to transform the email address properly:

And when we use this personalization in our emails, we simply include the token in the "FROM" field: {{my.Transformed BD Email Address}}

[SanfordWhiteman]

Hey Dan, that VTL is great for most cases but I would do this touchup:

#set( $defaultEmail ="info​@marketing.avanade.com" )
#set( $email = $lead.Avanade_BD_Owner_EmailAddress )
#set( $search = "@avanade.com" )
#set( $replace = "@marketing.avanade.com" )
#set( $final = $email.replace($search, $replace) )
#if( !$final.endsWith($replace) )
#set( $final = $defaultEmail )
#end
${final}

If you don't check endsWith() then a malformed owner email (like with just a mailbox, no domain, or crazy-but-legit address like "jim​@avanade.com"​@gmail.com) won't be transformed into the default email.

[Dan_Stevens_]

Thanks Sandy!

[Anonymous]

Thank you Sanford Whiteman​ and Dan Stevens​ ! Extremely helpful, and that velocity script is going to save me an amazing amount of time. Really appreciate the guidance on this.