RFC 4871 DomainKeys Identified Mail (DKIM) Signatures -- Update
obsoleted by
- rfc-6376 — DomainKeys Identified Mail (DKIM) Signatures
updates
- rfc-4871 — DomainKeys Identified Mail (DKIM) Signatures
Extracted elements (18)
DKIM's primary task is to communicate a single SDID to a recipient-side Identity Assessor. The SDID is the mandatory output; the AUID is optional. Any attempt by a receiver to intuit structured semantics from either identifier is a heuristic function outside the scope of DKIM's specification.
RFC 4871 defined two identifiers in the DKIM-Signature header (d= and i=) without clearly specifying which is the mandatory payload delivered to a receiving assessor module, creating potential interoperability problems where signers and assessors might disagree on which identifier to use for trust assessment. This Update resolves the ambiguity by designating d= (the SDID) as the single mandatory output.
The AUID has email-address syntax but not necessarily email-address semantics: its domain need not be registered in DNS and its Local-part may be drawn from a namespace unrelated to user mailboxes. The details of AUID namespace structure are determined by the Signer and are outside the scope of the DKIM specification.
The DKIM specification does not require the SDID or AUID to match identifiers in other message header fields (e.g., From:); such linkage is an assessor policy issue. The real-world efficacy of bindings between SDID/AUID and other identities is not well established, and reliance on such bindings should be strictly limited.
This entire document constitutes an update to RFC 4871 in the style of an errata entry, correcting and clarifying the Abstract, Introduction, and multiple sections (2.7–2.11, 3.5, 3.8, 3.9, 6.3, Appendix D) to consistently use the new defined terms SDID, AUID, and Identity Assessor in place of ambiguous prior phrasing.
For signers and verifiers that had been using the i= tag as the primary value delivered to the assessor, this Update requires a software change to use the d= tag instead. The standardized minimum output of a DKIM-compliant library is the verification yes/no result and the d= value.
A receive-side DKIM verifier MUST communicate the Signing Domain Identifier (d=) to a consuming Identity Assessor module and MAY communicate the Agent or User Identifier (i=) if present.
A signer SHOULD use the same AUID for each message intended to be evaluated as being within the same sphere of responsibility, in order to offer receivers the option of using the AUID as a stable, finer-grained identifier than the SDID.
If the key record contains the "s" flag in the t= tag, the domain of the AUID (i= tag) MUST be the same as that of the SDID (d= domain). If the flag is absent, the domain of the AUID MUST be the same as, or a subdomain of, the SDID.
Once the signature has been verified, that information MUST be conveyed to the Identity Assessor (such as an explicit allow/whitelist and reputation system) and/or to the end user. If the SDID is not the same as the address in the From: header field, the mail system SHOULD take pains to ensure that the actual SDID is clear to the reader.
The d= tag specifies the SDID claiming responsibility for introducing a message into the mail stream, and the SDID MUST correspond to a valid DNS name under which the DKIM key record is published. When presented with a signature that does not meet these requirements, verifiers MUST consider the signature invalid.
The domain part of the i= tag (AUID) MUST be the same as, or a subdomain of, the value of the d= tag (SDID). Internationalized domain names MUST be converted using the ToASCII function per RFC 3490.
The Agent or User Identifier (AUID) is a single identifier, comprising a domain name and optional Local-part, that refers to the agent or user on behalf of whom the SDID has taken responsibility. The domain name must equal or be a subdomain of the SDID, and it is specified via the i= tag.
The Identity Assessor is a module that consumes DKIM's mandatory payload (the SDID). It is dedicated to assessment of the delivered identifier; other DKIM and non-DKIM values may also be delivered to it, but such additional activity is outside the scope of the DKIM signature specification.
The Signing Domain Identifier (SDID) is a single domain name that is the mandatory payload output of DKIM, referring to the identity claiming responsibility for introduction of a message into the mail stream. It is specified via the d= tag in the DKIM-Signature header field.
This Update clarifies core details about DKIM's payload, affecting interoperability, semantic characterization, and expectations for identifiers carried with a DKIM signature. Clarification is likely to limit misinterpretation of DKIM's semantics and thereby improve DKIM's security characteristics, since DKIM is fundamentally a security protocol.
The d= tag ABNF is: sig-d-tag = %x64 [FWS] "=" [FWS] domain-name; domain-name = sub-domain 1*(".") sub-domain, derived from RFC 5321 Domain but excluding address-literal. This corrects the earlier reference to RFC 2821.
The i= tag ABNF is: sig-i-tag = %x69 [FWS] "=" [FWS] [ Local-part ] "@" domain-name. The Local-part is optional; when omitted, the AUID defaults to an empty Local-part followed by "@" and the d= domain.