Understanding SPF, DKIM and DMARC

Spam messages have become a huge issue. They are both annoying, flooding our mailboxes with unneeded content and they are a security risk too, as many of them contain links to malicious websites or even viruses. To fight spamming SPF, DKIM and DMARC emerged. The basic idea behind them is to check  the probability of a message being spam, then our mail server can decide what to do with the message: likely putting it in the "Spam" or "Junk" folder, or simply fropping the email altogether.

To measure the spam confidence level of incoming emails, the servers do the following simple checks:

Let's dive deeper in these three!

SPF

There is one thing we need to clarify at the very beginning: anyone can send messages from any email addresses. With no sugar coating, that is a fact. You can set up a basic mail server and send me an email from POTUS@whitehouse.gov, or Bill.Gates@microsoft.com that will appear in my inbox as the actual sender. This is how scammers might use your email address to email your clients with fake data.

But there is good news also because these messages will likely land in the spam folder, or they might not even be delivered to the end user thanks to SPF.

How it works

SPF stands for Sender Policy Framework. It is basically a public DNS record that contains all the webservers that should be sending out messages from the domain in question.

For instance, Always Hot Café has the following public TXT record added in DNS

The structure of the record is very simple: v=spf1 says the clients that this record contains the SPF records for the domain. The consecutive part contains the servers that should be able to send emails form *@alwayshotcafe.com addresses. There we have many options to state the servers, also there can be multiple entries separated by spaces.

DKIM

It stands for DomainKeys Identified Mail. It is used to prove that the message is authentic. That means it is truly from the organization that is claims to be originated from. Also proves that the message was not tampered with in transit.

For a detailed Exchange 2019 DKIM deployment guide please click HERE!

We go through an example email to see how it happens: John Doe sends an email from his John.Doe@alwayshotcafe.com email address. Our email server checks the header of the message and finds the DKIM-Signature section, that tells the server a lot of things:

a=hashing algorithm that was used by John's server to hast the original message.

b and bh: the hashes of the body and header of the original message, encrypted with the private key of the originating email server.

s: the selector tells our mail server where to find the public key to decrypt the encypted hashes stored in b and bh. Here it is selector1, as the domain is alwayshotcafe.com, our mail server knows to check the selector1._domainkey.alwayshotcafe.com DNS record to retrieve the public key, that is:

After decrypting the b and bh values, we have the original hashes the sender generated. Our server calculates the hashes by itself as well and compares those hash values with the originals. If there was a single character difference the hashes would not match.

This check confirms two things: first, if the calculated and decrypted hashes match, that means the message was not changed, it was not tampered with in between sending and receiving. This proves authenticity as if someone intercepted our message, then re-hashed it, they could not have encrypted it again without the private key that only the original sender has.

So, if the calculated and decrypted hashes match, DKIM passes.

DMARC

Domain-based Message Authentication, Reporting, and Conformance, the third pillar of email security. It is also a DNS record, that has one purpose: telling us what should happen if either SPF or DKIM or both fail.

Back to our example the record is the following _dmarc.alwayshotcafe.com TXT record:

It has a few very simple parts:

Hope it was informative.