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.