Email Security – Part 4: DKIM (DomainKeys Identified Mail)
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!
5 Ways to Determine if a Website is Fake, Fraudulent, or a Scam – 2018
in Hashing Out Cyber SecurityHow to Fix ‘ERR_SSL_PROTOCOL_ERROR’ on Google Chrome
in Everything EncryptionRe-Hashed: How to Fix SSL Connection Errors on Android Phones
in Everything EncryptionCloud Security: 5 Serious Emerging Cloud Computing Threats to Avoid
in ssl certificatesThis is what happens when your SSL certificate expires
in Everything EncryptionRe-Hashed: Troubleshoot Firefox’s “Performing TLS Handshake” Message
in Hashing Out Cyber SecurityReport it Right: AMCA got hacked – Not Quest and LabCorp
in Hashing Out Cyber SecurityRe-Hashed: How to clear HSTS settings in Chrome and Firefox
in Everything EncryptionRe-Hashed: The Difference Between SHA-1, SHA-2 and SHA-256 Hash Algorithms
in Everything EncryptionThe Difference Between Root Certificates and Intermediate Certificates
in Everything EncryptionThe difference between Encryption, Hashing and Salting
in Everything EncryptionRe-Hashed: How To Disable Firefox Insecure Password Warnings
in Hashing Out Cyber SecurityCipher Suites: Ciphers, Algorithms and Negotiating Security Settings
in Everything EncryptionThe Ultimate Hacker Movies List for December 2020
in Hashing Out Cyber Security Monthly DigestAnatomy of a Scam: Work from home for Amazon
in Hashing Out Cyber SecurityThe Top 9 Cyber Security Threats That Will Ruin Your Day
in Hashing Out Cyber SecurityHow strong is 256-bit Encryption?
in Everything EncryptionRe-Hashed: How to Trust Manually Installed Root Certificates in iOS 10.3
in Everything EncryptionHow to View SSL Certificate Details in Chrome 56
in Industry LowdownA Call To Let’s Encrypt: Stop Issuing “PayPal” Certificates
in Industry Lowdown