DKIM RFC Summary

This is my short summary of the DKIM RFC. This can be a quick reference or a starting point for anyone interested in knowing more about the protocol. I would recommend reading the full RFC document. With that said, let’s get into the summary.

What?

DKIM is an authentication framework which allows a mail receiver to verify the sending organisation and the integrity of the message contents.

It uses public key cryptography and the existing DNS protocol and infrastructure to enable this with minimal effort from the users.

Features

• There is no dependency on public and private-key pairs being issued by well-known, trusted certificate authorities.
• There is no dependency on the deployment of any new Internet protocols or services for public-key distribution or revocation.
• Signature verification failure does not force rejection of the message.
• It is compatible with the existing email infrastructure and transparent to the fullest extent possible.
• It requires minimal new infrastructure.
• It can be deployed incrementally.
• It allows delegation of signing to third parties.

Operation

A very high level flow of DKIM is given below:

1. The sender generates a private-public key pair and publishes the public key as a TXT record.
2. The private key is used to sign any outgoing emails.
3. The signature is added to the message in the DKIM-Signature header.
4. The mail passes through multiple relays and arrives at the destination.
5. The receiver parses the email and verifies the signature.
6. The result of the verification can be used as a part of any mechanism that determines the trustworthiness of the email.

Anyone interested in the authentication protocols and the other components which work in tandem with DKIM can go through RFC 5585, RFC 6376, RFC 8301 and RFC 5863 for a detailed explanation of the protocol.

Protocol Elements

• SHA1 and SHA256 are the hashing algorithms supported by the protocol
• RSA is used for signing the message hashes and any key size between 1024 bits to 4096 bits must be supported by everyone, and, receivers can decide to support higher key sizes, if desired.
• The DNS record published will be in the tag=value format where each tag=value pair will be separated by a semicolon ;
• Each domain can have multiple keys for signing, and the keys are differentiated by selectors present in the email header.
• The TXT records are stored in a subdomain named _domainkey .Given a DKIM-Signature field with a domain example.com and an selector foo.bar, the DNS records will be for foo.bar._domainkey.example.com. So, selectors are a necessary part of input even if it is not present in the record