Basics of Email Authentication

In response to the announcement of Google and Yahoo! changing their email authentication services to make it a little more restrictive to what a user will see in their inbox, I've decided to explain what these changes are and how they benefit both marketers and users alike. Plus, who couldn’t use a refresher on Sender Policy Framework (SPF), DomainKeys Identified Mail (DKIM), and Domain-based Message Authentication Reporting & Conformance (DMARC)?

The Update

Both Google and Yahoo! have released similar updates to their email authentication and list management requirements. 

For example, Google states: “Starting February 2024, Gmail will require the following for senders who send 5,000 or more messages a day to Gmail accounts: Authenticate outgoing email, avoid sending unwanted or unsolicited email, and make it easy for recipients to unsubscribe.” If you or your marketing teams are sending mass emails, this means email authentication is now required, and is one of the first things a Salesforce developer should consider when setting up Salesforce Marketing Cloud or Marketing Cloud Account Engagement (Pardot). Industry trends show that these requirements aren’t going anywhere and shows how important understanding these concepts are. 

Email authentication primarily focuses on three standards to verify the authenticity of an email: the sender, the message, and what to do when it fails those checks. 

Those standards are held in the aforementioned SPF, DKIM, and DMARC records. Let’s take a look at these three Domain Name System (DNS) records in order to understand what they do in relation to email authentication.

SPF

The Sender Policy Framework (SPF) record is a standard for email messaging where all IPs authorized to send from a domain are listed. Essentially, it’s a list of people you allow to send emails for you. SPF is a TXT entry within your DNS. The purpose of this record is to let receiving email servers know who is allowed to send emails on behalf of the sending domain. Without SPF, attackers would be able to impersonate senders and phish recipients for information.

If you’d like to check SPF records, you can use your favorite DNS tool. I will use terminal commands to view the entries:

dig TXT YOUR.DOMAIN.com

You may see a similar SPF record, “v=spf1 include:cust-spf.exacttarget.com -all”. This is a marketing cloud example.

These records will have a format that can typically be broken down into three parts. The first part, “v=spf1”, tells DNS that this is an SPF entry. 

Next is the mechanism. The mechanism in most cases, in regards to Marketing Cloud, will look like this, “include:cust-spf.exacttarget.com”. This means that when your SPF record is checked, the “include:” part says to run an additional SPF check on the given domain, “cust-spf.exacttarget.com”. 

When the SPF check is run on “cust-spf.exacttarget.com”, we can see it returns a list of ip addresses. Which, presumably, is where emails could originate from within Marketing Cloud. 

Lastly, “-all”. This, itself, is two parts. “-” essentially means to fail, and “all”, well, means all. Together, they tell the receiving server to reject, fail, all messages from senders not included in the SPF record. 

There are other ways to configure the SPF record, but I think it is important to first understand it as it relates to Marketing Cloud. More often than not, Marketing Cloud admins and developers will use SAP. Therefore, following the above configuration.

DKIM

Valimail explains DomainKeys Identified Mail (DKIM) well: “DKIM is an email authentication standard that uses public/private key cryptography to sign email messages.” DKIM is also a TXT record in DNS. 

For each message that is sent from Marketing Cloud or Account Engagement, the private key (not included in the DKIM record) is used to calculate a hash based on the contents of the email and includes the hash in an email header, and the email is signed this way. 

When the receiving server gets the message it will do two things. It will compute a hash based on the contents of the email, and it will use the public key from the sender’s DKIM record to decrypt the digital signature in the email header. Once these two things are done, then the receiving server will compare the two hashes. If they match, the email can be delivered!

Also, because the decryption worked, we know exactly who sent the email, and because the hashes matched, we know the contents of the email have not been tampered with. We know who sent the message because encryption done with a private key can only be decrypted with the corresponding public key. Also, if the contents of the email were changed, that would produce a different hash value. This is the clear benefit of using DKIM.

An easy way to see your DKIM record is to start with an email you received. If you choose to “show original”, then you will be able to see the selector needed to search for the DKIM record.

As shown in the screenshot, the selector we need is the value of the “s” attribute within the DKIM-Signature. Now using this selector we can run a quick command in the terminal.

dig TXT <selector>._domainkey.YOUR.DOMAIN.com

This will display the entire DKIM entry including the encryption algorithm and the public key.

DMARC

Domain-based Message Authentication Reporting & Conformance (DMARC) is another TXT record that tells the receiving server what to do with the message if it fails authentication, like SPF and DKIM. View your domain’s DMARC record with the following terminal query:

dig TXT _dmarc.YOUR.DOMAIN.com

If we break down the results, “v=DMARC1; p=reject; adkim=r; aspf=r; pct=100;”, we can see the “v” for version of DMARC, “p” is the policy tag, “adkim” is the alignment node for DKIM, “aspf” is the alignment node for SPF, and “pct” is the percentage of message that should be filtered.

In our case, the policy is to reject the message if it fails authentication. In short, adkim and aspf attributes are set to “r” for “relaxed” to allow us to send from a sub-domain as it will compare the root of the sender domain to the domain set in DKIM and SPF. 

Another benefit of DMARC is that you can have the receiving server send the mailing server result for reporting, but it seems Marketing Cloud does not do that. You can read more about each of the DMARC tags here.

How does this affect us for the Google and Yahoo updates?

Ultimately, proper email configuration will provide marketers more confidence than ever that their messages are reaching the target audience. These changes also provide more control and security for developers. Email audiences will now have inboxes that contain less spam and have confidence the messages are from who it appears they’re from. 

So what do we do? Test, test, and test! Ensure your emails are still making it to the inbox, and if there are any concerns, you can run the example DNS queries to see if the three required DNS records are configured correctly, or reach out to us for help!

One more thing. 

Don’t neglect the importance of the one-click unsubscribe. Honoring unsubscribe requests within ten days is a requirement of CAN-SPAM law. With these changes, it will be required to honor these requests within two days. Again, this gives the power to your email audiences to better control what is in their inbox. Marketing Cloud will build a header for the email message that indicates where one-click unsubscribes can be sent. Make sure the value is correct and working to ensure you comply.

Lastly, one more notable part of this update is the requirement that the spam complaint rate of your emails need to be less than .1%. This is best achieved by keeping your segmentation and email lists nice and tidy.

Using all of these records and one-click unsubscribe have been solid best practices. But, now they are going to be required. 

Finding these terms, values, or queries to be a little too much? If you need help ensuring your email authentication processes are set up correctly, or if you’re looking for help in setting SAP up, let us know!

Donny Guimont is a Salesforce Marketing Cloud Developer and Consultant. Away from Marketing Cloud, he spends time playing hockey, playing disc golf, and reading books with his two kids. When the kids are asleep, it is chill time with his three dogs and wife!