DKIM explained: selectors, keys and rotation

What DKIM proves

DKIM (DomainKeys Identified Mail, RFC 6376) lets a domain take responsibility for a message. The sending server signs selected headers and the body with a private key and adds the result as a DKIM-Signature header. The receiving server fetches the matching public key from DNS and checks the signature. If it verifies, the receiver knows two things: the message really was signed by the domain in the signature's d= tag, and the signed parts weren't changed on the way.

Unlike SPF, DKIM doesn't care which server delivered the message, so a signature normally survives forwarding. It can break when something along the way rewrites the message - a mailing list that adds a footer or tags the subject, for example. DKIM on its own also says nothing about what a receiver should do with unsigned mail; that is what DMARC adds.

Anatomy of a DKIM signature

A shortened signature header looks like this:

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=example.com;
  s=mail2026; h=from:to:subject:date:message-id;
  bh=47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=;
  b=Kx9f...base64 signature...

Selectors: more than one key per domain

The selector is a label you choose, and it decides where the public key lives: selector mail2026 on example.com means the key is published at mail2026._domainkey.example.com. Because every selector is a separate DNS name, a domain can have many keys at once - one per sending service (your mailbox provider, a newsletter tool, a helpdesk) and, during a rotation, an old and a new key side by side. Keys from different services never conflict, unlike SPF, where everything has to fit into one record.

The DKIM TXT record

The public key is published as a TXT record under the selector name:

mail2026._domainkey.example.com.  3600  IN  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA..."

• v=DKIM1 is the version, k=rsa the key type and p= the base64-encoded public key. An empty p= means the key has been revoked.
• In your DNS panel the host is usually just mail2026._domainkey; the panel appends the domain itself. Entering the full name there often produces mail2026._domainkey.example.com.example.com.
• Copy the value exactly. A missing character, a stray space or a line break in the middle of the key makes every signature fail.
• Some providers ask you to create a CNAME pointing at a key they host instead of a TXT record. That works too, as long as you use the record type they specify.

Key length: why 2048-bit

RSA keys shorter than 1024 bits must not be used for DKIM (RFC 8301), and 1024-bit keys are now considered weak. Use 2048 bits: it is what major mailbox providers recommend and what practically every receiver can verify. The only practical cost is size - a 2048-bit public key is roughly 400 characters of base64, longer than the 255-character limit of a single TXT string. The record then has to be split into several strings within one record (most DNS panels do this automatically; see how to add DNS records). Ed25519 DKIM keys (RFC 8463) exist, but support among receivers is still incomplete, so they are used alongside RSA rather than instead of it.

AnyMail generates a separate 2048-bit RSA key for every mail server and keeps the private half encrypted at rest.

Rotating a DKIM key safely

Rotating keys limits the damage if a private key ever leaks and is good hygiene for long-lived domains; once a year is a common rhythm. The key point is order: a receiver must be able to find the new public key before it sees the first message signed with it, and the old key must stay available while mail signed with it may still be checked.

The two-phase rotation

1. Prepare. Generate a new key pair under a new selector and publish its public key next to the current one. Keep signing with the old key.
2. Verify. Wait until the new record resolves publicly - at least the TTL of the record.
3. Switch. Start signing with the new key.
4. Retire. Leave the old record published for a few more days, so messages still queued or re-checked later keep verifying, then delete it.

AnyMail follows exactly this flow. Starting a rotation creates the new key under a fresh selector while the current key keeps signing; AnyMail looks up the new record and only lets you activate it once DNS really serves the right key. After activation, the old key stays listed as retired for seven days with a reminder of when its record can be removed. Nothing rotates automatically - you choose when to switch, and the dashboard suggests a rotation once a key is more than a year old.

Checking DKIM

Look up the key with dig TXT mail2026._domainkey.example.com +short or use the email authentication checker. Then send yourself a message at an external mailbox and look at the Authentication-Results header: dkim=pass header.d=example.com means the signature verified for your domain. If it says dkim=fail, the usual causes are a truncated key, a selector mismatch, or a system that modifies messages after they have been signed.