DKIM signing explained

DKIM signs each outgoing message with a private key held by your mail server. The matching public key sits in DNS, and receivers use it to confirm the message was really sent by you and has not been altered on the way.

Unlike SPF, DKIM survives forwarding. A message forwarded through a mailing list usually fails SPF because the address it arrives from is now the list server, but the DKIM signature still verifies. That is a good reason to have both.

Selectors

The public key is published under a selector, which is just a label that lets you have several keys at once. Your provider gives you the selector and the record, and you publish it.

bash

dig fm1._domainkey.example.com TXT +short
# "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A..."

Why a checker cannot list your selectors

DNS has no way to enumerate names, so no tool can discover which selectors exist on a domain. Any checker, mine included, can only try common names. If a check says no DKIM key was found but you know you publish one, it almost certainly uses a selector nobody guesses. That is fine, receivers read the selector out of the message header.

Key size and rotation

Use 2048 bits if your provider offers it. Anything below 1024 is rejected by most receivers now. Rotating keys is easy because of selectors: publish the new key under a new selector, switch the server to sign with it, and remove the old record once nothing is signing with it any more.

An empty p= value means the key is revoked. If you see that unexpectedly, someone has replaced the record with a tombstone.