One of the critical path steps in deploying DomainKeys is to determine how you will ensure your public keys will be published in your _domainkey DNS TXT records. For many companies the email administrator does not administer the DNS records. Thus, to use DomainKeys, the email administrator and DNS administrator must work together to ensure the public keys used by the email servers have been published into the DNS records. There are two general strategies to achieve this:

• The email administrator creates a zone transfer that the DNS administrator regularly imports
• The email administrator name serves the _domainkey subdomain

Companies that outsource all or part of their email infrastructure have additional options. They must determine if they should limit the scope of their provider's signing ability and have a few additional options in setting up the DNS service.

The most general key distribution mechanism is for the email administrator to generate the _domainkey records to give to the DNS administrator. This can be done in numerous ways. One option is to set up an internal AXFR server and have the DNS administrator slave their masters to them for the _domainkey zone.

As the email administrator generates and changes keys on the outbound signing MTAs, they would also generate and change the zone on the AXFR machine, and thus have the main DNS machines pick it up automatically. With this implementation the email admin's AXFR machine is invisible to the rest of the Internet and only needs to deal with the occasional AXFR request.

This option is probably most useful to companies that run all their email services internally.

Another option is to delegate the _domainkey subdomain name serving to a DNS server operated by the email administrator. When an outside domain queries the _domainkey subdomain, the main name servers returns the email administrator's name servers. The email administrator's name server would likely answer the final query, though it may delegate certain subdomain queries to yet another name server (see below). As the email administrator generates and changes keys on the outbound signing MTAs, they would also generate and change the zone on the name serving machine.

This option may be particularly useful for companies that completely outsource their email services. The company could delegate their _domainkey subdomain name servers as a one time DNS record update, then have the outsourced email service manage new key proprogation and management.

Yet another option is to name serve a subdomain to the _domainkey subdomain. The draft-delany-domainkeys-base-01 spec allows a domain to choose selectors that include "."s in them, effectively allowing a subselector. For instance, the domain example.net could create a subdomain to their _domainkey subdomain called sydney (sydney._domainkey.example.net). Yet another sudomain provides the final piece to the selector used in the email. The DNS record "main.sydney._domainkey.example.net" would have the DomainKey selector "main.sydney."

This allows a domain to to delegate only part of their selector space instead of all of the selector space. If example.net wished to hire a third party to send email on its behalf, they could delegate the name serving of the sydney._domainkey.example.net to that third party. The third party could then easily deploy and retire keys and selectors as necessary without affecting other example.net email or DNS operations.

$dig sydney._domainkey.example.net NS

; AUTHORITY SECTION:
sydney._domainkey.example.net. 12m2s IN NS dns-01.ns.example.com

One downside of this approach is that the organization that name serves the subdomain selector is technologically equivalent to the domain administrator. The name serving organization can create as many keys as they desire and are not technically constrained to using more granular keys than the domain (that is, the "g" tag can be null). This concern could be addressed by giving the third party a subdomain to use for their email addresses, for instance, email.example.net.

This option is probably most useful to companies that use a combination of outsourced and internal email services. It allows third parties to manage and propogate keys without requiring much or ongoing change in the company's DNS records.

Over time, the email administrator may wish to retire a DomainKey and begin using a new one or change outsourcing providers. Administrators may feel that the risk of a key being broken is too great or has decided to make a change in their outsourcing.

Before removing a key from DNS, a new key should be put into the DNS records and the outbound MTA should begin using it. After all MTAs have stopped using the key to be retired for at least five days (preferably 14), the key record can be removed from the DNS records entirely. Similarly, when changing delegated name servers, the new name server should contain the all the DomainKeys that were used in the previous five days (preferably 14 days). By continuing to publish these DomainKeys, email that is still in transit may be verified.