Key PairDKIM Public / Private Key Pair

Definition

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
At a glance
Cryptography Asymmetric (public / private)
Private key On the mail server, signs mail
Public key DNS TXT record, verifies
DNS hostname selector._domainkey.domain
Recommended RSA 2048-bit (RFC 8301)
Alt algorithm Ed25519 (RFC 8463)

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.

A DKIM public-key record: selector s1, domain example.com, 2048-bit RSA
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

You generate a key pair: one private, one public
The public key goes into DNS at selector._domainkey; the private key stays on the server
Outgoing mail is signed with the private key into a DKIM-Signature header
The receiver reads s= and d= and fetches your public key from DNS
It re-hashes the message and checks it against the signature
A match proves the domain signed it and it was not altered

Private 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

Still using a 1024-bit key
Gmail, Yahoo, and Microsoft now treat 1024-bit DKIM keys as weak and may discount or ignore them. Generate a 2048-bit RSA pair so your signatures carry full weight.
Never rotating the key
A key that signs forever is a standing risk: if the private key ever leaks, attackers can sign as you indefinitely. Rotate periodically under fresh selectors.
Pasting the private key into DNS
Only the public key belongs in the DNS TXT record. Publishing the private half hands anyone the ability to forge your domain’s signature. Keep it on the server alone.

Frequently asked questions

What is the difference between the public and private DKIM key?
The private key stays secret on your sending server and signs each outgoing message. The public key is published in DNS for anyone to read and is used by receivers to verify that signature. Only the matching pair validates, which is what proves the mail came from your domain.
What DKIM key length should I use?
Use 2048-bit RSA. RFC 8301 sets it as the minimum, and major mailbox providers treat 1024-bit keys as weak. 4096-bit works but can cause DNS issues with some resolvers, and Ed25519 is faster but not yet universally supported, so 2048-bit RSA is the safe default.
How often should I rotate DKIM keys?
A common practice is every few months to once or twice a year. Generate a new key under a new selector, publish it, switch signing over, then retire the old selector after a short overlap so in-flight mail still verifies. Rotate immediately if a private key is ever exposed.
Reviewed by Jennifer Jackson, Email Deliverability Analyst · June 2026 ← Back to glossary