What Is DKIM?

DKIM (DomainKeys Identified Mail) is a protocol that allows an organisation to take responsibility for transmitting a message by signing it in a way that mailbox providers can verify. DKIM record verification is made possible through cryptographic authentication.

Implementing email authentication technology like DKIM is one of the best ways to protect your employees and customers from targeted email attacks. Earlier this month, we published a post breaking down what SPF (Sender Policy Framework) is and why it matters. This week, we turn to another email authentication protocol, DKIM (DomainKeys Identified Mail).

There are three main steps to the DKIM signing process. First, the sender identifies what fields they want to include in their DKIM record signature. These fields include the “from” address, the body, the subject, and many others. These fields must remain unchanged in transit, or DKIM authentication will fail.

Second, the sender’s email platform creates a hash of the text fields included in the DKIM signature. The following text fields,

From: Jane Doe <jane.doe@proofpoint.com>
Subject: Update

for example, will map to this hash string:

3303baf8986f910720abcfa607d81f53

Once the hash string is generated, it’s encrypted with a private key, only accessible to the sender.

Finally, after the email is sent, it’s up to the email gateway or consumer mailbox provider to validate the DKIM signature by finding the public key that perfectly matches the private key. The DKIM signature is thereby decrypted back to its original hash string.

Then, the receiver generates its own hash of the fields included in the DKIM signature and compares it with the just decrypted hash string. If they match, we know two things: One, the DKIM signature fields were not changed in transit, and two, the signer of the email truly owns the email.

The DKIM signature is the main feature of validation. The signature is a hash created by various components within the message. The sender could use the domain, body of the message, and other parts of the message to create a signature. These components are decided when the message is sent, so it cannot change later.

To create the signature, the sender uses the domain’s private key to encrypt the message and create a hash. The recipient email server then uses the sender’s public key to also encrypt the same components from the message. The recipient takes the encrypted result, a hash string, and compares it to the decrypted sender’s hash. If both strings are the same, then DKIM validation passes. Even if a single character in the message has changed, the hash returned by encrypting it with the public key will not be identical to the one sent from the sender’s email server.

A DKIM signature validation process failure indicates that an attacker could have tampered with the message. The DKIM signature and encryption process ensures the integrity of the message so recipients don’t fall victim to phishing and malware attacks from intercepted messages.

The domain’s DNS server hosts the DKIM TXT entry, but the recipient’s email server must be able to locate it among other TXT entries. The DKIM selector indicates where the recipient’s email server can locate the domain’s public key. The public key is used to create a hash and verify it against the same hash created with the private key, so it’s a necessary component in DKIM validation.

Every email message sent with DKIM configurations includes a DKIM-Signature header with the selector included with other information. The following is an example of a DKIM Signature:

DKIM-Signature: v=1; a=rsa; c=relaxed/relaxed; d=mydomain.com; s=s837fhs;

The value located in the “s” tag is the DKIM selector. This selector is generated when you create your private/public key pair. You can find your own DKIM selector after setting up DKIM on your email server and sending a message to yourself. View the email message’s headers and find the DKIM-Signature section of the headers. The value in the “s” tag in the headers is your own DKIM selector.

DKIM and SPF work together to secure email, stop eavesdropping, and prevent data tampering. They are both a part of DMARC (DMARC (Domain-based Message Authentication Reporting and Conformance), but they serve different purposes. DKIM is used to verify that no third party has tampered with data within an email. SPF, however, stops spoofed messages using the sender’s domain.

With an SPF record, the domain owner registers a TXT record on their DNS servers in the same way a DKIM record hosts key information. The TXT information lists all email servers approved to send email messages on behalf of the domain. Should an attacker use spoofed message headers, the SPF record enables the recipient’s email server to detect fraudulent messages and block them from reaching the intended victim’s inbox.

An SPF record only ensures that spoofed email messages cannot be sent to recipients, but it does not guarantee that an attacker did not tamper with the message. Without DKIM, an attacker could hijack messages and send an altered message to the recipient. DKIM works with SPF to ensure the sender is legitimate and the message was not altered during transmission.

DKIM and SPF together add security to the email system, a primary communication tool on the internet. Email had long been a way for attackers to steal identities and user credentials, as most users could not detect spoofed messages. These two strategies are then applied to DMARC rules. DMARC determines what happens to the message if it fails validation.

For large businesses, DMARC rules can quarantine messages for review by an administrator. Quarantined messages don’t reach the intended recipient unless the administrator passes them to their inbox. False positives can be forwarded to the intended recipient so that no important messages are incorrectly dropped and deleted. Once security has been thoroughly tested, you can set DMARC to automatically drop and delete messages that fail DKIM and SPF validation.

DKIM, SPF, and DMARC are often used interchangeably; however, they are three distinct strategies working together to secure email messages. Think of DMARC as the security rules that determine what to do with a message when DKIM and SPF do not pass validation.

DMARC provides three settings for failed DKIM validation: quarantine, reject, and none. The DMARC security process determines which three of these phases will be applied to the message. The email server administrator sets up DMARC settings, so what happens to failed messages depends on administrator preferences.

The “none” setting means nothing happens, and messages still flow to the recipient’s inbox. This setting is for recipients that need to receive messages that have been spoofed or contain malicious content. The recipient could be a security administrator or employee who needs to investigate suspicious messages.

The “quarantine” status is what many administrators use so to review messages that fail validation. The email system places these messages in a safe location where users cannot access them but where an administrator can later review them. By reviewing messages sent to quarantine, an administrator can determine when the organisation is the target of a phishing campaign. Messages in quarantine could also be used to ascertain if SPF or DKIM settings are misconfigured. Some email security systems work with artificial intelligence (AI), so the administrator can point out a false positive to help better “train” the system.

If a message fails DKIM validation and DMARC is set to reject messages, the email server drops the message altogether and does not send it anywhere. This setting is common with public email servers such as Gmail. Google outright drops millions of messages that fail DKIM and SPF validation so that their customers don’t fall victim to phishing, hacking, and other identity theft campaigns.

A DKIM record benefits receivers by informing them of emails that may contain malicious or spam content. It also validates that the data included in the DKIM signature was not changed in transit. But because DKIM is more challenging to implement, fewer senders have adopted it. In addition, DKIM does nothing to prevent cybercriminals from email spoofing the visible parts of an email’s “from” field, including the email address, display name, and domain. So, like SPF, DKIM on its own is not sufficient to protect an organisation from sophisticated phishing attacks.

Combining the best of both SPF and DKIM, the DMARC (Domain-based Message Authentication Reporting and Conformance) authentication standard is the only technology that can validate that the messages using a company’s header “from” domain are legitimate.