DomainKeys Identified Mail (DKIM) Development, Deployment, and Operations
DomainKeys Identified Mail (DKIM) allows an organization to claim responsibility for transmitting a message, in a way that can be validated by a recipient. The organization can be the author's, the originating sending site, an intermediary, or one of their agents. A message can contain multiple signatures, from the same or different organizations involved with the message. DKIM defines a domain-level digital signature authentication framework for email, using public key cryptography and using the domain name servic
Informational, not a standard. Published for the record and carrying no standards weight. Worth knowing before citing it as a requirement.
What it is
Deployment guidance for DKIM: key management, selector strategy, and what to sign.
What it solves
The protocol specification says how to sign. It does not say how to run signing as an ongoing operation.
What it means to operate
The rotation advice is the useful part. Use a dated selector, keep the previous key published until the last message signed with it has aged out, and remember that removing a selector retroactively invalidates every message it signed.
Domain check resolves the selectors a domain actually publishes, which is the deployment step this document is about. Open domain check
Normative requirements
Every sentence in this RFC carrying an RFC 2119 keyword, with the section it came from.
2.2 Choosing a DKIM Tag for the Assessment Identifier
- MAYDKIM MAY optionally provide a single responsible Agent or User Identifier (AUID)...
- MUSTA receive-side DKIM verifier MUST communicate the Signing Domain Identifier (d=) to a consuming Identity Assessor module and MAY communicate the User Agent Identifier (i=) if present....