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
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 – 2018in Hashing Out Cyber Security
How to Fix ‘ERR_SSL_PROTOCOL_ERROR’ on Google Chromein Everything Encryption
Re-Hashed: How to Fix SSL Connection Errors on Android Phonesin Everything Encryption
Cloud Security: 5 Serious Emerging Cloud Computing Threats to Avoidin ssl certificates
This is what happens when your SSL certificate expiresin Everything Encryption
Re-Hashed: Troubleshoot Firefox’s “Performing TLS Handshake” Messagein Hashing Out Cyber Security
Report it Right: AMCA got hacked – Not Quest and LabCorpin Hashing Out Cyber Security
Re-Hashed: How to clear HSTS settings in Chrome and Firefoxin Everything Encryption
Re-Hashed: The Difference Between SHA-1, SHA-2 and SHA-256 Hash Algorithmsin Everything Encryption
The Difference Between Root Certificates and Intermediate Certificatesin Everything Encryption
The difference between Encryption, Hashing and Saltingin Everything Encryption
Re-Hashed: How To Disable Firefox Insecure Password Warningsin Hashing Out Cyber Security
Cipher Suites: Ciphers, Algorithms and Negotiating Security Settingsin Everything Encryption
The Ultimate Hacker Movies List for December 2020in Hashing Out Cyber Security Monthly Digest
Anatomy of a Scam: Work from home for Amazonin Hashing Out Cyber Security
The Top 9 Cyber Security Threats That Will Ruin Your Dayin Hashing Out Cyber Security
How strong is 256-bit Encryption?in Everything Encryption
Re-Hashed: How to Trust Manually Installed Root Certificates in iOS 10.3in Everything Encryption
How to View SSL Certificate Details in Chrome 56in Industry Lowdown
PayPal Phishing Certificates Far More Prevalent Than Previously Thoughtin Industry Lowdown