DomainKeys is a technology proposal that can bring "yes or no" back to the decision process by giving email providers a mechanism for verifying both the domain of each email sender and the integrity of the messages sent (i.e,. that they were not altered during transit). And, once the domain can be verified, it can be compared to the domain used by the sender in the "From" field of the message to detect forgeries. If it's a forgery, then it's spam or fraud, and it can be dropped without impact to the user. If it's not a forgery, then the domain is known, and a persistent reputation profile can be established for that sending domain that can be tied into anti-spam policy systems, shared between service providers, and even exposed to the user.
“DomainKeys schematic” gives a graphical view of how DKIM works.
The domain owner (typically the team running the email systems within a company or service provider) generates a public/private key pair to use for signing all outgoing messages (multiple key pairs are allowed). The policy and the public key is published in DNS, and the private key is made available to their DomainKey-enabled outbound email servers. This is step "A" in the diagram to the right.
When each email is sent by an authorized end-user within the domain, the DomainKey-enabled email system automatically uses the stored private key to generate a digital signature of the message. This signature is then prepended as a header to the email, and the email is sent on to the target recipient's mail server. This is step "B" in the diagram to the right.
The DomainKeys-enabled receiving email system extracts the signature and claimed "From" domain from the email headers and fetches the public key from DNS for the claimed "From" domain. This is step "C" in the diagram to the right.
The public key from DNS is then used by the receiving mail system to verify that the signature was generated by the matching private key. This proves that the email was truly sent by, and with the permission of, the claimed sending "From" domain and that its headers and content were not altered during transfer. It then looks in DNS for the DomainKeys signing policy for the claimed sending domain to assess the result.
The receiving email system applies local policies based on the results of the signature test. If the domain is verified and other anti-spam tests do not catch it, the email can be delivered to the user's inbox. If the signature fails to verify or there is not one, the email can be dropped, flagged, or quarantined. This is step "D" in the diagram on the right.
Enabling DomainKeys signing in Momentum is a two-step process:
Generate public and private keys for each signing domain and create the public key DNS records for those domains.
Configure Momentum to conditionally attach DomainKeys signatures to emails that are submitted into the MTA.
In order to generate RSA keys for the domain
example.com with a selector called
s1024, issue the following openssl commands at the command prompt:
# mkdir -p /opt/msys/ecelerity/etc/conf/dk/example.com # openssl genrsa -out /opt/msys/ecelerity/etc/conf/dk/example.com/s1024.key 1024 # openssl rsa -in /opt/msys/ecelerity/etc/conf/dk/example.com/s1024.key \ -out /opt/msys/ecelerity/etc/conf/dk/example.com/s1024.pub -pubout -outform PEM
The contents of the file
/opt/msys/ecelerity/etc/conf/dk/example.com/s1024.pub should be placed in the DNS TXT record of
The resulting public key should look similar to:
-----BEGIN PUBLIC KEY----- MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDAf1O8E/pDap7nRe1w6hVwsdUC 3BmO/EIE1RCxY92Dk8TwSv7MteLTPfHcasiUDeAboGDjm2U2WfO6AE8detDuKsIN TGt1QY/ng3aTGq0/93OyeUFnux/8o9rQOjZrmVQQICfgWb4VvhdG6j0tjXoVzGOA gYdV9a5DY5fwlbM3DwIDAQAB -----END PUBLIC KEY-----
The DNS text record should be similiar to the record shown below:
s1024._domainkey IN TXT ""g=*; k=rsa; p=MIGf...IDAQAB"
As a signer, you must select a key size that is supported by validation systems on the remote receiving end. Those implementations must choose key sizes of 512, 768, 1024, 1536 or 2048 bits.
The second step of deploying DomainKeys is to specify how you will be using DomainKeys in a public DNS record. This will allow verifiers to process the outcomes of a successful, failed, or missing signature.
The interim sending domain policy is very simple and is expressed in the _domainkey TXT record in the DNS of the sending domain. The contents of this TXT record are stored as tag=value pairs separated by semicolons:
Specifies the granularity of the key. The intent of this tag is to constrain which signing address can legitimately use the selector for this key. The default value for this key is
*. If an empty value (i.e. "g=") is specified, no signing address will be able to use this key.
Used to provide notes to a human inspecting the record. It is not interpreted by a DomainKeys validator. This tag is optional.
Specifies the sending domain's signing policy. A value of
-indicates that this domain signs all email with DomainKeys. A value of
~indicates that this domain may sign some email with DomainKeys.
~is the recommended value at this stage of DomainKeys deployment and adoption.
Specifies an email address to which notification of invalid verification results will be sent. The frequency and content of such emails has yet to be formally defined. This feature is designed for early implementors and testers. This tag is optional and it is recommended that it be omitted.
Used to indicate that a domain is currently testing DomainKeys.
ywill indicate that this domain is in testing mode.
nis not a valid value for the testing tag and this tag should be omitted if DomainKeys is not in testing mode for this domain.
A sample DNS text record would look like:
_domainkey IN TXT "t=y; o=~"