There are several use cases for sending emails from Salesforce, including automated emails associated with business processes, scheduled notifications and end users sending email with the Lightning Email Composer (typically accessed via the “Email” tab in the Activity panel on Contact and Lead pages).

Several DNS records can be added to the domain of the sending email address to improve the likelihood that the emails will be delivered to the recipient’s inbox and not filtered to spam or junk mail folders.

This post outlines how to set up and test DKIM, SPF and DMARC records with your domain, as well as the related configuration necessary in the sending Salesforce org.

DomainKeys Identified Mail (DKIM)

DomainKeys Identified Mail, or DKIM, uses cryptographic authentication for validating the identity of the domain name that is associated with an email message. The basic approach is to create a public/private key pair, add the public key as a DNS record and include the private keys with the outbound emails. Sending and receiving email servers will handle the rest.

Enable in Salesforce

As of the Winter ’19 release, the DKIM feature in Salesforce has changed and you may need to activate the critical update titled “Enable Redesigned DomainKeys Identified Mail (DKIM) Key Feature with Increased Email Security“. As of the time of writing the post, Salesforce was planning to automatically activate the critical update for all orgs on 10/15/19. This change results in Salesforce publishing the record with the public key to DNS on your behalf so that they can rotate keys and improve security of the keys.

Navigate to Setup -> Email -> DKIM Keys and click the “Create New Key” button. Use the following values

  • RSA Key Size: 1024-bit
  • Selector: 2019.sfdc
  • Alternate Selector: 2019.sfdc2
  • Domain: (your domain; e.g. aaronwinters.org)
  • Domain Match: Exact domain only

On the confirmation page, Salesforce will confirm that the TXT records with the DKIM key have been published to DNS and will show the values for the CNAME and Alternate CNAME records that you need to publish on your domain.

Create the DNS Entries

Log into the domain registrar or hosting provider where your domain’s nameserver is managed. Create two new records.

First record:

  • Name/Host: 2019.sfdc._domainkey
  • Type: CNAME
  • TTL: (default)
  • Value: (Value from CNAME Record beginning after “IN CNAME”)

Second record:

  • Name/Host: 2019.sfdc2._domainkey
  • Type: CNAME
  • TTL: (default)
  • Value: (Value from Alternative CNAME Record beginning after “IN CNAME”)

Test the DKIM Keys

Use a DKIM Lookup tool to check that the set up was performed correctly. Enter your domain (e.g. aaronwinters.org) in the Domain Name field and enter the DKIM selector (2019.sfdc in this example) in the Selector field.

On the results page you should see that the tool was able to find the DNS and DKIM records without syntax errors, along with the public key.

Sender Policy Framework (SPF)

The Sender Policy Framework (SPF) allows email senders to specify which email servers are permitted to send email on behalf of your domain. Permitted mail servers can be specified by domain or IP address in a DNS record with special syntax.

If you already have an SPF record for your domain – this is common if you are already sending email with Google Apps or Office 365 – then add the following text to the existing record after other “include” statements and before the closing “all”:

include:_spf.salesforce.com

If you don’t already have an SPF record, create a new one using the following information:

  • Name/Host: @
  • Type: TXT
  • TTL: (default)
  • Value: “v=spf1 mx include:_spf.salesforce.com ~all”

Note that ending the entry with “~all” will flag email sent from other domains with a soft fail status and will likely still allow delivery. Changing the ending to “-all” results in mail being sent from any other domain being flagged with a hard fail status and will likely be blocked.

Test the DNS entry

Finally use an SPF validation tool to test the SPF record with an IP address that Salesforce uses to send email. For example, use the following values in the “Test and SPF record” section of the validation tool:

  • IP address: 13.108.238.141
  • SPF Record v=spf1…://–>: v=spf1 mx include:_spf.salesforce.com ~all (or use the value of your SPF record if you created a custom value)
  • Mail From address: (use a valid email address on your domain)
  • HELO/EHLO Address: (use a valid email address on your domain)

Click the “Test SPF Record” button. You should be directed to a page with text output confirming that the SPF record is valid.

Domain-based Message Authentication, Reporting and Conformance (DMARC)

Domain-based Message Authentication, Reporting and Conformance, or DMARC, helps define a structured process for email senders and receivers to collaborate around improving mail authentication practices of senders and to enable receiving servers to reject unauthenticated messages.

Email senders publish a DMARC policy that tells email receivers what to do when an email does not pass authentication, and tells email receivers where to send reports about how well email authentication is working for emails coming from that sender. Senders publish their DMARC policy in the Domain Name Server (DNS) using a TXT record. DMARC builds on DKIM and SPF, so those records need to be in place before adding a DMARC record.

When an email message is received, it will include information about the message’s alignment with the sender’s DMARC policy. Receiving email servers can then handle the message according to the DMARC policy and send reports about how well the sender’s authentication methods are working to an email address specified in the DMARC policy.

Create a new DNS record with the following information:

Note: you should update the email addresses above with a valid email address on your domain.

These are some of the most important attributes and options:

  • p: Indicates the policy to be enacted by the Receiver at the request of the Domain Owner. “none” is a good option to start with until you have more feedback reports. Other options are “quarantine” and “reject”.
  • rua & ruf: URIs of an email address owned by the sender where receiving email servers should send reports about how the sender’s email authentication methods are working. Multiple addresses can be included and they should be comma-separated.
  • sp: Policy for subdomains of the sender’s domain. This attribute is optional and when absent, the policy in the p attribute will be applied to email sent from subdomains. The options are the same for the p attribute.
  • adkim: Indicates whether strict (“s”) or relaxed (“r”) DKIM Identifier Alignment mode is required by the sender.
  • aspf: Indicates whether strict (“s”) or relaxed (“r”) SPF Identifier Alignment mode is required by the sender.

A full list of attributes and options can be found in the DMARC specification.

The typical approach is to start with a more relaxed DMARC policy and make the policy more strict as you receive more reports and see how the authentication methods are working.

Test and Monitor the DNS Entry

Test the DNS entry using a DMARC policy lookup tool. The tool should return the value of the DMARC record and validate that the syntax is correct.

Pretty soon, you will begin receiving emails to the mailto address published in the DMRAC record) from ISPs that are involved in the delivery of emails sent on behalf of your domain. The emails will include reports with information about the originating IP addresses and the results of the SPF and DKIM checks. These reports are a great resource for identifying all of the applications that are sending emails on behalf of your domain and monitoring the effectiveness of the SPF and DKIM entries for each.

Important Notes!

  • When you set the DKIM or SPF alignment to “strict” mode, it will affect all applications that are sending email on behalf of this domain. It is a good practice to catalog the applications that are sending email on behalf of the domain and make sure that you have enabled DKIM and updated the SPF for those applications before setting the corresponding DMARC policy to “strict” mode.
  • If you are sending email from Salesforce via an email relay with the bounce management feature enabled, the SPF will result in a soft fail for emails sent from Salesforce due to a mismatch in authorized sending IP address and the actual sending IP address, so you may not be able to set the DMARC policy for SPF alignment to “strict” in this scenario.

Additional Resources

Tags

One Comment

  1. Jenny Sevcik
    September 1, 2021 at 1:37 pm  ·  Reply

    Hi — I’m wondering if you’ve come across salesforce list emails not being sent to emails within your own domain?

    We are able to send regular one-off emails through salesforce. This is set up to send via office 365 and works just as intended. An email relay has been set up and it will not work for all email addresses in our list emails, specifically we want to copy our team on list emails. Everyone has been set up as a contacts (as salesforce does not allow adding “users” as campaign contacts) but the emails will not go through. Salesforce support says this is not their issue. Office 365 support has no idea what the issue is.

    I have email logs from salesforce that says “the command has been aborted due to a serve error (on their end) … cryptographic failure. Message Trace in Office 365 does not have record of the list emails that failed.

    I’ve used your above instructions. I keep checking the message source trying to figure out what the issue is. I was successfully able to add the DKIM for salesforce and that is now showing “signature was verified” but we are still not able to send list emails to our work email addresses.

    Any idea what the next step should be?

Leave a Comment

Your email address will not be published. Required fields are marked *