As you can read here "....A selector is added to the domain name, used to find DKIM public key information...".
Also, in Wikipedia terms: "...The receiving SMTP server uses the domain name and the selector to perform a DNS lookup [...] the selector is a straightforward method to allow signers to add and remove keys whenever they wish..."
In other words, if you are sending a DKIM-signed e-mail, you have to tell external mail-servers HOW they can retrieve your RSA key to check the validity of your email. The RSA-key is published into your DNS, ok, but WHERE? Which DNS-query will retrieve it? How will they know which DNS query/record resolve? This is where the selector plays its role: if you are sending mail from the
example.com domain and, in your mail, you declare
whatever as selector then:
- in the outgoing mail-header you need to reference your domain and related selector, like in:
DKIM-Signature [...] d=example.com; [...] s=whatever
- in your DNS you have to provide a
TXT record for
whatever._domainkey.example.com publishing your RSA key, like in:
whatever._domainkey.example.com IN TXT "k=rsa\; t=s\; p=MIGfMA[...]AQAB"
As you can see, the DNS-query is in the form <selector>._domainkey.<your_domain>
Based on this, we can say that:
the RSA-key can be replaced/updated without any impact on the selector. Obviously it's critical that, when you update one side of the key (the public one, published on the DNS), you change also the other side (the one used to "sign" your outgoing mail);
if you leave the selector unchanged while updating the RSA-key, than a side effect is that.... remote clients (not servers; I'm talking about MUAs) that for whatever reasons want to check the DKIM-signature included in their old/archived e-mails, will fail the verification process (as the archived e-mail has been signed with a private-key whose public-one, the one published on the DNS, has been updated and now is different!).
I want to add that, in my experience, I'm used to think that DKIM-signing/verification is a process targeting the transport of the e-mail, and not the verification client-side. So I would bet that it's quite safe to update the KEYs leaving the selector untouched.
By I also think that.... if you're going to update the KEYs, than you've to change both your signing-code (that need to point to new private-key) and the DNS (to publish the new public-key in the TXT record). So, why not to change also the selector (again, at both side?). You will end up having TWO selectors published on the DNS, one pointing to the old-key and another one pointing to the new one. In this way, everything will be fine during SMTP-transport and, also, MUAs will be able to validate old/archived e-mails as the old-key, associated to old selector, is still available.