An email service provider is one of the more complex situations in which to deploy DKIM Core, for a number of reasons. The goal of this set of deployment suggestions is to reduce to a minimum the effort needed to bring on a new customer, especially any work that needs to be performed by the customers IT group, and to eliminate any ongoing work by the customer. Also, there’s a need to use not only a customer-specific token to tie reputation to the customer, but possibly also an ESP-specific token to easily allow DKIM based feedback loops to be setup by the ESP. To further complicate matters some customers will want to be able to use multiple ESPs simultaneously, so configuring DKIM Core for use with one ESP must not prevent them from using other ESPs (or using DKIM Core for the mail they send themselves).
One approach that achieves all of these goals is as follows, using as examples an ESP called myesp.com and a customer called customer.com.
Choose an identifier that you will use as part of the selector for all your customers, based on your company name, for example “myesp”.
Set up two new nameservers dedicated to serving DNS for DKIM keys for your customers, dkim1.myesp.com and dkim2.myesp.com. These needn’t be dedicated servers, but keeping them separate to your main nameservers and giving them dedicated hostnames is a good idea. Initially these will be standard nameservers (powerdns, bind, tinydns, whatever technology your IT group are familiar with) but they could potentially be replaced by special nameservers that synthesize responses based on queries to simplify customer deployment in the future.
Tell each customer to have their IT group delegate a subdomain of their domain to you. Specifically, delegate myesp._domainkey.customer.com to your dkim nameservers:
myesp._domainkey.customer.com. IN NS 86400 dkim1.myesp.com. myesp._domainkey.customer.com. IN NS 86400 dkim2.myesp.com.
The reason for delegating myesp._domainkey.customer.com instead of _domainkey.customer.com is to allow the customer to use multiple ESPs, or to easily send DKIM Core mail themselves.
For each new customer create a new key pair and a selector that is the current month and the selector identifier you chose, e.g. feb2009.myesp. Put the public key as described in the previous section, in your dkim nameservers. See sections 1 and 2 of the specification for the details of how to do that.
Sign outbound email for that customer using feb2009.myesp as the selector and customer.com as the signing domain, and the private key you generated for that customer. If you're using a DKIM signing engine with no DKIM Core configuration see here for configuration details.
If you want to take advantage of DKIM-based feedback loops without the overhead of creating a new feedback loop for each new customer then also sign each outbound email with a second signature using a domain owned by you. For example, use a selector such as feb2009.myesp and a token of fbl.myesp.com. This allows you to set up one feedback loop with each ISP offering such a thing based on the token fbl.myesp.com and never have to modify it.
If you need to update the key pairs used to sign mail, either because they may have been compromised or because you just want to update them regularly you can do that fairly easily. Create a new key pair and a new selector for each customer, e.g. mar2009.myesp, and publish the new public key in your dkim nameservers. Start sending email using those keys. After a few days, when you’re sure all the mail sent with the old key has been delivered, simply remove the old keys from the dkim nameservers.
There are some obvious variants on this. If the customer is incapable of delegating a domain to you then you can register a new domain on their behalf, pointed directly at your dkim nameservers and use that. For customers who don’t have a domain of their own you can do the same thing, or simply not use a customer-specific signature at all. And if there is a need to add additional tokens (to support a third-party service, perhaps) they can be added independently either before or after the process described above.
Customers who have their own domain, who don’t believe they're able to delegate a subdomain to the ESP, but who would like to use their own domain as a DKIM Core token are yet another complication. One option is to decline to support this. Another option would be to register a domain for them, or use a subdomain, but have them setup CNAME records in their DNS for their domain pointing at the appropriate records in that domain. For example:
feb2009.myesp._domainkey.customer.com. IN CNAME 86400 feb2009.myesp.customer.com.dkimhack.myesp.com mar2009.myesp._domainkey.customer.com. IN CNAME 86400 mar2009.myesp.customer.com.dkimhack.myesp.com apr2009.myesp._domainkey.customer.com. IN CNAME 86400 apr2009.myesp.customer.com.dkimhack.myesp.com
and so on.
Rather than using a series of CNAME records, you can instead use just two - "ping" and "pong", perhaps or "dkim1" and "dkim2". Then each time you need to rotate keys you switch to the one you're not currently using. Adding a third CNAME might make rotations in case of a compromised key simpler.
This is probably the simplest approach for ESP customers to deploy.
A final option which may be requested by sophisticated customers, but which is likely to be operationally expensive to support, is to have the customer handle all the key generation and DNS needed, and simply provide the ESP with a token, selector and private key to sign outgoing email with.