The Complete Guide to Email Authentication, Part 5

This is part 5 of an 8 part series on Email Authentication, to go to part one click here.

DomainKeys

DomainKeys is a domain-level authentication standard that uses public/private key encryption, DNS, and multiple policies to prove the legitimacy and contents of an email message. It verifies the domain used in the “from” or “sender” header. An email message signed with DomainKeys will utilize both a public key record, and a policy record.

Public Key

A public key/private key-pair is created for the sending domain. The private key is stored securely on the mail server, and the public key is stored in the DNS as a TXT record of the domain. Here is an example of a DomainKey text record:

mail._domainkey.example.net. 3600 IN  TXT  "t=y; k=rsa; 
p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBg......U4i3CaMu98nwIDAQAB"

A DomainKey text record will contain a number of “tags” or attributes that give more information about the record. In the above example, the following tags were used:

t = The DomainKey is in test mode

k = Defines the key type. RSA is the default.

p = Public key data, encoded as a Base64 string.

DomainKeys Naming Conventions

As DNS text records are already being used for SPF records, to avoid namespace conflicts the DNS namespace “_domainkey” is prepended to the domain. Additionally, a “selector” is then prepended to “_domainkey”. Selectors allow a sending domain to have more than one public key in DNS, and can be any arbitrary name.

The following are examples of DomainKey records:

mail._domainkey.example.com
marketing._domainkey.example.com
default._domainkey.example.com
nyc.staff._domainkey.example.com
sfo.letters._domainkey.example.com

email authentication guide

DomainKey Message Configuration and Signing

The actual configuration of DomainKeys varies depending on what respective mail system is being used, and is outside the scope of this document. The signing methodology, however, is consistent across all platforms, per how the RFC standard was written.

Consider the following sample email and accompanying DomainKey signature:

DomainKey-Signature: q=dns; a=rsa-sha1; c=nofws;
	s=marketing; d=example.net;
h=Received:Date:From:Reply-to:To:Message-ID:Subject;
b=WHS4P2mFr2k4J+TLrgzjXx3KGQHm...b7EhUUmE0R6Dzvn41e6MrIEM=
Received: from [192.168.1.1]; Fri, 09 Jan 2009 13:52:35 -0800
Date: Fri, 9 Jan 2009 13:52:30 -0800 (PST)
From: Example-Announce 
Reply-to: [email protected]
To: [email protected]
Message-ID: <[email protected]>
Subject: January Announcements

When an email message is signed with DomainKeys, it will include a number of “tags” whose values contain authenticating data for the message being sent. In the example above, the following tags were used:

q = The query method used to retrieve the public key. Currently, the only valid value for this tag is “dns”.

a = The encryption algorithm used to generate the signature. The default value for this tag is “rsa-sha1”.

c = The canonicalization algorithm – or the method by which the headers and content are prepared for presentation to the signing algorithm.

s = The selector used in the public key.

d = The domain name of the signing domain.

h = A colon-separated list of header field names that identify the headers in the email message. The values in this tag MUST contain the complete list of headers in the order presented to the signing algorithm.

b = The signature data or public key, encoded as a Base64 string.

Verifying DomainKeys

There are three primary steps in verifying a DomainKey signed email message:

A receiving mail server extracts the signature information from the headers of the email message, and the public key is fetched from DNS. The public key is matched to private key for validation. All additional tag information is verified.

Once the verification process is complete, the receiving mail server then applies local policies based on the results of the verification, and based on the results can determine whether to deliver the message.

>>Continue on to The Complete Guide to Email Authentication, Part 6