Guides DKIM
What is DKIM?
DKIM (DomainKeys Identified Mail) works like a wax seal on a letter. Your mail server 'seals' every outgoing message with a secret key. The receiver needs a matching public key to check whether the seal is intact. You publish that public key in your DNS. If the seal checks out, it's certain the mail came from your domain and wasn't tampered with along the way. Without DKIM your DMARC leans on SPF alone, and SPF breaks the moment someone forwards your mail.
How does the seal work?
When sending, your mail server computes a kind of fingerprint over the body and a few important headers of the message, and signs it with a secret private key that only you hold. The result goes into the mail as a DKIM-Signature header, along with two pointers: the selector (s=, a sort of key name) and the signing domain (d=).
The receiver reads those pointers, fetches the matching public key from your DNS (at <selector>._domainkey.<domain>) and checks whether the fingerprint matches. If it does, it's proven that no one altered the signed parts.
What's in DNS?
The DKIM key lives as a TXT record at <selector>._domainkey.<domain>. The main parts:
v=DKIM1: the versionk=rsa: the key type (rsaor the more moderned25519)p=...: the public key itself, a long string of characters- an empty
p=means: this key has been revoked and no longer counts
Usually you don't build this by hand: your mail provider supplies it ready-made, often as a CNAME pointing to the provider so they handle the management (and rotation) for you.
Why you need this
DKIM proves two things at once: that the mail was genuinely sealed by your domain, and that the content wasn't altered in transit. A big advantage over SPF: DKIM usually survives forwarding. SPF looks at the sending IP address, which changes when a message is forwarded. The DKIM seal is attached to the message itself, so it stays valid.
Together with SPF, DKIM is the basis for a passing DMARC check: at least one of the two must 'match your visible sender'. That's why you really want DKIM switched on at all times.
Keys and rotation
Use at least a 2048-bit RSA key. 1024 bits is too short: a key that size can be cracked, and whoever does it can sign mail that receivers can't tell apart from yours. Ed25519 is more modern and compact, but not yet supported everywhere. You can publish both side by side.
Rotate (replace) your keys now and then, so a leaked key can't be abused forever. Does your provider manage DKIM via a CNAME? Then they usually rotate automatically and you don't have to do anything.
Finding your selector
You can't simply query DKIM selectors from DNS. You need to know the name. That's why checkers sometimes can't find your DKIM: they try a list of known selectors, and if yours isn't on it, it looks like nothing is there.
Here's how to find it yourself:
- Open a mail you've sent and view its raw headers
- Locate the
DKIM-Signatureheader and reads=(the selector) andd=(your domain) - Check that
<selector>._domainkey.<domain>returns a validp=
DNS Radar's Mailheaders tool extracts the selector from a pasted header automatically.
Frequently asked questions
What is a DKIM selector?
A name that points to where the public key lives (<selector>._domainkey.<domain>). One domain can have several selectors, e.g. one per provider or per key rotation.
Why can't a checker find my DKIM?
Because selectors aren't enumerable. A tool probes known selectors. If yours isn't among them, paste a sent mail header or add your selector manually.
What key length should I use?
At least 2048-bit RSA. 1024 bits is considered too weak. Ed25519 is fine too, provided your receivers support it.
How often should I rotate my DKIM key?
Rotating every six to twelve months is common. If your provider manages DKIM via a delegated CNAME, it usually rotates automatically and you don't have to do anything.
What does an empty p= mean?
That the key has been revoked. A record with p= and no value tells receivers this selector is no longer valid.