Preventing Email Forgery Part Two: DKIM

In our next post in this series, we look at another way to prevent forged email: DKIM. By using encryption techniques and digital signatures, the sender’s servers can transparently “sign “a message so that you can verify the source and ensure the message has not been modified. DKIM works together with SPF to stop fraud and improve email security.

DKIM – Domain Keys Identified Mail: A Simple Explanation

DKIM stands for “Domain Keys Identified Mail.” Actually, the acronym can be further expanded to “Domain-wide validation Mail Identity through use of cryptographic Keys.” To understand DKIM, we need to pause and look at what we mean by “cryptographic keys” and how they can be used.

Cryptographic Keys

In security, there is a concept called symmetric encryption. Users pick a password and use a cipher to convert a regular (plaintext) message into an encrypted (ciphertext) message. Someone else who knows the password and cipher can reverse the process to get the regular message back in plaintext. 

Another prevalent but more complex concept is asymmetric encryption. Using this method, one can create a key pair or a combination of two keys. A message encrypted using Key One can only be decrypted with Key Two and vice versa. We typically call Key One our “private key” because we keep that safe and secret. Key Two is our “public key” and can be accessed by anyone.

What are the benefits of asymmetric encryption?

1. Signatures: Anything encrypted using Key One can be decrypted by anyone. If they can decrypt it, that proves that you sent it. Only you have the private key, and thus, only you could have encrypted it in the first place.
2. Encryption: Anyone can use your public key to encrypt a message that you can only open (using your private key).

How DKIM Works

DKIM uses asymmetric encryption for signing email messages. This validates the sender’s identity and ensures the message contents are not altered in transit. Below is a simple overview of how it works.

Message Sending:

1. Make a Key Pair: The owners of the sender’s servers create a cryptographic key pair.
2. Publish the Public Key: They publish the public key in the DNS records for their domain.
3. Sign Messages: Using the private key, the sender’s servers look at selected message headers (including the sender’s name and address, the subject, and the message ID) and the message body, and they use a cryptographic “hash” function to make a unique fingerprint of this information. Any change to that data would change the fingerprint. This fingerprint hash is also encrypted using the private key. Then, it is added to the message as a new header called “DKIM-Signature.”

Message Receipt:

When you receive a message signed using DKIM, you know the purported sender, their IP address, and the additional DKIM-Signature. However, you cannot trust that the signature header is real or has not been tampered with. Fortunately, you do not have to trust it unquestioningly; DKIM allows you to verify it. Here is what happens on the recipient’s side:

1. Receipt: The recipient’s inbound email server receives the message.
2. Get the Signature: The encrypted DKIM fingerprint is detected and extracted from the message headers.
3. Get the Key: The recipient’s server looks in the sender’s DNS settings to get the public DKIM encryption key.
4. Decryption: The fingerprint is decrypted using the public key.
5. Fingerprint Check: The recipient then uses the message body and the same headers as the sender to make another fingerprint. If the fingerprints match, the message has not been altered since it was sent.

As a result, you can verify the sender’s identity because:

1. We know that the message has not been modified since it was sent. The sender’s name and address (among other things) are the same as when it was sent.
2. We know the message was sent by a server authorized to send emails for the sender’s domain, as that server used the DKIM private key.

So, through encryption, we have a way to verify that the message was sent by a server authorized to send email from their domain, and thus, we have a solid reason to believe the sender’s identity. Furthermore, this validation does not rely on server IP addresses alone and thus does not share the weaknesses of SPF.

Setting up Domain Keys Identified Mail

It is up to the domain owner to configure their DNS settings for DKIM to be checked by the recipients. You must have access to the domain and the ability to update your DNS records to implement DKIM. 

DKIM is set up by adding unique entries to the published DNS settings for the domain. You can use a tool like this DKIM Generator to create your DKIM cryptographic keys and tell you what you should enter into DNS. Your email provider may have their own tools to assist with this process. The private key must be installed on their mail servers, and DKIM must be enabled. We recommend asking your email provider for assistance.

We will not spend time on the details of the configuration or setup here. Instead, we will look at the actual utility of DKIM, where it fails, and how attackers can get around it.

The Benefits of DKIM

Once DKIM has been set up and is used by your sending mail servers, it does a fantastic job with anti-fraud. It is more robust than SPF. It also helps ensure that messages have not been modified since they were sent. We can be sure who sent the message and what they said, while SPF does not provide any assurance that messages were unaltered.

DKIM is highly recommended for every domain owner and every email filtering system. However, as we shall see next, it’s not time to throw a party celebrating the end of fraudulent emails.

The Limitations of DKIM

While Domain Keys Identified Mail is significantly stronger than SPF on its own, it continues to have limitations in the battle against email fraud.

Identifying Email Sending Servers

To properly use DKIM, all servers that send emails for your domain must have it set up and have keys for your domain. This can be challenging to implement if you use vendors or have partners send emails on your behalf. If DKIM cannot be used, emails should be sent using a different domain or a subdomain so that the primary domain can be fully DKIM-enabled and its DNS can tell everyone that DKIM signatures must be present on all messages. You want to be strict with DKIM usage in a way that is hard to do with SPF.

If you cannot be strict, then DKIM allows you to be soft, which indicates that signatures may or may not be present. In such cases (like with SPF), the absence of a DKIM signature does not make a message invalid. However, if your DKIM setup is soft, it makes forgery simple. 

Inter-Domain Forgery

DKIM checks only the domain name and the server. If there are two different people in the same organization, Fred and Jane, either can send email legitimately from their @domain.com address using the servers they are authorized to use for domain.com email.

However, if Fred@domain.com uses his account to send a message forged from Jane@domain.com, the DKIM will check out as okay, even if DKIM is strict.

DKIM does not protect against inter-domain forgery at all. Note: using separate DKIM selectors and keys for each unique sender would resolve this problem (and the next one), but this is rarely done. 

Same Email Provider: Possible Shared Servers Forgery

If Fred@badguy.com and Jane@goodguy.com were using the same email service provider and servers, Jane’s goodguy.com domain would be set up with DKIM. The email provider’s servers are also set up to sign messages from @goodguy.com with appropriate DKIM signatures. What happens when Fred@badguy.com logs in to his account and sends a message pretending to be from Jane?

 The answer depends on the email provider:

1. The provider could prevent Fred from sending emails purporting to be from anyone except himself. This would solve the problem immediately, but it is very restrictive, so many providers do not do this.
2. The provider could associate DKIM keys to specific users or accounts (this is what LuxSci does). Fred’s messages would never be signed by valid the “goodguy.com” DKIM keys, no matter what. This also solves the problem.

However, if the provider’s servers are not restrictive in one of these (or a similar way), Fred’s forged email messages will be DKIM-signed with the goodguy.com signature and appear DKIM-valid.

Legitimate Message Modification

DKIM is very sensitive to message modification. DKIM signature checks will return invalid if even one character has been changed. This is generally good, but email filtering systems may break DKIM. They often read and “re-write” messages in transit where the actual message content is unchanged, but specific (MIME) metadata is replaced with new data. This breaks DKIM, and it can happen more frequently than expected.

Good spam filters check DKIM before modifying messages. Still, if you have multiple filtering systems scanning messages, the DKIM checks of later filters may be broken by the actions of earlier filters. 

DKIM does not protect against Spam

This is not a limitation of DKIM, but it’s worth noting anyway. All DKIM does is help you identify if a message is forged or altered. Most spammers are savvy. They use legitimate domain names and create valid DKIM records to look legitimate.

In truth, this does not make them look less spammy; it just says that the messages are not forged. Of course, if the spammer tries to get by your filters by forging the sender address to pretend that they are you or someone you know, then DKIM can help.

How Attackers Subvert DKIM

So, in the war of escalation where an attacker tries to get a forged email message into your inbox, what tricks do they use to get around sender identity validation by DKIM?

The protections afforded by DKIM are more significant than those provided by SPF. From an attacker’s perspective, it all comes down to what sender’s email address (and domain) they are forging. Can they pick an address to construct an email that will evade DKIM?

1. If DKIM is not set up, it’s easy to forge the email. 
2. If DKIM is set up as weak, the attacker can send a forged message with a missing DKIM signature, which will look legitimate.
3. Suppose the attacker can send a message from one of the servers authorized by the DKIM for the domain. If that server does not care who initiated the message but will sign any messages going through it with the proper DKIM keys, then the message will look legitimate. If the attacker signs up with the same email provider used by the forged domain and that provider’s servers do not restrict DKIM key usage, they can send an email from the same servers and have their messages properly signed. This makes the attacker’s email look valid even if the forged domain’s DKIM records are strict.

 An attacker’s options are much more limited with DKIM. They can only send fraudulent messages from domains with no or weak DKIM support, send through non-restrictive shared email servers, steal the private key used by the sender’s DKIM, or compromise the email account of someone using the same email domain as the address that is to be faked.

The situation is better, but not perfect. Many organizations leave their DKIM configuration weak. They would rather take a chance on forged emails than have legitimate messages be missed due to accidental message modification or because they were sent from a server without DKIM.

We will see in our next post how one can use DMARC to combine the best features of DKIM and SPF to enhance forged email detection further and where the gaps that attackers use remain.

Read next: Preventing Email Forgery Part 3: DMARC