Rotating the DKIM key

A DKIM key has no expiry date, and a 2048 bit RSA key does not weaken by getting old, so this is not something you have to think about often. When a key does change, whether we start it on a schedule or you start it yourself, sending is never interrupted: the new key is prepared and waited on before anything switches to it, and the old one keeps signing until then.

What it asks of you depends on how your DKIM is published.

If your DKIM is delegated to C-Connect (the default)

Nothing. You published two CNAMEs once, when you added the domain, and the key behind them changes on our side without touching your DNS again. We rotate a delegated key on our own, about once a year, and nothing shows up for you to do: the CNAMEs already point at both places a key of yours will ever live.

You can also start one yourself, from the domain page, if you have a reason to. We prepare the new key at the name your second CNAME already points to, wait for it to be reachable, and only then switch to it. Sending continues on the current key the entire time.

The one exception is a domain that sends only through our fallback relay. Rotating it means asking Amazon to re-verify the new key, which takes hours, and there is no way to do that without a window in which the fallback cannot be used for this domain. We rotate those by hand instead of on the yearly schedule, and starting one yourself is turned off too; if this is your domain, talk to us about the timing.

If you publish the key yourself

When it is time for a new key, whether we start it or you do, we generate the pair and show you the private key once, on that screen. What you publish is its public half, as a new record at a new name, which the panel shows you: not the one you already have, because the old key keeps signing until the new one is confirmed, and a record cannot do both at once.

Name:  cs202610._domainkey.mail.mycompany.com
Type:  TXT
Value: v=DKIM1; k=rsa; p=MIIBIjANBgkqhki...

Sending is not interrupted while you do this. We keep signing with the current key until we see the new record published and resolving, and only then switch. There is no point where a message leaves signed with a key nobody can look up yet.

Once we have switched, the old record can stay in your DNS for a few more days, and it should: messages sent before the change are still checked against it when somebody forwards them or a filter re-evaluates them.

When to start one yourself

• The private key was exposed, or you suspect it might have been.
• An internal policy requires periodic rotation.

Otherwise you do not need to: we already change the key about once a year on our own, with nothing for you to do unless you publish it directly.

Afterwards

Check in Messages that the first messages after a change are being delivered and not merely accepted. If a large receiver starts deferring after one you published yourself, wait for propagation rather than publishing a second time.