You’ve got mail: Boosting your email deliverability

Between marketing efforts, system notifications, myriad other use cases for corporate email communications, wondering if your email has reached its intended recipient can feel a lot like the ubiquitous “Can you all hear me?” on Zoom calls. Why are corporate emails flagged as spam or rejected for delivery—and what can you do to prevent these issues during implementation?  

Approaches to validate legitimacy 

Most modern, secure email platforms protect their user base from the millions of malicious, unsolicited, and unwanted spam email messages that are sent out worldwide each day. The most common way to prevent spoofed emails is to authenticate every incoming email against the domain that it comes from—for example, if the message is coming from sender@domain.com, the receiving email server will verify that the email is actually coming from the email server at domain.com before releasing it to the recipient’s mailbox. 

There are three key mechanisms that can be used to validate emails, each with their own cryptic-sounding terms: Sender Policy Framework (SPF), DomainKeys Identified Mail (DKIM), and Domain-based Message Authentication, Reporting, and Conformance (DMARC). 

Together, these three components work in conjunction to provide higher confidence in email authenticity and provide instructions to mail servers.  

SPF

SPF acts as a public directory that allows an email domain to list authorized IP addresses or domains of all mail servers that send outbound emails on its behalf. When an email is sent, the receiving mail server verifies that the IP address of the sending mail server from which an email originated is listed as one that can send outbound emails for that domain. 

This list of valid or allowed IP addresses is published in the sending organization’s Domain Name System (DNS). For example, when working with a client that wanted to send emails to external recipients from their Salesforce org, we recommended that they create the following SPF record in their company’s DNS:  

v=spf1 mx include:_spf.salesforce.com ~all 

Once added, any mail server in the salesforce.com domain—as a third party—was authorized to send outbound emails on our client’s behalf.

DKIM

DKIM is a public key used in the digital verification process—or a way to sign emails. When you sign a paper check, your bank matches your signature with what’s on record. If the two match, the bank releases the funds. Similarly, a receiving email server can use public key cryptography to computationally verify that the digitally signed email did come from the domain from which it claims to originate. Like SPF, a domain’s DKIM record is stored in its DNS.  

For emails originating from the Salesforce platform, you can create a key via DKIM Keys in the Setup menu. After the DKIM key is created, the CNAME record it generates should be published in your organization’s DNS by your email administrator. Salesforce will recognize that the CNAME record has been published and enable key activation. Any subsequent emails sent post-DKIM key activation from that Salesforce org will be digitally signed and will be DKIM compliant.

DMARC 

Unlike authentication protocols SPF and DKIM, DMARC is a complementary policy and the final component of this framework that provides instructions on how to handle an email if the SPF and DKIM checks fail on the receiving mail server.

For example, it could request that a report of all successful and failed emails be sent back to the sending domain server. That kind of data can be used to further secure email delivery or quantify the email delivery issues for the sender. Similarly, a DMARC policy could instruct the receiving server to send a failing email to the recipient’s spam folder, though a receiving server can still choose to ignore your DMARC policy. However, the server is more likely to treat an email originating from a domain that has published a DMARC policy as legitimate simply because you have made the effort to publish one.

Using DMARC establishes trust with the receiver, demonstrating that you’re serious about email deliverability and authentication. Like the other two approaches, a domain’s DMARC record is stored in the DNS. On typical Salesforce engagements, we work with the client’s mail system administrators to implement and establish DMARC policies for their email domain so they can see how well their SPF and DKIM protocols are working. 

Conclusion

SPF and DKIM are two different protocols for authentication that can exist individually or together without having DMARC policies in place. DMARC, on the other hand, can only be created if both SPF and DKIM are in place.

In organizations that use Salesforce for email communications, we strongly recommend that clients implement all three in conjunction to capitalize on each protocol’s strengths and shore up their weaknesses. Practically speaking, this allows emails originating from Salesforce to have the highest chance of landing in their intended target mailbox.