Salesforce Email Deliverability Tips (All you need to know about SPF, DKIM and DMARC)

Share this article...

Do you send automated emails alerts, whether triggered by Workflow, Process Builder, Flow or Apex? Anyone using “send list email”? Are your service desk agents sending individual emails from Salesforce, to customers?

Do you know if these emails are being received and trusted? If you want to improve your likelihood of successful email delivery then read on!


Email is so 2005, and yet traffic volumes are still growing 4% per year. It’s still an important vector for communications but with flaws due to its design heritage.

You send the emails out, but how do you ensure they are received and don’t end up in a spam bucket? Security enhancements are being made to improve reputation and delivery. Just like with Salesforce’s enforced MFA rollout, you need to be making changes or you could find yourself out in the cold. Are your systems keeping up?

Help avoid warnings, like the one above, by following the advice in this guide!!

We’re going to go through how to set these up:

  • Compliance BCC – an easy win, to help you understand what’s being sent out from Salesforce)
  • SPF – prove that Salesforce has the authorisation to be sending email on your behalf
  • DKIM – has anyone altered your emails between them being sent by yourself, and being received by the recipient’s email server?
  • DMARC – tells other systems to reject the email if it’s not from a trusted source

Compliance BCC, SPF and DKIM can all be set up separately from one another, so you can do one at a time, and test them, using the tools provided at the end of this guide.

BONUS! Most of the principles mentioned here also apply to any third party mass email products you might be using (e.g. Campaign Monitor, Mailchimp) so learn the techniques once, and you can help improve the effectiveness of other tools too.

Compliance BCC Email for help with troubleshooting

Rating: Easy

The title may sound officious, but Compliance BCC is really handy for troubleshooting.

By adding an email address you (or, hopefully, your nominated email address) get BCC’d copies of all the emails that Salesforce sends out including Workflow and Process Builder email alerts, chatter messages and individual emails (not password reset mails or import completion notifications though).

What’s the benefit? Well, if someone says “X hasn’t received this” it’s easy to check the whole message straight away.

If (when!) a user gives you incomplete information you can use your email provider’s search function to help identify the email. Searches in a normal email inbox are far easier than looking in the Email Log Files. You get the whole body of the message and you aren’t restricted to 30 days – so you can look on in horror as you see that an email has been sent out incorrectly for months. It can also give rapid visibility over an incorrectly configured process that has sent out too many emails. Just as hypothetical examples of course!

Like backups, no use in setting it up after an “incident” – this one needs to be set in advance to be of use.

All that is required is a separate email address, which you may have to ask your IT department to provide. You really don’t want this stuff cluttering up your inbox. I normally call mine [email protected] and hide from the organisation/internal address lists if at all possible.

Then go to Setup | Email | Compliance BCC Email and pop in the same email address. Job done!

Authenticate your email: SPF

Rating: Medium

Sender Policy Framework (SPF) shows that another server (e.g. has permission to send on behalf of a whole domain (e.g. and is much stronger than a verified email address (which only proves that you had access to a single email address for a moment in time). By setting up your SPF record and adding Salesforce, it means emails that you send from Salesforce are less likely to be marked as spam as it verifies that you truly have the permission to be sending from this domain.

For this you’ll need access to your domain’s DNS record. If you don’t have access you may need to liaise with your IT department to ask them to set this up on your behalf (or point them to this section of this blog, as there’s no Salesforce configuration required).

Health warning: when editing DNS, if you make a mistake you can severely affect your entire domain services (e.g. email, file sharing, website), so take a backup of ALL the existing DNS settings beforehand and proceed with caution! That’s not to say don’t do this. We have to adjust critical systems every day in our roles, but definitely don’t do this last thing on a Friday and perhaps get (any) colleague to double-check and ensure no typos.

  • Log in to the control panel for your domain DNS host
  • Look for the line with
  • If it is there, you already have other domains sending on your behalf. It may look something like this:
v=spf1 ~all

(this example would be applicable for Salesforce, but you may need to use another “include” statement for your mass mail tool such as Campaign Monitor or Mailchimp)

You would then need to modify it so it has:

And it then becomes:

v=spf1 ~all

Or, if there is no existing SPF record, then add the following:

Record name: (your domain - e.g.
Record type: TXT
Content/Value: v=spf1 ~all

n.b. The ~all at the end results in a soft SPF fail (it’s a squiggle ~ not a – as they have different impacts!). If the email is not from the listed sender it is not authorized, but not explicitly unauthorized; this is the most common setting, useful if you’re not 100% which other platforms/parties are sending out emails on behalf of your domain!)

The TTL (time to live) – the last column in the screenshot below – can be set to 600 instead of the 14440 default (it’s time in seconds, in case you were wondering) and when all is still working after a day or two, then you can put it back to 14400. This helps regulate how often your DNS settings are checked.

At the end your DNS panel should look something like this:

Or it could look something like this (depending on whether your DNS service needs you to include the domain name or not – it will be obvious from the other DNS records that already exist):

Tamper-proof: DKIM

Rating: medium

After SPF, along came another progression. DomainKeys Identified Mail (DKIM) shows that no one altered your email on route from the sender’s email server, to the recipient’s email server.

DKIM is also part of the DNS settings of a domain. If you don’t have access to your DNS settings, you’ll also need to do this part in conjunction with your IT department.

Case study: If you don’t have DKIM set up, an email sent by Salesforce internally within your company can be bounced if your email server goes “I definitely didn’t send that” (as seen on Microsoft 365).

To set this up: Navigate to Setup | Email | DKIM Keys

There are 5 items:

  • Key Size: It’s a security thing. In this instance bigger is better! Select 2048-bit (the 1024-bit is for old DNS systems and unlikely to be necessary; you’ll encounter an error if it becomes a problem)
  • Selector: Type “sf1” (you can type other things, just my recommended tip is to avoid using a full stop!)
  • Alternate Selector: Type “sf2” (as above)
  • Domain: The domain name from which you are sending out emails (e.g.
  • Domain Match: If you send email from the “main” domain (e.g. [email protected], without any subdomain (e.g. then “Exact Domain” only is fine; otherwise choose one of the other options as appropriate.
  • Press “Save”

It will look something like this:

This is the bit which could involve your IT department.

Where it says CNAME record, take the first part, before the domain name (highlighted above, in pink). This then becomes “Record Name” in the DNS settings; the part after “CNAME” in the screenshot above becomes the target/content/value in the DNS settings (3rd column in the screenshot below, from the domain hosting company’s DNS setup screen).

It will look something like this. The TTL (time to live) can be left as the default value.

Or it could look something like this (depending on whether your DNS service needs you to include the domain name or not – it will be obvious from the other DNS records that already exist):

The same is true of the trailing dot at the end of “” which the sharp-eyed amongst you would have spotted on Salesforce’s DKIM screenshot above – most DNS control panels I see don’t need this, but presumably some do.

  • Save the settings
  • Wait 48 hours (this is important) for those settings to percolate through the internet
  • Pop back into Salesforce’s DKIM Keys screen and click on the relevant “selector” (see pink highlight on screenshot below)
  • Press “Activate”
  • All done!
  • Ok… one thing extra. Sending from multiple domains? You will need to set up one per domain.

TIP! If 48 hours after the DNS settings are changed, the “Activate” button is not showing, it means that the DNS has not been correctly set up. Very occasionally it can take Salesforce longer than 48 hours (in which case you need to log a Case with Salesforce).

Further resources: Salesforce & DKIM


Rating: complex

SPF shows that the sender is valid, DKIM shows that the email hasn’t been interfered with, but what about the rest of the emails that appear to be coming from your domain? Is it a forgery (just like anyone can print a letterhead) or should the email still be considered valid? Domain-based Message Authentication, Reporting and Conformance (DMARC) completes the set and tells the recipient email server what to do.

Health warning: DMARC is more complicated than SPF and DKIM. The aim of this section is to give you insight into what’s involved.

Although it’s very important, and very much part of email delivery it should be viewed as a separate project to allocate time and resources to get it right. It will require monitoring for at least the first couple of weeks once it is set up (ideally with a backup plan in case the main person monitoring is on annual leave). It also sits well outside of “only” Salesforce, as it touches all email services.

You may want to ask your IT department whether this has been set up, but beyond that, proceed with extreme caution as getting this wrong can adversely impact email sending across your entire organisation.

DMARC only works when you have set up both your SPF and DKIM records, ideally for all email sending sources on your domain.

Again, this involves configuring your DNS. To construct the DMARC string there are a few basic parts.

  1. v=DMARC1
  • This is the DMARC version number; we’re currently on version 1, so this is easy!
  1. You have three different policy options:
  • p=none

This is where the server receiving the email lets the email through, even if the email doesn’t align with the SPF and/or DKIM information; initially this is recommended in case you haven’t identified all the email-sending sources 

  • p=quarantine

This is where the server receiving the email is recommended to quarantine the email, if the email doesn’t align with the SPF and/or DKIM information 

  • p=reject

This is where the server receiving the email is recommended to reject the email, if the email doesn’t align with the SPF and/or DKIM information

3. How to treat DKIM

  • aspf=s
  • aspf=r

SPF policy can be “strict” or “relaxed”; if strict then any emails sent without SPF being correct will be rejected.

4. How to treat DKIM

  • adkim=r
  • adkim=s

As with SPF, DKIM policy can be “strict” or “relaxed”; if strict then any emails sent without DKIM being correct set up will be rejected

5. Pass Through Rate

  • pct=100

This is the percentage of emails that have to meet this policy; when going live with DMARC, or changing between settings, you can ramp it up slowly from 1% upwards to avoid falsely rejecting emails. As a form of testing, it’s very useful. pct=100 means that 100% of emails need to meet the policy and is the default.

6. How to treat SPF and DKIM for reporting purposes

  • fo=0

For email provider to send a report if both SPF and DKIM fail (“relaxed”, the default setting)

  • fo=1

For email provider to send a report if either SPF or DKIM fail (“strict”, our recommendation)

7. Aggregate Reporting

By providing an email address you’ll get emailed an aggregate report about all email traffic (usually daily, although you can add the following which will control the frequency with the time listed in seconds: ri=86400)

8. Forensic Reporting

By providing an email address you’ll get emailed a real-time forensic report about each email failure; useful when first setting up DMARC to see what’s being rejected when perhaps it shouldn’t!

9. Report Format

  • rf=afrf
  • rf=iodef

This is the report format used for failure reporting; typically this is run through an automated tool (e.g. GLock Apps, but there are many others too) so you can identify and act on any issues.

The good news is that there are many DMARC generators to help you out here. Worthwhile using as you don’t want your emails adversely affected after all the effort you’ve put in! The page also includes testing tools. I particularly liked Email Industries which have an example implementation strategy for DMARC towards the bottom of their article.

The other part is TTL (time to live), as earlier, you may initially want this set to 600 seconds and then raise it back to 14400 seconds when you are happy that all is well.

Your end record may look something like:

Record Name: _DMARC
Type: TXT
TTL: 600 or 14400

v=DMARC1; p=none; rua=mailto:[email protected];

ruf=mailto:[email protected]; fo=1; adkim=s; aspf=s; 
pct=100; rf=afrf; ri=86400; sp=none

The reporting options can help to get information about delivery trouble. Normally, you receive a (zipped) report daily from several mail providers in the mailbox mentioned. If you send a lot of emails it can be helpful to use a reporting tool to process these reports. (This is what I found:

Testing and Further Reading

You may want to use the’s resources to test your SPF, DKIM and DMARC setup. DNS changes can take up to 48 hours to percolate, so do remember to be patient!

With huge thanks to Gauhar Kassymbek, Matt Morris, Michiel van Gaalen and Tobi Fondse for their inputs on this article!

3 thoughts on “Salesforce Email Deliverability Tips (All you need to know about SPF, DKIM and DMARC)

  1. Excellent article thanks Paul. I created a blog back in 2019 when I was improving email deliverability for a client and couldn’t find a detailed How To guide. I’ve popped a link in my blog to this one as I didn’t cover DMARC and yours is more detailed (thank you!). One of the issues I found was that when sending to the same domain as your org, even with SPF and DKIM it still flags as potential spam – have you found a similar issue or have you found a solution to this? In my blog, for organisations using Gmail, I suggested using the Gmail integration (in addition to SPF/DKIM) as it removes the ‘via…..’ when viewing the email on a laptop and it ensured that it wasn’t flagged as spam even when sending from and to the same (org) domain. Let me know if you’ve found a solution when sending to the org domain other than whitelisting? This is my How to Improve Email Deliverability in Salesforce Lightning blog:

    1. That’s strange. I’ve found by adding the SPF and DKIM it removed the issue when viewing emails straight on Gmail. Maybe if it wasn’t set up with SPF originally, it needs to be retrained (although that feels marginal/unlikely/grasping!). It could also be that Gmail has improved the way they handle SPFs since then. p.s. Apologies for the delayed response. I hadn’t spotted your message.

      I would also use only the the SPF tools to double check that everything is configured 100% correctly… although to be honest, the examples in your blog look spot on.

Add Comment