DKIM RFC Summary

13 Apr 2022

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.


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.


  • 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.


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 and an selector, the DNS records will be for So, selectors are a necessary part of input even if it is not present in the record
Tag Name Description Possible Values Default Value Optional
v Version of the DKIM record DKIM1. It must be the first tag in the record. If it has any other value, the entire record will be discarded. DKIM1 No
h Acceptable hash algorithm sha256 Yes
k Key Type rsa rsa Yes
n Notes for human beings Notes for humans, this is not interpreted by any program Yes
p Public Key Data The public key as a base64 encoded string. Empty value is equivalent to the public key being revoked and will cause any message signed by the corresponding private key to fail validation No
s The services for which the record applies *: All services. email: Only email. * Yes
t Flags y: Testing mode, receivers shouldn’t treat messages that fail validation and the ones that pass validation. s: Do an exact match when comparing domains, the key applies only to the published domain and not any subdomain of it. Yes