DomainKeys Identified Mail (DKIM)

DomainKeys Identified Mail attaches a DKIM-Signature header to outgoing mail. The sending server hashes the message, always covering the From: header and the body, signs that digest with a private key that never leaves the system, and names the signing domain in the signature’s d= tag. The matching public key is published in DNS under a label called a selector, so any receiver can fetch it and recompute the digest without prior arrangement. There is no certificate authority, which is the main way DKIM differs from the model behind TLS and PKI. Selectors are also what make safe key rotation possible, and what let a third party sign on a domain’s behalf.

The boundaries are where questions live. DKIM provides integrity and domain authentication, and no confidentiality at all: it signs, it does not encrypt, and the message travels in the clear. It authenticates a domain rather than a person, so it does not deliver the nonrepudiation an individual’s digital signature does. And a valid signature says nothing about the visible sender, because an attacker can publish keys for a domain they genuinely own and sign a forgery perfectly.

Exam relevance: if a scenario asks for confidentiality of message content, DKIM is the distractor and TLS, S/MIME or PGP is the answer. If it describes authentication surviving a forward, DKIM is the mechanism, because the signature travels with the message rather than depending on the path. A list that rewrites the subject or appends a footer does break it, which is what Authenticated Received Chain (RFC 8617) addresses.