What is DKIM? DomainKeys Identified Mail Explained

What is DKIM?
DKIM (DomainKeys Identified Mail) is an email authentication standard that lets a domain attach a cryptographic signature to the messages it sends, so the receiving server can confirm two things: the mail really came from that domain, and nothing in the signed portion changed in transit. It is defined in RFC 6376 and works by publishing a public key in DNS while the sending server keeps the matching private key secret.
DKIM says nothing about which servers are allowed to send for you — that is SPF's job. On its own it also does not tell receivers what to do when a check fails; that decision belongs to DMARC. DKIM's single, narrow contribution is a portable proof of origin and integrity that survives forwarding better than SPF does.
How does DKIM work?
DKIM relies on an asymmetric key pair: a private key that only the sender holds and a public key that anyone can read from DNS.
- Signing. When your mail server sends a message, it hashes selected headers (typically
From,Subject,Date,To) and the body, then encrypts that hash with your private key. The result is inserted as aDKIM-Signature:header, which also records the signing domain (d=), the selector (s=), and exactly which headers were signed (h=). - Publishing the key. The domain owner publishes the matching public key as a TXT record at
. The selector lets one domain run several keys at once — one per sending service, or an old and new key during a rotation.._domainkey.yourdomain.com - Verifying. The receiving server reads
d=ands=from the signature, fetches the public key at that DNS location, and recomputes the hash. If its result matches the decrypted signature, DKIM passes. If the signature is missing, the key cannot be found, or the body was altered, DKIM fails.
The value in that record is the public key. The v=DKIM1 tag marks it as DKIM, k=rsa names the algorithm, and p= carries the base64-encoded key itself. Deleting the p= value revokes the key immediately.
What the DKIM signature proves — and what it doesn't
A valid DKIM signature proves the signed headers and body were not modified after signing, and that whoever signed controls the private key for the d= domain. It does not prove that the visible From: address is trustworthy. An attacker can send a message that is perfectly DKIM-signed for their own domain while displaying your brand in the From: field. That gap is exactly why DMARC exists: it requires the DKIM d= domain (or the SPF domain) to align with the From: domain the reader actually sees.
Because DKIM signs the message rather than the connection, its result travels with the email. A mailing list or forwarder that leaves the signed headers and body intact preserves a passing signature, which is why DMARC can still succeed on forwarded mail through DKIM even when SPF breaks.
Current key and algorithm guidance
- Use a 2048-bit RSA key. RFC 8301 says signers should use RSA keys of at least 2048 bits and must use at least 1024. A 2048-bit key satisfies that guidance and the Gmail and Yahoo bulk-sender rules; anything below 1024 bits is rejected outright by verifiers.
- Ed25519 is defined but not universal. RFC 8463 added
k=ed25519signatures. Support across receivers and gateways is still uneven, so if you adopt Ed25519, publish an RSA key alongside it rather than relying on it alone. - Rotate with selectors. Because the selector is part of the DNS path, you can publish a fresh key under a new selector, switch your signer to it, and remove the old one once no in-flight mail relies on it — with zero downtime.
Why DKIM matters
- It blocks tampering. Any change to signed content invalidates the signature, protecting recipients from altered invoices, links, or payment details.
- It curbs spoofing and phishing. Combined with DMARC alignment, DKIM makes it far harder for an attacker to send convincing spam that appears to come from your domain.
- It is a DMARC prerequisite. DMARC passes when SPF or DKIM aligns. DKIM is the more resilient of the two, so a correctly signed domain keeps authenticating even when mail is forwarded.
- It helps deliverability. Mailbox providers treat a consistently signing domain as more reputable, which supports inbox placement over time.
Frequently asked questions
How many DKIM records can one domain have?
As many as you have selectors. Each sending service — your mailbox provider, your marketing platform, your ticketing tool — should sign with its own key under its own selector, so every stream authenticates independently and you can revoke one without touching the others.
Does DKIM encrypt my email?
No. DKIM signs a hash of the message so tampering is detectable, but the body still travels in plain text unless the connection is separately protected with TLS. DKIM is about authenticity and integrity, not confidentiality.
Why does DKIM pass but DMARC still fails?
Almost always an alignment problem. DMARC needs the DKIM d= domain to match the visible From: domain (in relaxed mode, the organizational domain must match). A message signed by d=mailer.vendor.com for a From: of yourdomain.com produces a valid DKIM signature that DMARC still rejects because the domains do not align.
What breaks a DKIM signature after it's sent?
Anything that modifies a signed header or the body: a mailing list appending a footer, a security gateway rewriting links, or a forwarder that reformats content. When that happens, DKIM fails at the next hop — which is why pairing it with SPF and DMARC gives you a second path to authenticate.
How long does a DKIM DNS change take to work?
It is governed by the TTL of the record, not a fixed clock. Resolvers that cached an old record serve it until their copy expires; with a short TTL that is minutes. Lower the TTL before rotating a key, then raise it again afterward.
Related reading

Written by
Samuel ChenardCEO & Co-Founder, Palisade
Samuel Chenard is the CEO and co-founder of Palisade, the DMARC automation platform for MSPs. He writes Palisade's guides on DMARC, SPF, DKIM and email deliverability.
More from Samuel →


