DKIM

Email Domain Authentication

!DomainKeys Identified Mail (DKIM) Signatures allows a signer, not the author as maybe the case with S/MIME or !OpenPGP, (a person or organization) to claim some responsibility for an email. The DKIM signed email proves the domain identity of a signer. It also insures that most or all of it content arrived unaltered if the signature is valid.

DKIM is different from S/MIME or !OpenPGP:

• the message signature is written as a message header field so that neither human recipients nor existing MUA (Mail User Agent) software is confused by signature-related content appearing in the message body;
• there is no dependency on public- and private-key pairs being issued by well-known, trusted certificate authorities;
• there is no dependency on the deployment of any new Internet protocols or services for public-key distribution or revocation;
• signature verification failure does not force rejection of the message;
• no encryption.

DKIM allows delegation of signing to third parties. DKIM stores its public key in DNS TXT RR for the domain:

 _domainkey.<domain> IN TXT "<tag;tag;...>"

• “v=1” - Version of DKIM
• “h=sha1:sha256” - Colon-separated acceptable hash algorithms
• “k=rsa” - Signing key type
• “n=” - optional notes
• “p=” - public key in Base64 format
• “s=email:*” - colon-separated service types
• “t=” - Colon-separated flags: “y” for testing DKIM, “s” - for subdomain: any DKIM-Signature header fields using the “i=” tag MUST have the same domain value on the right-hand side of the “@” in the “i=” tag and the value of the “d=” tag. That is, the “i=” domain MUST NOT be a subdomain of “d=”. Use of this flag is RECOMMENDED unless subdomaining is required.

The message must be signed! “From” and “DKIM-Signature” headers must be signed (the later one must not be included in the “h=” tag) and “Return-Path” should not be signed as it is likely to be modified in transit. It is allowed to sign non-existing headers to assure that they will not appear later in transit. Because same multiple headers are allowed, listing a header more than the actual number of headers in “h=” tag protects from same header further additions.

DKIM uses sha1 and sha256 for hashing and rsa algorithm for encrypting the hashes, essentially creating a signature. The key length must be between 512 and 2048.

Because an email headers (or even body) might be changed in transit and because there are different tolerance to such changes in organizations, two message canonicalization algorithms exist:

1. “simple” - tolerates almost no modifications. No included in hashing function header changes are allowed! As for the body, it converts “*CRLF” at the end of the body to a single “CRLF”.
2. “relaxed” - tolerates common modifications such as whitespace replacement and header field line rewrapping.

Either algorithm may be specified separately for headers and for a body. For more details on canonicalization algorithms, see RFC 6376.

The algorithms used are written to tag “c=” separated by “/”. The first algorithm is for headers, the second - for a body. To prevent “ASCII Art” attack on a message, use “simple” algorithm for a body. Also “l=” tag that is used for body length limits may be abused to deliver a fraudulent content, so its usage is discouraged.

DKIM signature is stored in DKIM-Signature Header. For the format of the header, see RFC 6376. Parameters to the DNS key lookup are the DNS RR type (the “q=txt” tag), the domain of the Signer (the “d=” tag of the DKIM-Signature header field) and the selector (the “s=” tag).

The Authentication-Results header field may be used for signature verification outcome. It is reasonable to treat unauthenticated email as lacking any trust and having no positive reputation.

In general, modules that consume DKIM verification output SHOULD NOT determine message acceptability based solely on a lack of any signature or on an unverifiable signature, especially if there is a tag “t=y” that means “testing DKIM”. If an MTA does wish to reject such messages during an SMTP session (for example, when communicating with a peer who, by some prior agreement, agrees to only send signed messages), and a signature is missing or does not verify, the handling MTA SHOULD use a 550/5.7.x reply code.

Where the Verifier is integrated within the MTA and it is not possible to fetch the public key, perhaps because the key server is not available, a temporary failure message MAY be generated using a 451/4.7.5 reply code, such as:

 451 4.7.5 Unable to verify signature - key server unavailable