DomainKeys Identified Mail (DKIM)

Overview
DomainKeys Identified Mail (DKIM) lets an organization take responsibility for a message while it is in transit. The organization is a handler of the message, either as its originator or as an intermediary. Their reputation is the basis for evaluating whether to trust the message for delivery. Technically DKIM provides a method for validating a domain name identity that is associated with a message through cryptographic authentication.

What is the purpose of DKIM?
DKIM allows an organization to take responsibility for transmitting a message, in a way that can be verified by a recipient. The organization can be the author's, the originating sending site, an intermediary, or one of their agents. Their reputation is the basis for evaluating whether to trust the message for delivery. 

 
What does DKIM Do?
The responsible organization adds a digital signature to the message, associating it with a domain name of that organization.  Typically, signing will be done by an service agent within the authority of the message originator's Administrative Management Domain (ADMD). Signing might be performed by any of the functional components, in that environment, including: Mail User Agent (MUA), or Mail Submission Agent (MSA), Internet Boundary MTA. DKIM permits signing to be performed by authorized third-parties.

Who validates the signature?
After a message has been signed, any agent in the message transit path can choose to validate the signature. Typically, validation will be done by an agent in the ADMD of the message recipient. Again, this may be done by any functional component within that environment. Notably this means that the signature can be used by the recipient ADMD's filtering software, rather than requiring the recipient end-user to make an assessment. 

What does the DKIM signature mean?
The owner of the domain name being used for a DKIM signature is declaring that they are accountable for the message. This means that their reputation is at stake.

Receivers who successfully validate a signature can use information about the signer as part of a program to limit spam, spoofing, phishing, or other undesirable behavior, although the DKIM specification itself does not prescribe any specific actions by the recipient.

 

Will using DKIM imporve deliverability?
Whether this improves deliverability or bypasses filters is entirely at the discretion of the validating receivers. When a message has been signed using DKIM, a receiver uses their knowledge about the signer to determine the most appropriate treatment of the message. It is expected that messages from a signer who has a good reputation will be subject to less scrutiny by the receiver's filters. 

 Implementation Details: 
Upon request, DNN4Less will generate and implement DKIM Signatures for Domains owned by the customer.
Signatures will have the following attributes:

• Signing Algorithm: RSA-SHA256
• Key Size: 1024
• Selector: UE(YEAR)(MONTH)

Once the DKIM Signature has been generated, the customer will receive a text file containing the Public Key Record.

It is the customer's responsibilty to have their Domains DNS updated with (2) TXT entries: Policy Record & Public Key Record

 

Example DKIM TXT Entries:

 

1. _domainkey.(YourDomain). IN TXT "o=~; r=postmaster@(YourDomain)"
2. (Selector)._domainkey.(YourDomain). IN TXT "v=DKIM1; p=MIGfMA0GCSqGSIb4DQ(.....)z2nJSPOxvGGznkcY25w5lIYpxpVwZ/IwIDAQAB;"

DKIM Policy Record:
A domain name using DomainKeys should have a single policy record configured. 
This is a DNS TXT-record with the name "_domainkey" prefixed to the domain name - for example "_domainkey.yourdomain.com". 
The data of this TXT-record contains the policy which is basically either "o=-" or "o=~".

 

• o=- 
  Means "all e-mails from this domain are signed"
• o=~ 
  Means "some e-mails from this domain are signed". 
• t=
  Means "Test" 
• r=postmaster@(YourDomain.com)
  Responsible e-mail address 
• n=
  Allows you specify a note.

DKIM Public Key Record (Domain Signature Record):
DKIM uses a simple "tag=value" syntax in several contexts, including in messages and domain signature records.

 

Values are a series of strings containing either plain text, base64 text (as defined in [RFC2045], Section 6.8), qp-section (ibid, Section 6.7), or dkim-quoted-printable (as defined in Section 2.6). The name of the tag will determine the encoding of each value. Unencoded semicolon (";") characters MUST NOT occur in the tag value, since that separates tag-specs.

 

• v=
  Version of the DKIM key record (plain-text; RECOMMENDED, default is "DKIM1"). If specified, this tag MUST be set to "DKIM1" (without the quotes). This tag MUST be the first tag in the record. Records beginning with a "v=" tag with any other value MUST be discarded. Note that verifiers must do a string comparison on this value; for example, "DKIM1" is not the same as "DKIM1.0".Version (MUST be included). This tag defines the version of this specification that applies to the signature record.
  
• g=
  Granularity of the key (plain-text; OPTIONAL, default is "*"). This value MUST match the Local-part of the "i=" tag of the DKIM-Signature header field (or its default value of the empty string if "i=" is not specified), with a single, optional "*" character matching a sequence of zero or more arbitrary characters ("wildcarding"). An email with a signing address that does not match the value of this tag constitutes a failed verification. The intent of this tag is to constrain which signing address can legitimately use this selector, for example, when delegating a key to a third party that should only be used for special purposes. Wildcarding allows matching for addresses such as "user+*" or "*-offer". An empty "g=" value never matches any addresses.
• h=
  Acceptable hash algorithms (plain-text; OPTIONAL, defaults to allowing all algorithms). A colon-separated list of hash algorithms that might be used. Signers and Verifiers MUST support the "sha256" hash algorithm. Verifiers MUST also support the "sha1" hash algorithm.
• k=
  Key type (plain-text; OPTIONAL, default is "rsa"). Signers and verifiers MUST support the "rsa" key type. The "rsa" key type indicates that an ASN.1 DER-encoded [ITU.X660.1997] RSAPublicKey[RFC3447] (see Sections 3.1 and A.1.1) is being used in the "p=" tag. (Note: the "p=" tag further encodes the value using the base64 algorithm.)
• n=
  Notes that might be of interest to a human (qp-section; OPTIONAL, default is empty). No interpretation is made by any program. This tag should be used sparingly in any key server mechanism that has space limitations (notably DNS). This is intended for use by administrators, not end users.
• p=
  Public-key data (base64; REQUIRED). An empty value means that this public key has been revoked. The syntax and semantics of this tag value before being encoded in base64 are defined by the "k=" tag.
  
• s=
  Service Type (plain-text; OPTIONAL; default is "*"). A colon-separated list of service types to which this record applies. Verifiers for a given service type MUST ignore this record if the appropriate type is not listed.
• t=
  Flags, represented as a colon-separated list of names (plain-text; OPTIONAL, default is no flags set). The defined flags are as follows:
  • y 
    This domain is testing DKIM. Verifiers MUST NOT treat messages from signers in testing mode differently from unsigned email, even should the signature fail to verify. Verifiers MAY wish to track testing mode results to assist the signer.
  • s
    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.