DKIM Explained: Selectors and Key Rotation

How a DKIM signature works

The signer first canonicalizes the message, which normalizes whitespace and header case so that harmless changes in transit do not break the signature. It hashes the body into the bh= tag, then signs that hash together with the headers listed in h=. The verifier repeats the same steps with the public key from DNS.

A typical signature header looks like this, with the long values shortened:

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=example.com;
        s=s2026a; t=1760486400; h=from:to:subject:date:message-id:mime-version;
        bh=2jUSOH9NhtVGCQWNr9BrIAPreKQjO6Sn7XIkfJVOzv8=;
        b=Kx4Fv0c8...truncated...Qe1w==

Selectors and the DNS record

The public key record lives at <selector>._domainkey.<domain> as a TXT record. Its main tags are v=DKIM1, the key type k= (RSA when omitted), and the base64 public key in p=. An optional t=y flag marks the domain as testing DKIM, and an empty p= means the key has been revoked.

$ dig +short TXT s2026a._domainkey.example.com
"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAu2v7...first 255 bytes"
"...remaining part of the key...IDAQAB"

$ dig +short CNAME s1._domainkey.example.com
s1.dkim.mail-provider.example.net.

Two details in that output trip people up. First, a single string inside a TXT record is limited to 255 bytes, and a 2048-bit RSA key is longer than that. The key is therefore split into several quoted strings inside one record, and verifiers join them back together. Splitting it into two separate TXT records instead is a common and fatal mistake. Second, many email services ask you to publish a CNAME instead of a TXT record. The selector then points at a name the service controls, which lets the service rotate its own keys without asking you to edit DNS.

Selector names are free-form. Good practice is to make them meaningful but not secret, for example by including the service and a date, such as mkt2026q4. That makes it obvious during an audit which keys are current and which are leftovers.

Key types and sizes

RFC 8301 updated DKIM's cryptographic requirements. Signers must not use rsa-sha1, RSA keys must be at least 1024 bits, and signers should use at least 2048 bits. RFC 8463 added Ed25519 keys, which are short enough to fit easily in DNS. Verifier support for Ed25519 is not universal, so domains that adopt it usually sign each message twice, once with RSA and once with Ed25519, using two selectors. A verifier that does not understand one signature ignores it and evaluates the other.

If you still have 1024-bit RSA keys in use, moving to 2048 bits is a normal rotation, described next.

Rotating DKIM keys safely

Rotation limits the damage a leaked private key can do and gives you a routine you can trust when you need to replace a key in a hurry. The rule that keeps rotation safe is simple: the new public key must be visible in DNS before the first message is signed with it, and the old public key must stay visible until no message signed with it can still be checked.

Notice that the new selector name matters in step 1. If you reuse the old selector name and overwrite its key, receivers that cached the old key will fail messages signed with the new one until the TTL runs out, and messages still in flight with the old signature will fail once the new key arrives. A fresh selector avoids both problems. Negative caching is explained further in Negative Caching and the SOA Minimum.

DKIM, SPF and DMARC alignment

DKIM on its own does not stop someone spoofing your From address, because an attacker can sign mail with their own domain. DMARC closes that gap by requiring that either SPF or DKIM passes and that the passing domain aligns with the domain in the From header. With relaxed alignment, d=mail.example.com aligns with a From address at example.com because they share an organizational domain. A service that signs with d=sender.example.net does not align.

DKIM has one big advantage over SPF: it usually survives simple forwarding, because the signature travels with the message instead of depending on the connecting IP address. Mailing lists that add footers or rewrite subjects do break it. The ARC protocol in RFC 8617 lets intermediaries record what they saw before modifying a message. For the SPF and DMARC side of the picture, see SPF/DMARC Misconfigurations.

How DNS Panopticon helps

Domain Visualizer is the tool for mail records. Its scan looks up DKIM at two selectors, selector1 and selector2 (the names Microsoft 365 uses), along with SPF, DMARC, MTA-STS, TLS-RPT and BIMI. If neither selector exists it reports an informational finding only, because DKIM selectors are chosen by each sending service and a missing selector1 says nothing about the selectors you actually use. Read the s= and d= tags from a real message's DKIM-Signature header and check that selector with dig as shown above. Website Recon focuses on websites and registration and does not check mail records.

For an inventory, load a zone export into Zone Analyzer and filter hostnames on _domainkey. You get every selector you publish in one grid, which makes stale keys from retired services easy to spot and export as CSV for cleanup.