When sending email messages, they contain two "from" addresses: the "envelope from" (e.g., return path) and the "header from" (e.g., the friendly from).

• The "envelope from" is the return address. It tells mail servers where to return (or bounce) the message back to. It's contained in the hidden email message header, which includes technical details servers use to understand who the message is for, what software was used to compose it, etc.
• The "header from" address is an address contained in the "From:" field of an email, which is visible to all email users.

Since both of these addresses can be spoofed by cybercriminals relatively easily, email authentication methods have been introduced over time to help prevent malicious emails from ending up in the recipient's inbox.

If these authentication methods are misconfigured, or not at all, email recipients may notice more emails going to Junk/Spam than they'd like.

To help increase the likelihood of your emails from Salesforce landing in the recipient's inbox rather than Junk/Spam, consider implementing the following email authentication methods.

Note: To fully implement these policies, consult with your organization's IT team.



Sender Policy Framework (SPF):

What is it?

SPF is an email authentication protocol that allows the domain owner to specify which mail servers they use to send mail from that domain.

Brands sending email publish SPF records in the Domain Name System (DNS). These records list which IP addresses are authorized to send email on behalf of their domains.

During an SPF check, email providers verify the SPF record by looking up the domain name listed in the "envelope from" address in DNS. If the IP address sending email on behalf of the "envelope from" domain isn't listed in that SPF record, the message fails SPF authentication.

Per Salesforce, Sender Policy Framework is a simple email validation system designed to detect email spoofing by providing a process to verify which providers are permitted to send emails on your behalf. It also aims to reduce spam and fraud by making it harder for anyone to hide their identity.

If you send an email from a Salesforce application and your domain is ABC.com, you can create an SPF record which authorizes Salesforce.com mail servers as allowed mail servers for the ABC.com domain. When the recipient receives your email, it checks the SPF record of ABC.com to determine if it is a valid email. The message will have a high chance of delivery if it can be validated using SPF.

In line with this, Salesforce has implemented an SPF record for our domain and we encourage our customers to implement SPF records for their domains as well.

Failing SPF authentication is the MOST COMMON cause of an email being delivered to Junk/Spam instead of the Inbox, so this is the first authentication method you should check.

Am I using this?

If you're sending emails from Salesforce, whether or not you're using a Vicasso application, ensure that your IT team has set up an SPF record for Salesforce on their DNS. You can provide s/he with the following Salesforce Knowledge Article which provides specific instructions on how to set up SPF for Salesforce.

To check if a Salesforce SPF record was created for your organization, navigate to a free SPF lookup tool such as MXToolBox. Enter your organization's domain, and click the SPF Record Lookup button.





Considerations with SPF:

• Keeping SPF records updated as brands change service providers and add mail streams is difficult due to lack of visibility.
• Just because a message fails SPF, doesn't mean it will always be blocked from the inbox. It's one of several factors email providers take into account.
• SPF breaks when a message is forwarded.
• SPF does nothing to protect brands against cybercriminals who spoof the display name or "header from" address in their message, which is the more frequently spoofed "from" address since it's the address most visible to the email recipient.
• You should implement SPF prior to DKIM and DMARC policies.

DomainKeys Identified Mail (DKIM):

What is it?

DKIM is a protocol that allows an organization to take responsibility for transmitting a message in a way that can be verified by mailbox providers. This verification is made possible through cryptographic authentication.

Per Salesforce, Use the DKIM (DomainKeys Identified Mail) key feature to let Salesforce sign outbound email sent on your company's behalf. These signatures give recipients confidence that the email was handled in a way that's consistent with your company.

See the following documentation on Creating a DKIM Key in Salesforce.




Once the DKIM Key is created, provide the details to your IT Team. From there, they can add this to the DNS record for the respective domain.

Am I using this?

DKIM records cannot be searched in the same fashion as SPF. To confirm if a DKIM record has been set up for your domain, ask your IT team to review the DNS record setup. Your IT team can also adjust the DKIM version, and what aspects of the email are being authenticated (the email header, body, or entire email).

Considerations with DKIM:

• High consumption of resources by the servers. 
• The information validated by DKIM is only on the server-side, and end-users don't really get a lot from the fact the email is validated under DKIM. 
• White-listing domains trusted solely on the basis of the DKIM signature.

Domain-based Message Authentication, Reporting and Conformance DMARC:

What is it?

DMARC ensures that legitimate email is properly authenticating against established SPF and DKIM standards and that fraudulent activity appearing to come from domains under the organization's control (active sending domains, non-sending domains, and defensively registered domains) is blocked.

DMARC's alignment feature prevents spoofing of the "header from" address by:

• Matching the "header from" domain name with the "envelope from" domain name used during an SPF check.
• Matching the "header from" domain name with the "d= domain name" in the DKIM signature.

A message must pass SPF authentication and SPF alignment and/or DKIM authentication and DKIM alignment. A message will fail DMARC if the message fails both (1) SPF or SPF alignment and (2) DKIM or DKIM alignment.

To set up DMARC, you MUST have already set up both SPF and DKIM for your domain.

Am I using this?

To check if a DMARC record was created for your organization, navigate to a free DMARC lookup tool such as MXToolBox. Enter your organization's domain, and click the DMARC Record Lookup button.





Considerations:

• DMARC Was Not Built for the Cloud Era
• DMARC Can Be Tricky to Implement
• Critical Services Can Be Accidentally Cut Off

In regards to email delivery when using Vicasso' applications, these applications are 100% native to the Salesforce platform and rely on Salesforce's Email Infrastructure. This includes whether the email was sent via Apex code (such as those emails sent by Email to Case Premium) or those sent through Email Alerts using Workflow / Process Builder.

In addition to this knowledge article, Salesforce provides documentation and a number of helpful articles to help ensure a proper configuration for sending emails. See the following links for reference.

Guidelines for Configuring Deliverability Settings for Emails Sent from Salesforce
Improve Deliverability of Emails Sent from Salesforce
Test the Deliverability of Emails Sent Through Salesforce
Troubleshoot email delivery problems
Salesforce Ben: Ensure Emails Sent from your Salesforce Org are Delivered! Salesforce Email Deliverability Tips


Please note: This knowledge article is provided as-is. Configuration of email authentication policies is not supported under the scope of support included with your purchase of Vicasso applications.

For further assistance, please contact your Salesforce administrator, Internal IT Team, or Salesforce implementation partner.