Good practice, Part 5: E-mail authentication and reporting

Most businesses send e-mail from individuals and systems to customers, suppliers, and partners. But are you sure these messages actually reach their recipients? What can you do to improve deliverability? This article will address both questions.

Would it not be great if you were able to tell your recipient that e-mail you send them actually come from you, and getting reports about whether or not e-mails are delivered? Great news! You can!

Note. This article only covers the basics of the mentioned topics to make you aware of them. A deeper understanding of these topics should be acquired before starting an implementation project.

Authentication with SPF and DKIM

Let’s have a look at authentication first. The part where you tell recipients that mail that you send actually come from you, and help them filter out imposters. We will look at SPF and DKIM to handle this.

SPF (Sender Policy Framework)

SPF is a framework where you define what e-mail servers are allowed to send email on your domain’s behalf. Let’s say I own domain.com and I want to send e-mail from jonas@domain.com to a customer, via my e-mail server.

I want to make sure recipients out there can trust that when I send mail from jonas@domain.com, they can trust that the message is legit. But if an imposter sends something from jonas@domain.com (which is incredibly easy), the receiver should be able to detect it and reject the message.

To do this, I create an SPF record in my DNS for domain.com, where I add the IP of my e-mail server as the only approved e-mail sending source of e-mail coming from domain.com.

So when I send e-mail to someone from jonas@domain.com via my e-mail server to someone, the receiving e-mail server will see that the e-mail I sent seems to be sent on behalf of domain.com. It can then ask the DNS of domain.com if the IP it received the e-mail from is an approved sending source. This example is illustrated in the image below.

Since I added “-all” after my approved IP in the SPF record, the receiving e-mail server know that if an e-mail from domain.com comes from any other IP, it should reject it and not deliver it to the recipient mailbox.

So, if an imposter sends a fake mail from jonas@domain.com, the receiving e-mail server will reject the e-mail if it looks up the SPF record for domain.com.

If you decide to implement SPF, make sure you first diligently identify all legit sending sources for your domain before creating the SPF record.

DKIM (DomainKeys Identified Mail)

Another method of letting receivers decide if e-mail from your domain is legit or fake, is to use DKIM. Using DKIM, your e-mail sending server will create an unique signature for each e-mail it sends out. This signature is based on the content of the email and a private key. Instructions for the receiving e-mail server on how to verify the signature is also included.

When the receiving e-mail server gets the e-mail with a DKIM signature, it will follow the included DKIM instructions. Contacting the sending domain DNS for a public key is one of these steps. If there is a public key there, it will try verify the DKIM signature using that key. In short, a DKIM signature can only be verified with a public key that “matches” the private key.

But the private key is only known by the sending e-mail server, so an imposter cannot create a fake DKIM signature that will be verified with a legit public key.

On the other hand, if an e-mail contain a DKIM signature that has been created with a private key that don’t “match” the public key, the DKIM check will fail.

Issues with SPF and DKIM

Let’s address some of the drawbacks with SPF and DKIM.

SPF

If an e-mail passes multiple servers before reaching the receiving e-mail server, the sending IP address evaluated by the receiving e-mail server can be different from the actual sending IP. This will fail the SPF check.

DKIM

The process of verifying a DKIM signature include multiple steps, and if some part of the e-mail is altered in transit, the DKIM signature may not be verified.

How can we reduce these drawbacks, you ask? Meet DMARC.

DMARC (Domain Message Authentication Reporting & Conformance)

DMARC has multiple purposes. We will have a look at the authentication part first.

Authentication

Since SPF and DKIM by them-self can fail even if the sender is legit, DMARC ties both of them together under its umbrella. So if a receiving e-mail server is using DMARC to authenticate incoming e-mails, it will check both SPF and DKIM. So if one of them fail but the other passes, it can accept the e-mail. This makes authentication more robust.

Reporting

Another part of DMARC is reporting. In your DNS you can ask receiving e-mail servers to report back to you about e-mails received that came from your domain. This include legit mail actually sent by your employees and systems, but also e-mail from imposters!

This will give you insights into your deliverability, and maybe show you e-mail sending servers you forgot about initially (since e-mail from them will fail SPF checks).

Summary

SPF, DKIM and DMARC are great for e-mail integrity, authentication, deliverability and reporting. It help protecting your recipients from impersonators pretending to be you, and help you mitigate the risk of being the next phishing victim if those sending e-mail to you implement these standards as well.

I strongly recommend everyone to research and implement them. Include all business units at your company that sends e-mail on your domains behalf in this project, to reduce issues with implementation and to give them insights in deliverability. Most likely, every unit involved will benefit from this.