Maintaining Email Security

Email Privacy

Give users the opportunity to opt out of emails entirely or receive them less frequently. Users might want to know about promotions but perhaps only once per week, not every day. Let users respond on your website or by calling a dedicated phone number. Process their request immediately.

Email Security

When sending email, use a strong encryption method. Encryption uses complex algorithms to scramble the data that is sent. Encrypted data using proper protocols makes interception by malicious users much more difficult.

Email Best Practices

When sending an email, ensure that the subject and content of the email match. The subject line should quickly capture the reader’s attention and express the purpose. For example, Sam works for XYZ Doctor’s office and is tasked with sending patient reminder emails. Instead of sending patient reminders, Sam sends promotional marketing material to 500 patients per day. These patients can’t find their appointment details in the email and are forced to call in, clogging the phone lines.

Be respectful of users and don’t inundate them with messages. Users have a pattern in their mind of how many email messages to expect from retailers, the government, politicians, and doctor’s offices. Utilize surveys and user feedback to anticipate the appropriate number of emails to send to your customers.

In most cases, users ignore emails if they haven’t provided permission to receive them or aren’t familiar with the sender. Before sending out mass emails or even a personalized email, be sure that the user has given you explicit permission. If the user blocks you or marks your email as spam, your details won’t make it through.

Transaction Layer Security (TLS)

TLS (version 1.2 and later) encrypts the contents of mail during transmission. By default, mail sent from Salesforce uses TLS when it’s supported by the receiving Mail Transfer Agent (MTA).

Salesforce no longer supports TLS version 1.0. If TLS 1.0 is used, emails are sent unencrypted.

Review the TLS options in Transaction Layer Security (TLS) to add additional security protection to your email and network.

Sender Policy Framework (SPF)

SPF helps improve the deliverability of messages and protects the credibility of the emails. The domain owner publishes DNS TXT records that identify the IP addresses of the sending gateways. Then, the receiving gateways complete an SPF lookup to determine if the sending email server’s IP address is valid within the SPF scope.

To protect against spamming and email spoofing, businesses often implement security controls that reject email messages that use their own domain name. Email messages are rejected if they can’t be authenticated as coming from the alleged sender. Salesforce is an on-demand service that checks emails on behalf of customers. As a result, legitimate emails sent from Salesforce can be blocked before reaching the recipient. To ensure that email sent from Salesforce doesn’t appear spoofed, consider implementing message authentication using DKIM, SPF, or DMARC. By enabling SPF, admins can ensure that they’re sending emails from a valid email. Admins should also enable email security compliance features or use email relay to have Salesforce route the mail through their own servers. Admins can apply security measures to have Salesforce route the email through their own servers. Sender Policy Framework is an additional security feature but isn’t a standalone to solve all email problems.

Domain Keys Identified Mail (DKIM)

DKIM enables you to add a signature to emails. The signature indicates that the mail was authorized by the signing party. The signature also guarantees that the body and specific headers in the email haven’t been compromised in transit.

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

DMARC is an email policy and reporting protocol built on top of the SPF and DKIM protocols. The DMARC policy tells the receiver what to do if neither protocol succeeds. It also can allow the receiver to report back to the sender.

Email Security Compliance

As an optional feature, Salesforce can modify the From field of emails that are sent from Salesforce to comply with SPF.

Sender ID

Sender ID is an obsolete protocol. Use it only when working with a deprecated version of Microsoft Outlook that requires it.

The Sender ID protocol works similarly to SPF. It verifies a domain from the message’s headers rather than the email’s From field. To deliver mail to a recipient who requires a Sender ID, enable it on the Salesforce Email Deliverability setup page. Sender ID can automatically populate the Sender field of every email that is sent from Salesforce with no-reply@salesforce.com. Enabling Sender ID allows you to prevent spoofing and to prevent malware. While most antimalware and strong firewalls can detect spoofing, this feature provides an additional layer of protection.

Note If your Salesforce org was created in Summer '24 or later, you can't enable Sender ID compliance in Email Deliverability settings.

Bounce Management

Bounce management keeps your contact list up to date by flagging addresses that Salesforce couldn’t deliver to. When bounce management is active and a user sends an email to an invalid address, Salesforce displays an alert next to that email address. You can’t send emails to these addresses until they’re updated. Optionally, you can send a bounce notification to the sender. This option applies to all users in the organization and can’t be enabled on a per-user or per-email basis.

Sending Directly from Salesforce

You can send emails directly from Salesforce using your domain name. When performing these sends, consider these configuration options depending on your preferences and security policies.

To pass SPF and Sender ID, Salesforce might modify the Envelope From and add a Sender header. To avoid modifying the Envelope From, turn off Email Security Compliance and Bounce Management. To avoid adding a Sender header, turn off Sender ID. You can manage these settings in the admin panel.

SPF verifies that the Envelope From domain authorizes the sending IP to send mail for the specified domain. This information is stored in DNS TXT records. SPF passes as long as the information is to a valid Salesforce domain.

DKIM Signing

Salesforce supports the ability for users to create DKIM keys. DKIM keys sign messages sent from Salesforce.

DKIM keys generate two public/private key pairs and add the values to the Salesforce DNS. Two keys are required to facilitate a rotation. These keys provide the user with CNAME records that are added to the domain’s DNS. When the CNAME records are present, make the DKIM keys active in Salesforce.

DMARC

SPF or DKIM must pass to use DMARC. If neither passes, mail can’t be sent through a Salesforce application.