DKIM selectors: finding, verifying and rotating keys

How DKIM uses the selector

DKIM (RFC 6376) has the sending server sign selected headers and the body with a private key. It adds a DKIM-Signature header like this one:

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

Two tags tell the receiver where to look:

• d=example.com is the signing domain. It's the identity DMARC compares with the From: address.
• s=selector1 is the selector.

The receiver fetches selector1._domainkey.example.com as a TXT record, gets the public key, and verifies the signature. Selectors exist so a domain can have many keys at once: one per platform, and old and new keys side by side during rotation.

Finding your selector

Because selectors are arbitrary labels, no tool can list them all for a domain. Checkers, including ours, try common names such as google, selector1, selector2, k1 and s1, but a miss doesn't mean DKIM is absent. The reliable way:

1. Send a message from the platform you're checking to a mailbox you control.
2. Open the full headers. In Gmail use "Show original"; in Outlook, open the message's Properties and look at "Internet headers".
3. Find DKIM-Signature and read s= and d=.
4. Enter that selector in the Email Record Lookup.

Common platform defaults (check your own headers, as these can be changed):

Where the record is a CNAME, the vendor hosts and rotates the key for you. Your job is to keep the CNAME in place.

Reading the key record

A published key looks like this:

selector1._domainkey.example.com. TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAx..."

Key length

RFC 8301 requires signers to use RSA keys of at least 1024 bits and says they should use at least 2048. Verifiers must reject keys shorter than 1024 bits. In practice:

• 2048-bit RSA is the recommended default and is supported by every major platform.
• 1024-bit still verifies, but it's weak; replace it at your next rotation.
• A 2048-bit public key is longer than one 255-character TXT string, so it must be split into several strings within one record. Most DNS providers do this automatically; some older control panels truncate it, which breaks every signature.

Ed25519 keys (RFC 8463) are short and strong, but receiver support is still incomplete. If you use them, sign with RSA as well.

Rotating keys

Rotation limits the damage if a private key leaks and retires weak keys. Do it in this order, and mail is never left unsigned or signed with an unpublished key:

1. Generate a new key pair and publish the public key at a new selector, e.g. s2026b._domainkey.
2. Wait at least the record's TTL, plus a margin, so resolvers can see it.
3. Switch signing to the new selector on the mail platform.
4. Keep the old public key published for several days. Messages signed with it may still be in queues or re-checked later.
5. Revoke the old key by publishing it with an empty p=, then remove it later.

Microsoft 365's two selectors exist precisely for this: it signs with one while the other is prepared, then swaps.

Common mistakes

• Concluding "no DKIM" from a selector scan. Always check the real selector from headers.
• Truncated keys. A key cut off at 255 characters fails verification with a "bad key" error. Compare the published p= length with what the platform gave you.
• Signing with a vendor's domain instead of yours. If d= is the vendor's domain, DKIM passes but doesn't align with your From: domain, so DMARC still fails. Set up custom-domain signing in the vendor's settings.
• Deleting CNAMEs during a DNS migration. Provider-hosted keys disappear and every message from that platform fails DKIM at once.
• Leaving t=y in place after testing finishes.

From the field: SPF is the list that says "This server was authorized to send this message from my domain." DKIM says "This message was authorized to be sent from my domain." If you do not have DKIM records properly configured, recepients have no way of validating this authorization.

Verify your setup

1. Find the selector in a real message's headers.
2. Check the key in the Email Record Lookup with that selector: it reports key type, approximate length, revocation and test mode.
3. Send a test message to a mailbox you control and look for dkim=pass header.d=yourdomain in the Authentication-Results header.

Sources

• RFC 6376: DomainKeys Identified Mail (DKIM) Signatures
• RFC 8301: Cryptographic algorithm and key usage update to DKIM
• RFC 8463: A new cryptographic signature method for DKIM (Ed25519)