Key PairDKIM Public / Private Key Pair
A DKIM key pair is the two halves of the cryptography behind DKIM: a private key kept secret on your mail server that signs each outgoing message, and a matching public key published in DNS that any receiver uses to verify that signature. Because only the holder of the private key could have produced a signature the public key validates, the pair proves a message really came from your domain and wasn’t altered in transit.
- The private key signs; the public key in DNS verifies. Never share the private key
-
The public key lives at
selector._domainkey.yourdomain.com - RSA 2048-bit is the modern standard; 1024-bit is now considered weak
- Rotate keys periodically using a fresh selector so signing never breaks
TXT record, verifies
selector._domainkey.domain
How the two keys work together
DKIM uses asymmetric cryptography: a single mathematically linked pair of keys, where what one key locks only the other can unlock. You keep the private key on your sending infrastructure. When a message goes out, the server hashes selected headers and the body and signs that hash with the private key, attaching the result as a DKIM-Signature header.
The public key is the opposite half, and it is safe to publish for the world to read. You place it in DNS as a TXT record. A receiver pulls the public key, re-computes the hash of the message it received, and checks it against the signature. If they match, two things are proven at once: the message was signed by a holder of the private key for that domain, and nothing the signature covered was changed on the way.
Selectors and where the public key lives
The public key is published at a hostname built from a selector: a label you choose (such as s1, default, or june2026) that lets a single domain hold several keys at once. The DKIM-Signature header on each message names its selector in the s= tag and the domain in the d= tag, which together tell the receiver exactly which DNS record to fetch.
s1._domainkey.example.com. 3600 IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEArQ...IDAQAB"
Key length, algorithm, and rotation
Key strength matters. RFC 8301 sets the minimum at 2048-bit RSA, and Gmail, Yahoo, and Microsoft now treat 1024-bit keys as weak. 2048-bit is the sweet spot: far stronger than 1024, without the DNS quirks that 4096-bit keys can hit with older resolvers. Ed25519 (RFC 8463) is a faster, much shorter modern option, but support is not yet universal, so RSA 2048 remains the safe default.
- Rotate on a schedule. Generate a new key under a new selector, publish its public key, switch signing to it, then retire the old one. Rotating limits the damage if a private key ever leaks.
- Keep the old selector live briefly. Leave the previous public key in DNS for a few days after cutover so mail already in flight still verifies.
- Guard the private key. If it is exposed, anyone can sign as your domain. Treat it like a password and reissue the pair immediately if it is ever compromised.
How a DKIM key pair signs and verifies a message
selector._domainkey; the private key stays on the serverDKIM-Signature headers= and d= and fetches your public key from DNSPrivate key vs public key
| Private key | Public key | |
|---|---|---|
| Where it lives | On your mail server | In public DNS |
| What it does | Signs outgoing mail | Verifies the signature |
| Who may see it | Only you (secret) | Anyone (published) |
| If exposed | Domain can be spoofed | No harm, it is public |
Common mistakes
TXT record. Publishing the private half hands anyone the ability to forge your domain’s signature. Keep it on the server alone.