The need for email validated identification arises because forged addresses and content are otherwise easily created—and widely used in
spam,
phishing and other email-based fraud. For example, a fraudster may send a message claiming to be from
sender@example.com, with the goal of convincing the recipient to accept and to read the email—and it is difficult for recipients to establish whether to trust this message. System administrators also have to deal with complaints about malicious emails that appear to have originated from their systems, but did not. DKIM provides the ability to sign a message, and allows the signer (
author organization) to communicate which email it considers legitimate. It does not directly prevent or disclose abusive behavior. DKIM also provides a process for verifying a signed message. Verifying modules typically act on behalf of the
receiver organization, possibly at each
hop. All of this is independent of
Simple Mail Transfer Protocol (SMTP) routing aspects, in that it operates on the RFC 5322 message—the transported mail's header and body—not the SMTP "envelope" defined in RFC 5321. Hence, DKIM signatures survive basic relaying across multiple
message transfer agents.
Technical details Signing The signing organization can be a direct handler of the message, such as the author,
mail submission agent, site, or further intermediary along the transit path, or an indirect handler such as an independent service that is providing assistance to a direct handler. Signing modules insert one or more DKIM-Signature: header fields, possibly on behalf of the
author organization or the originating service provider. The specification allows signers to choose which
header fields they sign, but the From: field must always be signed. The resulting header field consists of a list of tag=value parts as in the example below: DKIM-Signature: v=1; a=rsa-sha256; d=example.net; s=brisbane; c=relaxed/simple; q=dns/txt; i=foo@eng.example.net; t=1117574938; x=1118006938; l=200; h=from:to:subject:date:keywords:keywords; z=From:foo@eng.example.net|To:joe@example.com| Subject:demo=20run|Date:July=205,=202005=203:44:08=20PM=20-0700; bh=MTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTI=; b=dzdVyOfAKCdLXdJOc9G2q8LoXSlEniSbav+yuU4zGeeruD00lszZ VoG4ZHRNiYzR where the tags used are: The most relevant ones are
b for the actual digital signature of the contents (headers and body) of the mail message,
bh for the body hash (optionally limited to the first
l octets of the body),
d for the signing domain, and
s for the selector. An Agent or User Identifier (AUID) can optionally be included. The format is an email address with an optional local-part. The domain must be equal to, or a subdomain of, the signing domain. The semantics of the AUID are intentionally left undefined, and may be used by the signing domain to establish a more fine-grained sphere of responsibility. Both header and body contribute to the signature. First, the message body is hashed, always from the beginning, possibly truncated to a given length
l (which may be zero). Second, selected header fields are hashed, in the order given by
h. Repeated field names are matched from the bottom of the header upward, which is the order in which Received: fields are inserted in the header. A non-existing field matches the empty string, so that adding a field with that name will break the signature. The DKIM-Signature: field of the signature being created, with
bh equal to the computed body hash and
b equal to the empty string, is implicitly added to the second hash, albeit its name must not appear in
h — if it does, it refers to another, preexisting signature. For both hashes, text is canonicalized according to the relevant
c algorithms. The result, after encryption with the signer's
private key and encoding using Base64, is
b. In addition to the list of header fields listed in
h, a list of header fields (including both field name and value) present at the time of signing may be provided in
z. This list need not match the list of headers in
h. Algorithms, fields, and body length are meant to be chosen so as to assure unambiguous message identification while still allowing signatures to survive the unavoidable changes which are going to occur in transit. No end-to-end data integrity is implied. For example, given the example signature above: the
d tag gives the
author domain to be verified against,
example.net ; the
s tag the selector,
brisbane. The string
_domainkey is a fixed part of the specification. This gives the
TXT resource record to be looked up as: brisbane._domainkey.example.net Note that the selector and the domain name can be UTF-8 in internationalized email. In that case the label must be encoded according to
IDNA before lookup. The data returned from the query of this record is also a list of tag-value pairs. It includes the domain's
public key, along with other key usage tokens and flags (e.g. from a command line: ) as in this example: "k=rsa; t=s; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDDmzRmJRQxLEuyYiyMg4suA2Sy MwR5MGHpP9diNT1hRiwUd/mZp1ro7kIDTKS8ttkI6z6eTRW9e9dDOxzSxNuXmume60Cjbu08gOyhPG3 GfWdg7QkdN6kR4V75MFlw624VY35DaXBvnlTJTgRg/EW72O1DiYVThkyCgpSYS8nmEQIDAQAB" The available tags are: or
GNU General Public License v2.0 (and no other version).
Relationship to SPF and DMARC In essence, both DKIM and
SPF provide different measures of email authenticity.
DMARC provides the ability for an organisation to publish a policy that specifies which mechanism (DKIM, SPF, or both) is employed when sending email from that domain; how to check the From: field presented to end users; how the receiver should deal with failures—and a reporting mechanism for actions performed under those policies. == Advantages ==