Salesforce SPF and now DKIM support

Salesforce has published a SPF record for sending emails from Salesforce for years and with the Spring ’15 release, they will provide the option to sign with DKIM.
The SPF record is straight forward, include:_spf.salesforce.com which includes _spf.google.com, _spfblock.salesforce.com, several IP address blocks, mx, and ends with a SoftFail ~all.
Salesforce Knowledge Article Number: 000006347 goes in-depth with information regarding their SPF Record.

With the Spring ’15 Release, Salesforce offers the ability sign outbound emails with DomainKeys (DKIM).

DKIM signing of outbound email is available for Enterprise, Unlimited, and Developer Editions.  Salesforce recommends that you add the public key to your DNS before activating DKIM signing.  There is a limit of 1 DKIM key per domain and Salesforce gives you the option to domain match and sign emails for the domain only, subdomain only, or domain and subdomains.  More information about Salesforce DKIM signing can be found within their Spring 15’ Release Notes.
The ability to sign with non-Salesforce DKIM keys means that Salesforce users now have the option to use DMARC. Prior to this change all mail was authenticated as coming from Salesforce, which is perfectly acceptable and how authentication works. The ability to sign with the users’ DKIM key and domain means large Salesforce users are now able to track authentication failures or publish DMARC policy requests.

Related Posts

DMARC: an authentication framework

A new email industry group was announced this morning. DMARC is a group of industry participants, including large senders, large receivers and relevant intermediaries working on a framework to reduce the harm from phishing.
DMARC is working on a standard to allow senders to publish sending policies and receivers to act on those policies. Currently, senders who want receivers to not deliver unauthenticated email have to negotiate private agreements with the ISPs to make that happen. This is a way to expand the existing programs. Without a published standard, the overhead in managing individual agreements would quickly become prohibitive.
It is an anti-phishing technique built on top of current authentication processes. This is the “next step” in the process and one that most people involved in the authentication process were anticipating and planning for. I’m glad to see so many big players participating.
 

Read More

Setting up DNS for sending email

Email – and email filtering – makes a lot of use of DNS, and it’s fairly easy to miss something. Here are a few checklists to help:

Read More

Troubleshooting tools

There have been a number of comments on my post about Hotmail moving to SPF authentication having to do with troubleshooting authentication failures. I have been helping clients troubleshoot these issues, and am able to take on new clients to solve authentication problems. Contact me for more information.
Of course, many of these issues can be solved with access to the right tools. Steve’s been working on a number of tools that may help the troubleshooting process and we’ve recently launched them on Emailstuff.org. The website itself contains a number of DNS and data related tools we use for investigations and thought we’d share with the public at large.
One of the really useful tools is the SPF record expander. Plug in any domain, like google.com, and see what IP addresses they authorize to send mail.

Read More