DKIM – Domainkey Identified Mail



1.      What is DKIM?

DKIM is short for DomainKeys Identified Mail. The current specification for DKIM  is RFC6376. (http://www.ietf.org/rfc/rfc6376.txt) DKIM permits organizations to add a header to emails with cryptographic signatures in a way that other organizations can verify independently. The independence is achieved by the receiving MTA checking for DKIM Resource Records in the DNS domain used in the signature. Successful DKIM verification generally means that the signer has authorized the email and that some basic set of headers have arrived unmodified.

2.      Why use DKIM?

DKIM allows an organization to lay claim to a message they send in a way that recipients can verify. This allows the receiver to associate the reputation of the signing domain with the message received. It also allows receivers to check if the signature or signed headers have been modified or forged.

If senders sign all outgoing messages, then forged messages are easy to identify. With the addition of ADSP, senders can advise receivers how to treat unsigned messages. (ADSP is RFC 5617: http://www.ietf.org/rfc/rfc5617.txt )

Receivers can more easily track the source of signed messages. Failed signature verification can point to possible forgery or modification of the message. Receivers can act on this information for notification or filtering of messages.

3.      What is the network impact of adding DKIM to an MTA?

Incoming email:

For each email containing a DKIM signature, there will be a DNS query for the public key associated with the selector used in the signature. If ADSP is enabled as well, then when a DKIM check fails or a DKIM signature is not present, an additional DNS query is made to retrieve the ADSP policy. (ADSP is RFC 5617: http://www.ietf.org/rfc/rfc5617.txt )

In addition, DKIM signatures are decrypted during the verification phase.

Outgoing email:

Every email signed requires signature encryption.

4.      What do DKIM DNS RRs look like?

DKIM DNS Resource Records contain the public key used for a specific selector. Here are a few keys retrieved from facebook.com and gmail.com with the keys truncated:

s1024-2013-q3._domainkey.facebook.com. 86400 IN TXT “k=rsa\; t=s\; h=sha256\; p=MIGfMA0GCSqG…”

20120113._domainkey.gmail.com. 300 IN   TXT     “k=rsa\; p=MIIBIjANBgkqhkiG9… “

5.      How do I manually retrieve a DKIM RR from DNS?

You will need to know the selector and the domain. Using the “dig” tool:

$ dig txt SELECTOR._domainkey.DOMAIN

6.      What do DKIM Signature Headers look like?


DKIM-Signature: v=1; a=rsa-sha256; d=example.net; s=brisbane;
c=simple; q=dns/txt; i=@eng.example.net;
t=1117574938; x=1118006938;
h=from:to:subject:date;
z=From:foo@eng.example.net|To:joe@example.com|
Subject:demo=20run|Date:July=205,=202005=203:44:08=20PM=20-0700;
bh=MTIzNDU2Nzg5MDEyMz….QOTAxMjM0NTY3ODkwMTI=;
b=dzdVyOfAKCdLXdJOc9G2q8Lo….+yuU4zGeeruD00lszZVoG4ZHRNiYzR

7.      What do DKIM authentication results look like?


Authentication-Results: mx02.ctchouston.com; dkim=pass
reason="1024-bit key"
header.d=facebookmail.com header.i=@facebookmail.com
header.b=NVwgY4X2; dkim-adsp=pass

8.      What are the possible “dkim=” results and what do they mean?

dkim=pass: Successful verification. DKIM Signature exists, selector in signing domain exists, and the required headers are unmodified.

dkim=fail: Unsuccessful verification. DKIM Signature exists, selector exists but headers don’t appear unmodified.

dkim=temperror: Temporary recoverable error such as a DNS query timeout.

dkim=permerror: Permanent non-recoverable error such as:

Selector key not found

Bad message or signature format

Signing key too small (512-bit keys)

Here are some OpenDKIM dkim=permerror reasons from actual email:

reason=”key not found”

reason=”verification error: signing key too small”

reason=”verification error: signature timestamp in the future”

9.      How is an email changed when DKIM is used by the MTA?

Additional email headers are added to message either by the signing process or the verification process. The header additions are transparent to users.

10.  Will a user notice the existence or absence of DKIM related headers?

No. All DKIM information is in the email headers only unless an organization chooses to filter or modify email based upon DKIM information.

11.  Does DKIM have anything to do with content encryption?

No. DKIM is not intended to protect the contents of an email. Its purpose is limited to verification of the source of an email and that the headers associated with DKIM have not been modified since signed. Other technologies such as OpenPGP [RFC4880] and S/MIME [RFC5751] address content encryption.

12.  Does DKIM have anything to do with transport encryption?

No. DKIM only adds headers with either a signature or a verification result. Transport encryption of emails is most often achieved through TLS.

13.  What are DKIM Selectors?

Multiple and concurrent public keys are distinguished by a selector. Each selector will have a DNS RR that contains the public key used by verifiers. Each signing MTA must have a copy of the selector private key in order to add a signing header to the message. The name of selectors can be arbitrary or permit identification of signing location, MTA, a specific person or group, or delegation.

14.  How big are the selector keys?

The default and recommended size is 1024-bits. Technically you can create 512, 1024, or 2048 bit keys. Do not use 512-bit keys as they are too easily cracked and several companies were burned by this back in 2012.

From RFC6367 §3.3.3 Key Sizes:

“Signers MUST use RSA keys of at least 1024 bits for long-lived keys.”

Wired magazine had a nice article back in 2012 about Google’s key being cracked when it was only 512-bits: http://www.wired.com/2012/10/dkim-vulnerability-widespread/all/

15.  How do I check the size of a selector with openssl?

You will have to fetch the public key and format it properly. Here is a simple script that takes selector and domain as parameters and returns the public key size and modulus. It is not real elegant but it does the job.


-------START SCRIPT-------
:
SELECTOR=$1
DOMAIN=$2
{
echo "-----BEGIN PUBLIC KEY-----"
dig +tcp +short txt $SELECTOR._domainkey.$DOMAIN | sed -e 's/.*p=//
s/\\;\"$//
s/"$//
s/" "//g' | fold -w 79
echo "-----END PUBLIC KEY-----"
} | openssl rsa -text -pubin
-------END SCRIPT-------

16.  What signing and verification algorithms are used?

DKIM uses rsa-sha256 (recommended) or rsa-sha1. The choices balance security with computational requirements.

17.   How do I create signing keys?

Create a default 1024-bit key in the current directory with opendkim:

$ opendkim-genkey –selector=name –domain=name

The public key will already be in a format suitable for a DNS RR record.

It is possible to create the key with openssl directly.

The following will create a 1024-bit signing key:

$ openssl genrsa -out selector.private 1024

The following extracts the public key:

$ openssl rsa -in selector.private -out selector.public -pubout -outform PEM

The private key is what you use with your DKIM software for signing. The public key is placed in your domain’s DNS. Be sure to know what you are doing when placing in DNS. I’ve seen a lot of mangled DNS records associated with DKIM.

You can check a public key if it is in PEM format with the following:

$ openssl rsa -pubin -text -noout -in selector.public