(No Ratings Yet)

Loading...

• Facebook
• Twitter
• LinkedIn
• Mail

July 30, 2018 Comments closed

Email Security – Part 4: DKIM (DomainKeys Identified Mail)

in Hashing Out Cyber Security

Everything you need to know about DomainKeys Identified Mail (DKIM)

The last blog post was a decent technical look into a framework, specifically SPF (Sender Policy Framework), that could help establish trust for email senders and receivers alike. SPF is certainly a little more simplistic than today’s topic, DomainKeys Identified Mail (DKIM), but they are both related and their powers combined form like Voltron™ to make a super protocol with the ability to slay Cthulu and mitigate email tomfoolery.

We’ll get to that super weapon next time but for now, we need to continue walking before we fly.

As we covered last week, SPF outlines the valid IP addresses that are allowed to send email for a given domain. However, something like AmazonSES can send many, many emails. So, specifying, say, the dozens and dozens of allowable IP addresses from AmazonSES might not be enough to dictate who can send what. Many people use AmazonSES so the ability to spoof emails originating from AmazonSES would kill SPF right there. We want to take it to the next level. KABAM! Here’s DKIM (DomainKey Identified Mail).

What is this DKIM you speak of? Tell me more…

The general concept of DKIM is to establish trust. You ever have déjà vu?

Functionally, DKIM is not very complicated. Conceptually, it is also not very complicated. The general concept of DKIM is to update the DNS entry of an email domain to include a digital signature as well as a ‘selector.’ These are added to the domain name in the DNS record to help with the lookup.

When an email is compiled and sent out of the associated email server/server, it will use the same DKIM public key (“signature” in this case) to sign the email (or certain parts of it). The DKIM signature also contains the selector to find the appropriate DNS entry for the email domain. Then, the recipient mail server, or any intermediary server such as an exchanger, can then use the selector to check the signature of the email versus what is listed in DNS. If there is a match, then the DKIM is validated and everyone is happy. Except spoofers.

In a sense, this is another form to verify the origin of email generation. Not only that, but DKIM inherently uses a checksum to ensure that the content of the email has not been modified in transit. Therefore, one can ensure that the juicy bits of an email have arrived the same as they left.

While SPF uses a simple, “Where are you from” concept, DKIM uses a slightly more complex, “Who are you really?” concept to further identify. Both important, both used together to establish trust/verify and both used for DMARC (next week’s topic).

How Do I DKIM?

It’s rather simple, actually. Most mail services (Office.com, Rackspace, AltMail, etc.) will have a section for DKIM (it may be listed as Sender Authentication or something like that). A lot of times, they all but walk you through the process.

The site will generate your email domain’s own, unique, public key for you to copy over to update the corresponding DNS record. Often, the provider will give options to generate a new key and disable old ones.

Depending on the DNS service, the idea is to create a TXT record and then copy over the contents provided by the email service provider. The record should look something like:

v=DKIM1; k=rsa; p= HeYxdz0GCSqGSIb3DQEBAQUAA4GNADCBc/s77MZPKk2hAcP5CfxsgZJiQKBg
QClfSa9MKd6KtasdpZv2sGhKcNFEGzhkk1yrEHonXNBJPAtXawYbALk8+jpse4
A3cOubP5v9WVE1cAIuBJ2JSNPbljfuFLc0I+5v9WVE1cVRXDum+BLxy

Once in place, the sender and receiver do not really notice any difference in the sending and receiving of emails. While you can verify that the key was inserted into emails by looking at the email headers, but functionally, all the magic happens out of purview of the end users.

Again, everything is rather simplistic when it comes to DKIM from the end-user perspective. The real interesting part is when alignment, verification and failures are recorded (via MUA) and analyzed for DMARC which is an aggregated reporting service that provides rankings in order to give end users a glance at how they are doing with compliance and trust.

Stayed for next week when we delve into DMARC and button up this series. Until then, stay safe and happy scrutinizing!

Check out the rest of the Email Security Series

• Email Security – Part 1: Certificate Signed Emails
• Email Security – Part 2: Phishing and Other Falseness
• Email Security – Part 3: Sender Policy Framework (SPF)
• Email Security – Part 5: DMARC, Reporting and Email

• #DKIM
• #Email Security