DKIM Explained: How Email Signing Works and How to Set It Up
DKIM (DomainKeys Identified Mail) attaches a cryptographic signature to outgoing email. The sending server signs the message with a private key; anyone receiving it can verify that signature against a public key published in your DNS. If the message is altered in transit, the signature no longer validates.
Last updated: August 29, 2026
How DKIM works
When a message is sent, the mail server adds a DKIM-Signature header containing a hash of specific parts of the message, signed with a private key. The receiving server looks up the public key at selector._domainkey.yourdomain.com, a DNS TXT record, and uses it to verify the signature matches. The selector is just a label (often something like s1, google, or a date-based string). It lets a domain publish more than one DKIM key at once, which matters for key rotation and for using multiple sending services simultaneously.
Setting up DKIM
- Generate a key pair. RSA 2048-bit is the safe, universally-supported default. Ed25519 produces smaller, faster keys but isn't yet supported by every receiving mail system.
- Choose a selector name. Anything short and unique works; many providers assign one automatically.
- Publish the public key as a TXT record at
selector._domainkey.yourdomain.com. - Configure your mail server or provider with the private key so it signs outgoing mail.
- Send a test message and confirm the signature verifies.
Key size and algorithm choices
RSA 1024-bit keys are considered too weak for current use and are increasingly rejected outright. RSA 2048-bit is the current baseline. Ed25519 is smaller and computationally cheaper, which helps with DNS TXT record size limits, but check that your receiving audience's mail systems actually support it before relying on it exclusively.
Common mistakes
- Leaving old or test selectors published in DNS long after they're no longer used.
- Splitting a long public key across multiple quoted TXT strings incorrectly (DNS TXT records are limited to 255 characters per string and need correct concatenation).
- Typos in the selector name between DNS and the sending server's configuration, which have to match exactly.
- Rotating a key on the sending server before the new public key is live in DNS, which breaks verification for a window.
Create an RSA-2048 or Ed25519 key pair entirely in your browser and get the selector._domainkey TXT record ready to publish. The private key never leaves your device.
Frequently asked questions
What is a DKIM selector?
A short label that identifies which DKIM key was used to sign a message, published as part of the DNS record name (selector._domainkey.yourdomain.com). It lets a domain run more than one DKIM key at a time, which is useful when rotating keys or using several sending services.
Do I need DKIM if I already have SPF?
Yes. They check different things and survive different failure modes. SPF verifies the sending server's IP against your domain; DKIM verifies the message content wasn't altered, and it survives being forwarded through another server (which often breaks SPF). DMARC uses whichever of the two aligns to make its decision.
How often should I rotate DKIM keys?
There's no universal rule, but many domains rotate annually or when a key may have been exposed. The safe order is: publish the new public key in DNS first, wait for it to propagate, then switch the sending server to sign with it, never the other way around.
Can I use the same DKIM key across multiple domains?
Technically the DNS lookup is per-domain, so each domain needs its own published public key even if you reuse the same underlying key pair. It's generally better practice to generate a distinct key per domain.