How DKIM finds the key
A DKIM signature in a message names a domain (d=) and a selector (s=). The receiver joins them into selector._domainkey.domain, reads the TXT record there, and uses the public key in its p= tag to verify the signature. One domain can publish any number of selectors, so each sending service can have its own key and keys can be rotated without downtime.
The checker needs the selector because DNS offers no way to list the selectors a domain has. There is nothing to scan; the selector comes from the signature of a real message.
What makes a key weak or broken
RFC 8301 says RSA keys must be at least 1024 bits and should be 2048. A verifier may ignore a shorter key, and ours does, so a 512-bit key counts as no signature at all. Ed25519 keys (RFC 8463) are short by design and strong, but not every receiver verifies them yet, which is why they are usually published next to an RSA key rather than instead of it.
The checker decodes the key in full, because a record split badly across TXT strings, or base64 that does not decode, is a key no receiver can use. An empty p= means the key was revoked on purpose. t=y marks a domain that is still testing, and RFC 6376 §3.6.1 tells verifiers to treat its mail exactly like unsigned mail.
Questions
How do I find my DKIM selector, and is DKIM enabled at all?
Send yourself a message and open the headers of the copy that arrived. A DKIM-Signature header there means the message was signed: the selector is the s= value and the domain is d=. No such header means the service you sent through does not sign. Each sending service signs with its own selector, so a newsletter and a message from your mailbox may carry different ones.
The key is fine, but DKIM fails with "body hash did not verify". Why?
Usually the message was changed after it was signed, for example a footer added by a mailing list or a link rewritten by a security gateway. The key can only confirm what was signed. The full test shows the actual verification result for your message.
Full guide: DKIM fail
DKIM key length: 1024 or 2048 bits?
A 1024-bit key verifies everywhere, and RFC 8301 allows it. It is still the minimum, so move to 2048 bits next time you rotate keys.
Can a domain have more than one DKIM record?
Yes, one per selector, and many domains have several: one for the mailbox provider and one for each newsletter or billing service. Check them one at a time. A key that has been deleted from DNS fails every message still signed with it.
How often should I rotate DKIM keys?
M3AAWG recommends rotating at least every six months, and at once if a private key may have leaked. Publish the new key under a new selector, switch signing to it, and delete the old record only after mail signed with the old key has stopped arriving; senders retry for four to five days, so give it about a week.