Skip to main content

1. Introduction

DomainKeys Identified Mail (DKIM) permits a person, role, or organization to claim some responsibility for a message by associating a domain name [RFC1034] with the message [RFC5322], which they are authorized to use. This can be an author's organization, an operational relay, or one of their agents. Assertion of responsibility is validated through a cryptographic signature and by querying the Signer's domain directly to retrieve the appropriate public key. Message transit from author to recipient is through relays that typically make no substantive change to the message content and thus preserve the DKIM signature. A message can contain multiple signatures, from the same or different organizations involved with the message.

The approach taken by DKIM differs from previous approaches to message signing (e.g., Secure/Multipurpose Internet Mail Extensions (S/MIME) [RFC5751], OpenPGP [RFC4880]) in that:

  • the message signature is written as a message header field so that neither human recipients nor existing MUA (Mail User Agent) software is confused by signature-related content appearing in the message body;

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

  • no attempt is made to include encryption as part of the mechanism; and

  • message archiving is not a design goal.

DKIM:

  • is compatible with the existing email infrastructure and transparent to the fullest extent possible;

  • requires minimal new infrastructure;

  • can be implemented independently of clients in order to reduce deployment time;

  • can be deployed incrementally; and

  • allows delegation of signing to third parties.

1.1. DKIM Architecture Documents​

Readers are advised to be familiar with the material in [RFC4686], [RFC5585], and [RFC5863], which provide the background for the development of DKIM, an overview of the service, and deployment and operations guidance and advice, respectively.

1.2. Signing Identity​

DKIM separates the question of the identity of the Signer of the message from the purported author of the message. In particular, a signature includes the identity of the Signer. Verifiers can use the signing information to decide how they want to process the message. The signing identity is included as part of the signature header field.

INFORMATIVE RATIONALE: The signing identity specified by a DKIM signature is not required to match an address in any particular header field because of the broad methods of interpretation by recipient mail systems, including MUAs.

1.3. Scalability​

DKIM is designed to support the extreme scalability requirements that characterize the email identification problem. There are many millions of domains and a much larger number of individual addresses. DKIM seeks to preserve the positive aspects of the current email infrastructure, such as the ability for anyone to communicate with anyone else without introduction.

1.4. Simple Key Management​

DKIM differs from traditional hierarchical public-key systems in that no certificate authority infrastructure is required; the Verifier requests the public key from a repository in the domain of the claimed Signer directly rather than from a third party.

The DNS is proposed as the initial mechanism for the public keys. Thus, DKIM currently depends on DNS administration and the security of the DNS system. DKIM is designed to be extensible to other key fetching services as they become available.

1.5. Data Integrity​

A DKIM signature associates the "d=" name with the computed hash of some or all of the message (see Section 3.7) in order to prevent the reuse of the signature with different messages. Verifying the signature asserts that the hashed content has not changed since it was signed and asserts nothing else about "protecting" the end-to-end integrity of the message.

Last updated on