DKIM: selectors, key length and rotation without downtime

DKIM is the mechanism that lets a domain cryptographically sign the messages it sends. The receiver fetches the public key from DNS and checks that headers and body were not altered in transit. It is also the sturdiest pillar of DMARC because, unlike SPF, it almost always survives forwarding. Setting it up once is not enough: it has to be managed over time, and the concept that makes this possible is the selector.

What a selector is

Every DKIM signature carries two decisive fields in the DKIM-Signature header: d=, the signing domain, and s=, the selector. The receiver combines the two values and queries DNS at this name:

selector._domainkey.example.com

The selector is therefore a free-form label that allows several keys to be active at the same time on the same domain. Each service that sends on your behalf can have its own selector: one for the company mail server, one for the newsletter platform, one for the application that sends receipts.

A simplified header example:

DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=mail2026a;
  c=relaxed/relaxed; h=from:to:subject:date:message-id;
  bh=...; b=...

And the matching DNS record:

mail2026a._domainkey.example.com.  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqh..."

Choosing the selector name

The name has no technical meaning, but a good scheme makes life easier. Some practical criteria:

• include the service or function (crm, news, app);
• include a date reference or a sequence number (2026a, s2), useful for rotation;
• avoid names that reveal unnecessary internal details.

Many providers impose their own selector and ask you to publish a CNAME record pointing to their DNS. That is a good arrangement: they handle rotation and your record never needs touching.

Which key length

For RSA, 2048 bits is today's reference choice. 1024-bit keys are still accepted by many receivers, but they are considered weak and should be replaced. Keys longer than 2048 bits add margin, but produce bulkier records that not every DNS panel handles well.

A 2048-bit record exceeds the 255 characters of a single TXT string. DNS allows this by splitting the value into several quoted strings, which are concatenated when read:

s1._domainkey.example.com. TXT ( "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA"
                                 "u7Jx...rest-of-the-key...IDAQAB" )

There is also the Ed25519 algorithm for DKIM, with much shorter keys. Receiver support is not universal, though, so those who adopt it usually sign twice: once with RSA and once with Ed25519.

The signature parameters that matter

Canonicalization

The c= field says how tolerant verification should be of small changes. With relaxed/relaxed, extra whitespace and letter case in header names do not invalidate the signature; with simple, any change breaks it. For real-world mail relaxed/relaxed is almost always the right choice.

Signed headers

The h= field lists the headers covered by the signature. From is mandatory; it is good practice to include Subject, Date, To, Message-ID and, for newsletters, List-Unsubscribe and List-Unsubscribe-Post. A useful technique is to list From twice: that way a second From header added by an intermediary invalidates the signature instead of slipping through.

The l= tag

The l= tag limits the signature to part of the body. Avoid it: it lets third parties append content to the end of the message while keeping the signature valid.

Rotating keys without losing messages

A private key used for years is more likely to be exposed, perhaps in a forgotten backup or a copied configuration. Periodic rotation, for example every six or twelve months, limits the damage. Thanks to selectors it can be done without interruption:

1. Generate the new key pair and publish the record under a new selector, for example mail2026b.
2. Wait until the record is visible everywhere, taking the TTL into account.
3. Configure the server to sign with the new selector.
4. Leave the old record published for a few days: messages already queued or in transit must still be verifiable.
5. Remove the old record, or publish it with an empty p=, which explicitly signals a revoked key.

Checking that everything works

The most reliable check is to send a message to a mailbox you control and read the Authentication-Results header added by the receiver. It must show dkim=pass with header.d= equal to your domain, or one of its subdomains, if you want the signature to count for DMARC. A valid signature with the provider's d= passes DKIM, but is not aligned.

In short

• The selector lets several DKIM keys be active on the same domain, one per service.
• 2048-bit RSA keys are the current standard; 1024-bit keys should be replaced.
• Sign From, Subject, Date, Message-ID and the unsubscribe headers, and avoid the l= tag.
• Rotate by publishing a new selector and retiring the old one only after a few days.
• For DMARC, d= must be aligned with the From domain, not merely produce a valid signature.