If you would like to read the other parts in this article series please go to:
Introduction
We all hate spam and if you are reading this article, you probably know how dangerous spam and phishing attacks can be. As such, I am not going to write paragraphs and paragraphs about what spam and phishing are, their dangers and the importance of fighting/preventing them. I am going straight to the point: DKIM and DMARC.
What is DKIM?
DomainKeys Identified Mail (DKIM) is a public key encryption methodology that works in conjunction with Sender Policy Framework (SPF), by cryptographically linking each message with the sending domain, thus reducing the likelihood of your business email being detected as spam.
In 2005 a consortium of Internet companies submitted to the Internet Engineering Task Force (IETF) the draft “DomainKeys Identified Mail – DKIM” specification, a derivative work based on the work of Yahoo’s DomainKeys and Cisco’s Identified Internet Mail.
A SPF record indicates which servers are authorized to send mail for a domain. Recipient servers perform the check “is this email coming from an authorized mail server”? If not, then the email in question is more likely to be spam. Your SPF DNS record lets the recipient server perform this verification. The SPF check verifies that an email comes from authorized servers.
A DKIM record adds a digital signature to emails your organization sends. Recipient servers perform the check “does the signature match”? If yes, then the email has not been modified and is from a legitimate sender. Your DKIM DNS record lets the recipient server perform this verification. The DKIM check verifies that the message is signed and associated with the correct domain.
As SPF records are public, any spammer can easily find the IPs you authorize to send mail from and spoof their mail to come from those IPs. DKIM helps to prevent that by stating that in addition to look at the SPF record, the sender of the mail must also have this valid encryption key.
Figure 1
In a revolutionary paper back in 1976, Whitfield Diffie and Martin Hellman proposed the notion of public-key (also known as asymmetric key) cryptography in which two different but mathematically related keys are used: a public key and a private key. A public key system is constructed so that the calculation of one key is computationally impossible from the other, even though they are related. In public-key cryptosystems, the public key is used for encryption and is freely distributed, while its paired private key is used for decryption and must remain secret.
Public-key cryptography can also be used for implementing digital signatures and this is what DKIM uses. Digital signatures are permanently tied to the content of the message being signed and any attempt to alter its content will be detected. In digital signature schemes, there are two algorithms: one for signing, in which a secret key is used to process the message (or a hash of the message, or both), and one for verification, in which the matching public key is used with the message to check the validity of the signature. This provides two advantages:
- Authentication – digital signatures can be used to authenticate the source of messages. When ownership of a digital signature secret key is bound to a specific user, a valid signature shows that the message was sent by that user and no one else (assuming the private key has not been compromised);
- Integrity – in many scenarios, the sender and receiver of a message may have a need for confidence that the message has not been altered during transmission. Although encryption hides the contents of a message, it may be possible to change an encrypted message without understanding it. However, if a message is digitally signed, any change in the message after signature invalidates the signature. Furthermore, there is no efficient way to modify a message and its signature to produce a new message with a valid signature, because this is still considered to be computationally impossible by most cryptographic hash functions.
DKIM uses DNS to publish a Public Key, so that any party that wants to validate a signature can easily find it and use it to validate the DKIM signature. When a sender wishes to send an email to a recipient, the sending server calculates a crypto signature that covers the relevant parts of the message using the Private Key. The signature is then placed in an email header and the message is sent. At any point in travel the signature is validated using the public key.
Spoofed emails will not carry a valid signature so these are now easy to detect. Using DMARC (discussed in the next part of this article series), it is possible to help the recipient decide what to do with these messages that do not pass validation, typically asking for their rejection and reporting to the legitimate organization for further investigation.
DKIM in Office 365
Many email service providers such as Google, Yahoo! or and AOL have been offering DKIM for years now. So why has not Microsoft? Well, Microsoft went down a different route a few years ago, SenderID. But this is now changing and Office 365 finally supports DKIM.
At the time of writing this article, Office 365 supports inbound validation of DKIM over IPv4 and IPv6. Outbound DKIM signing is not yet available but it is in the roadmap for Q1 2015, so stay tuned for an update!
Office 365 will be giving customers the ability to DKIM-sign all of their outbound email by either using their own DKIM keys or let Office 365 generate them. This will be the case for fully hosted, hybrid or on-premises customers!
For inbound validation, we do not need to do anything as Exchange Online Protection (EOP) is already automatically validating DKIM through the DKIM-Signature header in the message headers. In the screenshot below we can see this header and the DKIM signature itself. We can also extract certain information from it such as the fact that the signing domain is gmail.com (d=gmail.com).
The result of a DKIM-Signature validation is stamped in the Authentication-Results header and, for now, in a temporary X-DkimResult-Test header as well. In the following screenshot we can see both the DKIM signature and its validation:
Figure 2
If a message fails DKIM verification, the header will say dkim=fail with the reason for the failure in parentheses such as invalid body hash, key query timeout, no key for signature, and so on.
Office 365 verifies DKIM signatures when receiving the message. However, after the message has been scanned by EOP, the existing DKIM-Signature may no longer be valid if the message is relayed to an on-premises server and this server tries to re-verify it. This is because EOP modifies some parts of the message, thus making the DKIM signature invalid… Microsoft is planning to change this behavior soon.
Administrators can also create Exchange Transport rules to action on these messages depending on the results of a DKIM validation to filter or route messages as needed.
Conclusion
In the first part of this article series, we had an overview of what DKIM is, how it works and what its purpose is. In the next part we will look at DMARC.
If you would like to read the other parts in this article series please go to:
