DKIM

September 28, 2023 Leave a comment

DKIM. No, it’s not a new singer/rapper/influencer/whatever. It’s a DNS controlled Email Authentication mechanism. What does that mean? Well, if you want a technical explanation, go see my article on Authorization vs Authentication, since that is important to understand if you want to understand DKIM. DKIM stands for DomainKeys Identified Mail. It uses a feature of Public Key Authentication to allow receiving mail servers to verify that the message is not modified in transit and that the sender is authentic. Kinda.

What DKIM Does

I mentioned this already. DKIM authenticates messages in a limited capacity. Like other standardized security mechanisms (SPF, DMARC, etc) it is a bit of a stop-gap solution meant to limit spam and prevent email spoofing and phishing attacks. If DKIM is enabled, it will allow a mail security system to verify that a message comes from the domain it claims to come from.  It will only protect one domain and one mail system. If you have multiple domains, you have to set up DKIM for each one. If you use a third party mail service like Mandrill to send messages, you have to set up DKIM for that system as well (many of those solutions allow you to configure “on behalf” sending, which doesn’t require DKIM, but still requires configuration in the third party system). And that’s pretty much it. DKIM doesn’t do much, to be honest, but it is extremely useful in preventing spoofing on your domain when combined with SPF and DMARC. I’ll go over that in more depth in a future article, but without those in place and configured properly, DKIM does almost nothing. The ability to block messages that fail DKIM exists on the receiver’s mail system, but it has no mechanism for forcing systems to perform DKIM authentication.

What DKIM Doesn’t Do

DKIM is *not* *I REPEAT* *NOT* an encryption mechanism. It will not encrypt messages. Public Key is capable of performing encryption, for sure. There isn’t a standard mechanism to force emails to encrypt. Yes, TLS allows encryption, but if one side doesn’t support TLS or has it turned off (shame on you, admins who do this. SHAAAAAAME!) encryption won’t happen. TLS is also only capable of “In Transit” encryption. But I’m getting off topic.

DKIM doesn’t verify that the sender is authentic. It will only verify that the message is coming from the email domain it claims to be from. If a message is from bob@bob.com, DKIM can verify that the message is coming from a verified email server that sends messages from bob.com. If an attacker is able to gain access to bob@bob.com’s mailbox DKIM will still verify that the message came from bob@bob.com. If an attack takes over the server, DKIM will also give a positive result for any email address used to send messages, even if that email address doesn’t exist. Only the domain itself is protected, so someone with their own server will not get a positive result if they attempt to send as bob@bob.com.

DKIM doesn’t authorize senders. That means it will not prevent someone in an environment from pretending to be someone else. So Jim@bob.com can send emails using the bob.com servers and DKIM will not prevent it from happening if there is not a jim@bob.com mailbox. It also will not prevent jim@bob.com from sending emails using bob@bob.com as the FROM address. Email server security will stop this from happening (hopefully), but an incorrectly configured mail server or security service may not stop it, and DKIM will definitely do nothing about it either.

It will not, on its own, block messages that fail to authenticate. It relies on the receiving mail system to block messages. If the receiver doesn’t block DKIM failures, messages that fail a DKIM check will get through. This is just like SPF. The receiving server can choose to ignore SPF, DKIM, and DMARC if configured to do so. I really wish mail security systems would not allow admins to ignore these solutions, but some of them do. I’m looking at you, Mr. Mail Security System that starts with P.

How Does DKIM Work?

As I mentioned, DKIM uses Public Key cryptography to authenticate messages. This means that when DKIM is set up to do its thing, the mail server will generate a Public key and a Private key. The keys are mathematically related to one another, meaning that a message encrypted with a public key can be decrypted with the private key and vice versa. The private key is held securely by the sending server and the public key is published with a DNS TXT record on the domain using what are called “Selectors.” The selector uses an FQDN that typically follows this convention: selecter._domainkey.bob.com. It’s pretty similar to how SPF works, except that the selector’s TXT returns the public key when you do a lookup against it.

The selector’s FQDN is included in the email headers of any message that is configured to perform a DKIM signing operation. The mail server or security system is configured to look for the DKIM FQDN and will perform a TXT record using the selector FQDN and that will allow the server to get a copy of the public key.

When a message is sent, the sending server will perform a hashing operation on a set portion of the message, which can be controlled with the DNS selector record (I’m not going to go over that in this article, though). The result of the hashing function is then encrypted using the private key the server generated and the message is shipped on over to the other server.

The receiving server checks the message headers for the selector data and runs a TXT record lookup against the FQDN specified in the email. It will then use the public key to decrypt the hash value. Once the hash data is decrypted, the receiving server will perform its own hashing operation against the email and compare the two hashes. If they match up, DKIM authentication succeeds and the receiving server does what it’s configured to do in that situation.

The core of DKIM’s security is ownership of the private key. If an attacker is able to obtain the private key, DKIM is not able to detect it and the sender can use any mail server to send messages using bob.com. Luckily, it’s pretty difficult to get a DKIM private key because it’s kept hidden away in whatever mail security system you use. I don’t know of any systems that even allow administrative access to the private key, but be aware that it’s possible and protect it as needed.

Dissecting DKIM

More fun and less mess than that day they had you eviscerate a dead frog in science class (Do they still do that?), we’re now going to look at the DKIM section of an email’s headers to show exactly what is happening. Hokay, so, here we have some headers:

ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816;
        h=mime-version:content-language:accept-language:in-reply-to
         :references:message-id:date:thread-index:thread-topic:subject:to
         :from:dkim-signature;
        bh=PoYQKmrLRAOzERrTBcrYqR5ktmYoTCHJe73mFosmqoQ=;
        fh=8uDsGZ9Vr8GPrNkWky+RKfIOlgN7hqVm6/Na+IPmccI=;
        b=WPKlS2BGykrgcXMowJg5z71ZqGeLUakltPUoejPGgOgi1Bt6a+XK31xT10J7Hl+kzI
         Ac0yW/RxB+VB2qc8ZJlL4XYe7Ac/ZYt06UF0Ozh3WEenpTouofoPhA+zeUpYs54R0gfC
         kYu7nprP3zCnGJdhOXCLTOxj2J1HFUGiC1SqLpcZdL4wk8BNrFFgJYZTe7UyFbXPDLBf
         IzhH7BJjaD8Y4nq2zvkwk8+gQGJrtf06oRd/hZqfrcgswExiDrmg+xmmfgnrOFs3KMCE
         Wgn1Unfb6mqY+gZR9zMcTOMzA1xFiimXnU6au9Et9AfRP+0h6OivzoWsAoJ1nJEwglWN
         hSng==
ARC-Authentication-Results: i=2; mx.google.com;
       dkim=pass header.i=@acbrown-it.com header.s=selector2 header.b=esqxHTUd;
       arc=pass (i=1 spf=pass spfdomain=acbrown-it.com dkim=pass dkdomain=acbrown-it.com dmarc=pass fromdomain=acbrown-it.com);
       spf=pass (google.com: domain of adam@acbrown-it.com designates 2a01:111:f400:7e88::715 as permitted sender) smtp.mailfrom=adam@acbrown-it.com;
       dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=acbrown-it.com

That is the email authentication portion of the email headers from a message I sent to my personal GMail account. So, let’s go through it. First line means this (I don’t know what i=2 means, I think it’s the version number, but I’m not certain)

  1. a=rsa-sha256; – This is the cipher suite used to sign the message. RSA encryption using SHA256 hashing.
  2. c=relaxed/relaxed; – This is a DMARC domain checking instruction. Relaxed means DMARC will allow subdomains to authenticate with the same settings as the root domain.
  3. d=google.com; – The domain of the server that authenticated the message.
  4. s=arc-20160816; – The server that authenticated the message. This and #3 result in an FQDN of arc-20160816.google.com.

The next line is less important and just covers the message format and type. I’m not 100% sure on how to read this, but it’s not super important as far as DKIM is concerned. The next two lines are a bit more important because they show what portions of the email were used to generate the DKIM signature string (This can be defined in the DKIM TXT record if you wish). In this case

  1. The Message ID
  2. Date
  3. Thread index (which part of a message chain it is)
  4. Thread topic (subject of the thread)
  5. Subject of the message
  6. Recipient
  7. Sender.

After that is “dkim-signature,” which introduces the actual DKIM signature generated by the sending server. The following 8 lines are the signature itself. It shows as a bunch of semi-random characters that include the encrypted hash of the above message attributes. The receiving server will decrypt this string with the domain’s public key to expose the hash generated by the sender and generate another hash using the same message attributes. Once generated, the two hash values are compared. If they are the same, DKIM passes. If not, DKIM fails.

After the signature, we get into another bunch of identifying information. This time, though, it’s telling us about the sending domain. The first line, however, shows the MX record of the recipient. After that we have:

  1. dkim=pass – The result of the DKIM check
  2. header.i=@acbrown-it.com – The domain of the message that sent the message.
  3. header.s=selector2 – The DKIM selector used to generate the hash. This is used by the recipient server to look up the public key. In this instance, I have two DKIM selectors and the email used selecter2._domainkey.acbrown-it.com’s key to generate the message hash value.
  4. header.b=esqxHTUd; – Your guess is as good as mine. I don’t know.

The rest of the header shows the full disposition of the SPF, DKIM, and DMARC checks. For this email, everything passed because I have DKIM properly configured on my domain. And that’s it. You can usually look at the headers of any message to see this info. It helps to understand the pieces because you may need to verify whether these checks passed if messages are bounced.

Implementing DKIM

Here’s the part you were probably looking for. I can’t give specific instructions here because each mail security system has different steps to enable DKIM. The crux of the issue, though, is that your mail system needs to generate a key pair. Once that’s done, the public key needs to be advertised. This is done with a TXT record using one or two selector FQDN. For my email domain (acbrown-it.com), I used a CNAME record to redirect systems to look at Exchange Online’s DKIM key system. That CNAME points to:
selector2-acbrownit-com01i._domainkey.acbrownit.onmicrosoft.com which is my domain’s tenant. When you run a TXT lookup against that, you get the actual DKIM public key record, which is:

 

v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCvkDpt4g2BwKXeq/1LmJeDsxusKea9kVGNGEH3bi6DpuV803Fv9IjYTRtE/ujmYMPrVe9ReFMsrt/c64xwZYMXa2cEm1J1ipXKi8XUnckVC87IuLYDJuf+YnrkmJNps8LLQ+LF2gx79GycnEoKopwSSspmHn4jocxfSO4j88gW8QIDAQAB;

When configuring DKIM, you either need to configure CNAME records to properly point to a DKIM system (like in Exchange Online) or publish the key directly using a selector record that includes the public key. For information, though, I’ll include some links to the instructions for a number of mail systems here:

I probably missed plenty, but you can usually run a quick search on any search engine and get setup information.

Security Concerns and Solutions

There are some weaknesses in DKIM that need to be addressed. One thing to be aware of is the abuse of similar domain names. A common tactic phishing attacks use is to obtain a domain name that is similar to a target’s. For instance, using acbrownit.com, an attacker could send mail using acbronit.com or acbownit.com. Phishing campaigns can send messages either to customers or internal users with those domains and trick users into thinking it’s real. The solution here is to purchase as many similar domains as possible to prevent attackers using them against you.

It’s also possible for attackers to use domains that are owned by your organization but are not configured with SPF, DKIM, or DMARC. So just purchasing similar domain names isn’t enough to prevent attacks. Those domains need to be properly configured to prevent unauthorized use. In SPF, use v=spf1 -all to block all message sent using any domain that doesn’t send mail for you organization.That *should* be enough to prevent attackers from using that domain because the “-all” in the SPF string with no allows causes all messages sent from that domain to generate a hard fail on SPF checks. It is still a good practice to configure DKIM for the domains in your mail security system to further improve those domains.

I already mentioned the last thing to be aware of. DKIM allows a crypto signature for the entire organization. Every email address used in your organization uses the same DKIM keys, so it’s not possible to verify the sender with DKIM. You can use any valid email address for your domain and the DKIM check will succeed. You need to be aware of this because attackers that gain access to any email can send messages that will pass SPF and DKIM checks. That issue would allow a phishing campaign that uses valid email credentials for anyone to get their messages through spam filters and other security measures because the reputation gain caused by SPF and DKIM implementation is potentially enough to get through. The only way to keep this from happening is to implement effective password policies and endpoint security solutions. User training is also important. As is always recommended, that training needs to include instructions for identifying phishing email.

That’s All Folks!

And that’s it. Everything I know about DKIM so far. It was a lot to cover, but in researching the subject, I found a mountain of “promoted” sites using DKIM articles to sell services, but those sites didn’t effectively cover the subject in as much detail as I wanted. So, there you go. As much detail as I can think of giving. Hopefully it’s enough to help you understand and implement DKIM ASAP.

Leave a Reply