DomainKeys Identified Mail (DKIM) Signatures
obsoleted by
- rfc-6376 — DomainKeys Identified Mail (DKIM) Signatures
obsoletes
- rfc-4870 — Domain-Based Email Authentication Using Public Keys Advertised in the DNS (DomainKeys)
updated by
- rfc-5672 — RFC 4871 DomainKeys Identified Mail (DKIM) Signatures -- Update
Extracted elements (30)
DKIM omits a Certificate Authority infrastructure entirely; verifiers query the purported signer's DNS entry directly to retrieve the public key. This trades some assurance for dramatically enhanced scalability, since there are over 70 million domains.
Signers may include header field names in h= that do not exist in the message; this explicitly asserts the absence of those fields so that any later insertion of them will break the signature. Non-existing header fields are treated as the null string in the hash computation.
The signing identity (i= tag) is intentionally not required to match any message header field address, because recipient mail systems apply broad and varied interpretations. This separates cryptographic signer identity from the purported author identity.
Two canonicalization algorithms (simple and relaxed) exist because different signers have different tolerances for in-transit modification. Relaxed tolerates whitespace normalization and header line rewrapping common among mail relays; simple requires byte-for-byte fidelity.
The DKIM-Signature header SHOULD be treated as a trace header field (prepended, not reordered). Signing existing DKIM-Signature header fields is error-prone because some intermediate MTAs may reorder them, breaking those signatures.
When messages will be transmitted with base64 or quoted-printable content transfer encoding, signers MUST compute hashes after encoding and verifiers MUST incorporate values before decoding. Hashes MUST be computed before SMTP dot-stuffing is applied.
All control characters, 8-bit characters, DEL, SPACE, and semicolon MUST be encoded in DKIM-Quoted-Printable as '=' followed by two uppercase hexadecimal digits. All whitespace including CR and LF MUST be encoded.
Bare CR or LF characters MUST be converted to CRLF before signing. All modifications to canonical RFC 2822 form MUST be done before signing; the signer MUST sign the message as it is expected to be received by the verifier.
If the key record t= flag contains 's', the domain of the i= signing identity MUST be exactly equal to the d= domain (subdomain signing is prohibited). Key records not intended for subdomain use SHOULD specify this flag.
Signers MUST use RSA keys of at least 1024 bits for long-lived keys. Verifiers MUST be able to validate signatures with keys ranging from 512 bits to 2048 bits, and MAY validate larger keys.
Tags with duplicate names MUST NOT occur within a single tag-list; if a tag name occurs more than once, the entire tag-list is invalid. Unrecognized tags MUST be ignored.
The d= domain MUST be the same as or a parent domain of the i= signing identity, or meet the requirements for parent domain signing in Section 3.8. Verifiers MUST consider any signature failing this requirement invalid.
The From header field MUST be included in the h= tag of the DKIM-Signature. It is the only header field that is unconditionally required to be signed.
The signer/verifier MUST compute two hashes: one over the canonicalized body (stored in bh=) and one over the selected canonicalized header fields plus the DKIM-Signature header with the b= value treated as the empty string.
The v= tag MUST be included in every DKIM-Signature and MUST have the value '1'. Verifiers must do a string comparison; '1' is not the same as '1.0'.
Verifiers MUST implement both rsa-sha1 and rsa-sha256 signing algorithms. Signers MUST implement rsa-sha256 and SHOULD sign using rsa-sha256.
Verifiers MUST implement both 'simple' and 'relaxed' canonicalization algorithms for header and body. If no canonicalization algorithm is specified by the signer, 'simple' is the default for both header and body.
Verifiers SHOULD evaluate multiple signatures independently and on their own merits. Verifiers SHOULD ignore failed signatures as though not present and continue checking until one successfully verifies. Verifiers MAY limit total signatures attempted to prevent denial-of-service.
When signing a header field that occurs more than once, signers MUST sign the physically last instance. To sign multiple instances, the field name MUST appear multiple times in h= and MUST be signed from the bottom of the header block to the top.
Key revocation is signaled by setting the p= tag in the DNS key record to an empty string. Verifiers should ignore any DKIM-Signature header fields referencing a revoked key. There is no defined semantic difference between a revoked key and a removed key record.
Selectors subdivide the key namespace within a signing domain to support multiple concurrent public keys. Given d=example.com and s=foo.bar, the DNS lookup is for foo.bar._domainkey.example.com. Periods in selectors create DNS label boundaries.
The DKIM-Signature header field stores all signature and key-fetching data as a tag=value list. Required tags are v= (version '1'), a= (algorithm), b= (RSA signature, base64), bh= (body hash, base64), d= (signing domain), h= (signed header field list), and s= (selector).
RFC 4871 creates seven new IANA registries: DKIM-Signature Tag Specifications, DKIM-Signature Query Method Registry, DKIM-Signature Canonicalization Registry, _domainkey DNS TXT Record Tag Specifications, DKIM Key Type Registry, DKIM Hash Algorithms Registry, DKIM Service Types Registry, and DKIM Selector Flags Registry.
DKIM relies on DNS for public key distribution, making it vulnerable to DNS cache poisoning, spoofing, and denial-of-service attacks against key servers. Intentionally malformed key records or DKIM-Signature header fields must be handled gracefully by implementations.
DKIM signatures are susceptible to replay attacks in which a validly signed message is retransmitted to a larger or unintended audience. The x= expiration tag is not an anti-replay defense; mitigations are outside DKIM's scope.
If a private key is misappropriated, an attacker can sign arbitrary messages as if they were from the legitimate domain. Revocation by setting p= to empty limits exposure, but there is an unavoidable window between compromise and revocation propagation.
Parent domain signing allows a key at example.com to sign messages with i=sub.example.com unless the 's' flag is set in the key record. Domains should set the 's' flag unless subdomain delegation is explicitly intended, to prevent inappropriate signing by parent domains.
The l= body length tag enables an attack where an attacker appends content that can completely replace the original content in the recipient's view and defeat duplicate-message detection. Signers should be extremely wary of using l=; verifiers may choose to ignore it.
DKIM-Signature optional tags include c= (canonicalization pair, e.g., 'relaxed/simple', default 'simple/simple'), i= (signing identity as email address with optional Local-part), l= (body length count in decimal octets), t= (Unix timestamp), x= (expiration timestamp), q= (query method list, default 'dns/txt'), and z= (copied header fields for diagnostics).
The DNS key record at selector._domainkey.domain uses a tag=value format. Key tags include v= ('DKIM1', must be first), p= (base64 public key; empty means revoked), k= (key type, default 'rsa'), h= (acceptable hash algorithms), g= (Local-part granularity with wildcard), s= (service type), and t= (flags: 'y' for testing mode, 's' for strict domain match).