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

Email Authentication in a nutshell

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

Read More

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

A brief DMARC primer

DMARC stands for Domain-based Message Authentication, Reporting and Conformance. What DMARC does is allow domain owners to publish policy statements in DNS telling receiver domains what to do with messages that do not authenticate. In addition, DMARC introduces the concept of “domain alignment.” What this means is that the authentication has to be from the same domain (or a sub-domain) as the address in the header-from: line. The idea behind DMARC is that organizational owners can use SPF and DKIM authentication to authenticate their actual domain in the header-from line. This moves authentication from a important but behind the scenes technology out to an end user visible technology.

Read More