Salesforce and DKIM

Last month I wrote about how Salesforce was implementing the ability to sign emails sent from Salesforce CRM with DKIM. The Spring 15 update is now live as is the ability to use an existing DKIM key or allow Salesforce to create a new one for you.
Setting up DKIM within Salesforce is straightforward. A Salesforce Administrator would go to Setup->Email Administration->DKIM Keys.
sf-dkim-step0
You can either allow Salesforce to create you a new DKIM key or you can import an existing key. For this example, I am going to create a new DKIM key for the domain wttwexample.com with a DKIM selector of 2015Q1.
Step 1 – Creating a new key within Salesforce, you enter the Selector for the key (2015Q1), the domain for the key (wttwexample.com), and the strictness of the key allowing either the exact domain only, subdomains of the domain only, or Exact domain and subdomains.
sf-dkim-step1
Step 2 – The next screen will display both the Public Key and the Private Key.
sf-dkim-step2
Step 3 – With the key being created, we need to store the Public Key within our DNS for the domain by created a TXT record with a hostname of 2015Q1._domainkey.
sf-dkim-step3
Using a DKIM check tool like ours http://tools.wordtothewise.com/authentication, we can see if the DKIM key is in the DNS and if the key is valid.
Step 4 – Once we have confirmed the key is valid and in DNS, we can go back to Salesforce and activate the key.
Step 5 – Emails sent from the Salesforce CRM Sales Cloud will now be signed with the new DKIM key and the emails will have a new header added called DKIM-Signature.
Signing with DKIM allows us to tell the recipient ISP that “yes, I sent this email” and this allows the ISP to track our reputation by the domain instead of just by the IP address.  This means that some fraction of our good reputation will be associated with these emails that are sent from Salesforce CRM. If we have not established any reputation yet, signing with DKIM is a good key to enable services like feedback loops as it includes the proof that you’re sending the FBL reports to someone responsible, not a random third party.
If you have plans to consider utilizing DMARC, you need to have ALL of your sources of mail authenticated.  DMARC looks for a passing SPF or DKIM validation during its evaluation of the message. Utilizing both SPF and DKIM for DMARC validation is recommended.
Having emails signed with DKIM, having a valid SPF, setting up sensible reverse DNS, having good hostnames all show that you are doing your part to send legitimate and valid mail. Signing with DKIM does not give you a free pass to send spammy emails, it just tells the receiving party who is taking responsibility for sending the message.

Related Posts

May 2014: The month in email

It’s been a busy and exciting month for us here.
Laura finished a multi-year project with M3AAWG, the Messaging, Malware and Mobile Anti-Abuse Working Group (look for the results to be published later this year) and continued working with clients on interesting delivery challenges and program opportunities. Steve focused on development on the next version release of Abacus, our flagship abuse desk tool, which will also be available later this year.
And as always, we had things to say about email.
The World of Spam and Email Best Practices
We started the month with a bit of a meta-discussion on senders’ fears of being labeled spammers, and reiterated what we always say: sending mail that some people don’t want doesn’t make you evil, but it is an opportunity to revisit your email programs and see if there are opportunities to better align your goals with the needs of people on your email lists. We outlined how we’ve seen people come around to this position after hitting spamtraps. That said, sometimes it is just evil. And it’s still much the same evil it’s been for over a decade.
We also wrote a post about reputation, which is something we get asked about quite frequently. We have more resources on the topic over at the WiseWords section of our site.
Gmail, Gmail, Gmail
Our friends over at Litmus estimate Gmail market share at 12%, which seems pretty consistent with the percentage of blog posts we devote to the topic, yes? We had a discussion of Campaign Monitor’s great Gmail interview, and offered some thoughts on why we continue to encourage clients to focus on engagement and relevance in developing their email programs. We also wrote a post about how Gmail uses filters, which is important for senders to understand as they create campaigns.
SMTP and TLS
Steve wrote extensively this month about the technical aspects of delivery and message security. This “cheat sheet” on SMTP rejections is extremely useful for troubleshooting – bookmark it for the next time you’re scratching your head trying to figure out what went wrong.
He also wrote a detailed explanation of how TLS encryption works with SMTP to protect email in transit, and followed that with additional information on message security throughout the life of the message. This is a great set of posts to explore if you’re thinking about security and want to understand potential vulnerabilities.
DKIM
Steve also wrote a series of posts about working with DKIM (DomainKeys Identified Mail), the specification for signing messages to identify and claim responsibility for messages. He started with a detailed explanation of DKIM Replay Attacks, which happens when valid email is forwarded or otherwise compromised by spammers, phishers or attackers. Though the DKIM signature persists (by design) through a forward, the DKIM specification restricts an attacker’s ability to modify the message itself. Steve’s post describes how senders can optimize their systems to further restrict these attacks. Another way that attackers attempt to get around DKIM restrictions is by injecting additional headers into the message, which can hijack a legitimately signed message. If you’re concerned about these sort of attacks (and we believe you should be), it’s worth learning more about DKIM Key Rotation to help manage this. (Also of note: we have some free DKIM management tools available in the WiseTools section of our site.)
As always, we’re eager to hear from you if there are topics you’d like us to cover in June.

Read More

Email Authentication in a nutshell

There are 3 types of authentication currently in use for email.

Read More

Superstition, correlation and reality

I’m not a huge baseball fan, probably a side effect of growing up in a city with no MLB team. SF_giants_ImageBut I do enjoy the social aspects of rooting for local teams when they’re winning big games. Last night I was following the World Series score online and switched over to watch the last inning. I posted something about the game on FB just about 30 seconds before the Giant’s outfield bobbled what should have been a single (at best). I immediately posted an apology, “Sorry about that, shouldn’t have said anything!”
Do I really think that my post somehow cursed two outfielders and caused them to bobble a simple play? No, of course not. But it is a very human response. In fact, there’s an entire advertising campaign centered around the the weird things people do while watching sports.
There is a lot of superstition in email delivery, too. I think that’s a combination of filtering necessarily being a black box, human’s built in tendency to see patterns in random data, and a need to be able to control and affect outcomes.
Figuring out cause and effect in the real world is not trivial. In my research days we set out to control as many confounding factors as possible so we could demonstrate the cause and the effect. That’s really hard to do when you’re not at a lab bench. In the real world, we can’t always control things directly. Instead, we have to rely on statistics and representative (or non-representative) samples.
Delivery isn’t even close to a science and one of the major issues is that filters are always changing. I’ve certainly seen occasions where multiple clients, or colleagues, were having problems delivering to one ISP or another. One of my clients made a change and saw their delivery improve. They patted themselves on the back for figuring out the problem. At the same time, though, other folks saw their delivery improve without making any changes. I can’t always convince people that whatever they did had nothing to do with their delivery improving.
The flip side is I can’t always convince people to stop doing somethings that they don’t need to do. I see a lot of mail with both DomainKeys and DKIM signatures. In most cases both signatures have the same selectors. DomainKeys is deprecated. No one, and I mean no one with a modern email system, is checking DomainKeys without checking DKIM. Senders can safely stop signing with DomainKeys and have nothing happen. It doesn’t matter, lots of ESPs and sender sign with both. They’re not going to change it. I’ve had multiple groups tell me they’re afraid to stop signing because it might hurt their delivery.
The reality is I didn’t make the Giant’s outfield bobble the ball because I posted to FB that I was watching the bottom of the 9th inning. The reality is that DomainKeys is deprecated and there’s no benefit to signing with both DomainKeys and DKIM. The reality is we are humans and we are inherently superstitious. Most of the times our superstitions are harmless. But sometimes they cause us more work than we need to do and provide no tangible benefits.

Read More