Publishing your first DKIM key
Generate a 2048-bit key, publish the public half as a TXT record, enable signing, and verify with a real message before you trust it.
Most hosted providers generate the key for you and show you a record to paste. When you are running your own mail server, the routine is short but unforgiving about detail.
Generate the pair
OpenSSL, 2048-bit RSA
openssl genrsa -out mail2026.private 2048
openssl rsa -in mail2026.private -pubout -outform PEM -out mail2026.publicKeep the private key readable only by the signing daemon. It is a credential: anyone holding it can sign mail as your domain, and a leaked key needs a rotation, not a patch.
Publish the public half
Strip the PEM header, footer and newlines, then publish the base64
mail2026._domainkey.example.com TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhki..."- v=DKIM1 is the version. Optional per the RFC, but publish it.
- k=rsa is the key type. Default is rsa, so it is often omitted.
- p= carries the base64 public key. An empty p= means the key is revoked.
- t=y is test mode. Tells receivers not to act on failures. Remove it once you are live.
Key size
Use 2048-bit RSA. 1024 is still accepted but is the floor, not a target. Ed25519 keys are defined and much shorter, but support among receivers remains patchy. If you use one, publish an RSA key alongside it and sign with both.
A 2048-bit key in base64 exceeds the 255-character limit for a single TXT string. It must be published as multiple quoted strings in one record. Most DNS providers handle this automatically; if yours does not, split it manually rather than truncating.
Verify
Look the selector up with the DKIM tool to confirm the record parses and the key size is what you expect. Then send a real message to a mailbox you control and read Authentication-Results in the received headers. dkim=pass header.d=example.com is the outcome you want.
More on DKIM
What DKIM actually does
DKIM signs the message itself, so the proof travels with the mail. That is why it survives forwarding when SPF does not.
Selectors: how one domain holds many DKIM keys
The selector is the label that lets each sending service have its own key under the same domain, and it is what makes rotation possible without downtime.
Rotating DKIM keys without dropping mail
Rotation is a four-step overlap: publish the new key, switch signing, wait out mail in flight, then revoke the old one.