DKIM signatures explained: selectors, keys and what gets signed

The signature header

A signing server adds a header named DKIM-Signature. It is a list of tag=value pairs defined in RFC 6376. The ones you need to read are:

• d= the signing domain, the domain that takes responsibility for the message.
• s= the selector, which names the key to use.
• a= the algorithm, normally rsa-sha256.
• h= the list of header fields that were signed. RFC 6376 requires the From header to be among them.
• bh= a hash of the message body, after canonicalization.
• b= the signature itself, computed over the signed headers and the DKIM-Signature header, with b= treated as empty.
• c= the canonicalization methods, for example relaxed/relaxed.

How the receiver finds the key

The public key lives in DNS. RFC 6376 stores all DKIM keys under a subdomain named _domainkey. Given d=example.com and s=foo.bar, the receiver queries the TXT record at foo.bar._domainkey.example.com.

Because the selector is part of the name, one domain can have many keys at once: one per email service, or an old and a new key during a rotation. It also means nobody can list a domain's DKIM keys from DNS alone. You need the selector, and the place to find it is the s= tag in a message the domain has sent.

Canonicalization: surviving small changes

Mail servers sometimes rewrap long header lines or change whitespace. A signature that demanded identical bytes would break. RFC 6376 therefore defines two canonicalization algorithms each for headers and body. Simple tolerates almost no modification. Relaxed tolerates common ones, such as replacing whitespace and rewrapping header lines, by normalising them before hashing.

Content changes still break the signature, by design. A mailing list that adds a footer to the body or a tag to the subject changes signed data, so the original signature no longer verifies.

Key sizes and algorithms

RFC 8301 updated DKIM's cryptography in 2018. Signers must use RSA keys of at least 1024 bits and should use at least 2048 bits. Verifiers must not accept signatures made with RSA keys shorter than 1024 bits, and rsa-sha1 must no longer be used for signing.

Mailbox providers set the same floor. Google requires a DKIM key of 1024 bits or longer for mail to personal Gmail accounts and recommends 2048 bits where the DNS provider supports it. Yahoo asks for DKIM on every message with at least a 1024-bit key.

What DKIM does and doesn't prove

A valid signature proves that the domain in d= signed the message and that the signed headers and body are unchanged. It doesn't say the message is wanted or safe, and on its own it doesn't connect d= to the From address the reader sees: a message from [email protected] can carry a valid signature from d=mailer.example.net. Requiring the two to match is the role of DMARC alignment.

Rotating keys is simple with selectors. Publish the new key under a new selector, switch the signing server to it, and keep the old key in DNS until messages signed with it are no longer being checked, then empty its p= tag.