Practically every single business and organisation uses email, every single day. But how many of them know that as a default, the standard security strength of email isn’t that strong.
Creating an Email Security Policy is one of the best things an organisation can do to protect themselves from data loss, reputational damage and even regulatory fines.
This post covers some of the Salesforce features you can use to increase your email security.
TLS
Transaction Layer Security (TLS) prevents the unauthorised access of email messages when they are in transit over internet connections, ensuring they are not viewable by third parties.
A secure TLS connection requires that both the sender and recipient use TLS. When both applications support TLS, it ensures that the data transmitted between them is encrypted with secure algorithms.
How do I implement this?
Organisations can choose a TLS setting when sending email through Salesforce or through an email relay.
TLS Settings can be edited from Salesforce setup. The default setting is ‘Preferred’. This means that Salesforce will attempt to create the TLS connection but will deliver an email in an encrypted state if an encryption cipher can’t be negotiated. More information is available here.
DKIM Keys
The DomainKeys Identified Mail (DKIM) key feature allows Salesforce to sign outbound email sent on your company’s behalf. In essence, DKIM validates the authenticity of the email message.
DKIM adds an encrypted signature to the header of all outgoing messages. Email recipients that receive signed messages then use DKIM to decrypt the message header and verify the message was not changed after it was sent.
This allows DKIM to protect against email spoofing, when email content is changed to make the email appear from someone or somewhere other than the actual source.
How do I implement this?
DKIM keys can be created directly in Salesforce but there are some limitations. For example, you can only have one active DKIM Key per domain. A full list of considerations is available here.
When creating a DKIM key you will need to add ‘Selector’ and ‘Alternative Selector’ unique names so that the keys can be automatically rotated. You will also need to choose the size of the RSA key. (RSA keys are used for encryption. You should consider email recipient limitations and any industry-specific security regulations when choosing the key size. Bigger isn’t necessarily better – there are storage and CPU considerations to be made too).
Sender Policy Framework
A Sender Policy Framework (SPF) is an email validation system designed to detect email spoofing by providing a process to validate which providers can send emails on your behalf. SPF validates the authenticity of the email sender.
An SPF record is a Domain Name Service (DNS) TXT record. It contains a list of all the IP addresses allowed to send email on behalf of your domain.
The SPF mechanism uses the Return Path Address of the domain to identify the SPF record. If the IP address is listed in the SPF record of the DNS, SPF ‘passes’.
SPF does not survive emails that have been ‘forwarded’. This is because the chances are that the list of providers authorised to send emails on your behalf doesn’t include any forwarders.
Salesforce.com delivers emails with a User defined ‘from’ email address, but the mail originates from Salesforce.com mail servers. So if an email containing your company’s domain in the ‘from’ address was sent by Salesforce it would likely fail unless the SPF record contained an entry to authorise Salesforce.
How do I implement this?
You can modify an existing SPF record, or create a new SPF record if one doesn’t exist, which authorizes Salesforce.com mail servers as allowed for your organisation’s domain.
You can enter your domain name into a tool like SPF Record Generator from MXToolbox which will help you create or modify a SPF record.
The entry to include in your SPF record when sending mail from Salesforce is _spf.salesforce.com.
Where you save your SPF record depends on your domain – you’ll most likely need manage or admin permissions to access the setup menu to do this. More instructions are available here.
DMARC
Domain-based Message Authentication, Reporting & Conformance (DMARC) is an email authentication policy, and reporting protocol.
DMARC uses the authentication methods of DKIM and SPF to evaluate the authenticity of email messages.
If you remember that DKIM authenticates the email itself and SPF authenticates the sender you’ll see that DMARC provides a second layer of security (remember that an SPF won’t always pass if an email is forwarded).
A DMARC policy allows a sender to indicate that their messages are protected by SPF and/or DKIM and tells an email receiver what to do when these authentication methods pass or fail.
DMARC also provides a way for the email receiver to report back to the sender about messages that pass or fail the DMARC evaluation.
How do I implement this?
Salesforce Admins can take steps to ensure that the email addresses used in their org are associated with a domain with mail account services that they own and control. The newly generated email addresses can be re-registered with the organisation’s Salesforce User records.
Admins can then create a DKIM Key and a SPF record to authorise Salesforce.com mail servers for your organisation’s domain.
Alternatively, an Email Relay can be set up so that your organisation’s SMTP email server is used – but there are some limitations here.
Email Relay for Salesforce
What is Email Relay?
Salesforce can be configured to automatically route email through your company’s Simple Mail Transfer Protocol (SMTP) server. It may be that some organisations are obliged to use an Email Relay for Compliance purposes.
SMTP is the standard way that email is transferred on the internet. Your SMTP server will be capable of sending DMARC compliant email on your domain’s behalf. Preferably they will be both SPF and DKIM compliant.
When you send an email, Salesforce will connect to your SMTP relay and send the message along with details the relay needs to figure out the next step in the message’s journey.
The relay uses the domain name in the email address and the Domain Name Service (DNS) to identify where the email should be sent.
The email may be sent directly to the Message Delivery Agent (MDA) of the recipient’s email service or it may be handed through multiple Mail Transfer Agents operating as SMTP servers before arriving at the recipient’s inbox.
How do I implement this?
Firstly, there are some options around if and how Salesforce authenticates with SMTP. You should test these in your sandbox first.
For security purposes, if possible it is best to use SMTP authentication to identify yourself with your server. You can store the username and password details in the setting to do this. You’ll also need to select the ‘Required Verify’ TLS option (this means that the server must support TLS) to ensure the login details are passed over in an encrypted format.
You should consider carefully using Bounce Management as this feature can reduce deliverability:
Salesforce bounce management sets each outgoing email’s return path to an address at bnc.salesforce.com. This means that the IP address of your relay doesn’t match the authorized IP addresses for the domain bnc.salesforce.com, which can cause an SPF soft failure which can affect deliverability.
To resolve this problem you can either switch off bounce management or implement DKIM to bolster the DMARC policy.
Furthermore, some of the Email Deliverability settings should be reviewed as they can alter the email’s return path: https://help.salesforce.com/s/articleView?id=000316016&type=1
Email Relays can be created from the Salesforce setup. Some technical knowledge is required to do this. More information is available here.
Once an Email Relay has been set up, you’ll also need to set up an Email Domain Filter for it to work. An Email Domain Filter determines which domains an email relay is restricted to. If your company works with multiple domains, you can create multiple Email Domain Filters and set them to priority order (you’ll need a developer to do this via the SOAP API).
An Email Domain Filter has two main attributes – setting the sender and the recipient domains, which restrict emails being sent based on the domain of the sender or recipient respectively. More information is available here.
Salesforce Email Security Compliance
Salesforce Email Security Compliance allows an organisation to leverage Salesforce’s SPF. Salesforce’s SPF protects against domain spoofing by validating the authenticity of the sender. The emails you send from Salesforce will therefore pass SPF checks even if your organisation doesn’t have an SPF record for your email domain.
Enabling Email Security Compliance updates the envelope ‘from address’ in emails sent from Salesforce to *.bnc.salesforce.com. The email header remains as your email address.
Salesforce’s SPF record authorizes the IPs used by their message transfer agents to send email from the Salesforce domain.
How do I implement this?
Email Security Compliance can be enabled directly from the Salesforce setup – more information is available here.
More resources:
https://help.salesforce.com/s/articleView?id=000336441&type=1
https://help.salesforce.com/s/articleView?id=sf.email_relay.htm&type=5
https://help.salesforce.com/s/articleView?id=sf.emailadmin_email_relay_considerations.htm&type=5
https://blog.mailchannels.com/what-is-an-smtp-relay-service
https://dmarc.org/
https://support.google.com/a/answer/174124?hl=en
https://danielpocock.com/rsa-key-sizes-2048-or-4096-bits/
https://www.dmarcanalyzer.com/spf/#:~:text=The%20Sender%20Policy%20Framework%20(SPF)%20is%20an%20email%2Dauthentication,can%20publish%20authorized%20mail%20servers.&text=SPF%20is%2C%20just%20like%20DMARC,DNS%20(Domain%20Name%20Service).
https://dmarcadvisor.com/what-is-spf/?gclid=Cj0KCQiA0eOPBhCGARIsAFIwTs4jeRbNmR9xPgEuAKMstAZMu-RgFPS3Pw7rWqywJiUJaXM0YEs6sAEaArtcEALw_wcB
https://help.salesforce.com/s/articleView?id=sf.emailadmin_send_from_salesforce_improve_deliverability.htm&type=5
https://help.salesforce.com/s/articleView?id=sf.emailadmin_set_up_tls.htm&type=5
https://www.makeuseof.com/what-is-email-security-policy/
https://www.mimecast.com/blog/why-your-organization-should-have-an-email-security-policy/
https://help.salesforce.com/s/articleView?id=000322936&type=1
https://mailtrap.io/blog/smtp-auth/
https://www.globalsign.com/en/blog/ssl-vs-tls-difference
About Cloud Galacticos
Cloud Galacticos is a Salesforce Consulting Partner with an all-star team. We are user and developer group leaders, bloggers, MVPs and all round Salesforce nerds. Our Salesforce consultancy has people all over the UK including Manchester, Leeds, Newcastle, Sheffield, and London.
So if you are looking for a Salesforce Gold partner with experience to help you make the most of your org, why not get in contact?
Cloud Galacticos is a 
