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.

When you already have a message or provider selector, use the DKIM record-check workflow to resolve the exact public key and validate the same production path.

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.

1. 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 a DKIM-Signature: header, which also records the signing domain (d=), the selector (s=), and exactly which headers were signed (h=).
2. Publishing the key. The domain owner publishes the matching public key as a TXT record at ._domainkey.yourdomain.com. The selector lets one domain run several keys at once — one per sending service, or an old and new key during a rotation.
3. Verifying. The receiving server reads d= and s= 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=ed25519 signatures. 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.

You can confirm a domain is signing correctly, and see the published selector and key, with the DKIM lookup tool — or check SPF, DKIM, and DMARC together with the Email Security Score.

If Google Workspace sends mail for your domain, follow the Google Workspace DKIM setup guide to generate the account-specific key, publish it in DNS, start authentication, and verify a delivered message.

If Mimecast is the final outbound gateway, use the Mimecast DKIM setup guide for the DNS Authentication definition, generated TXT key, outbound policy, and delivered-message validation steps.

Related reading

• What are DMARC, DKIM, and SPF?
• What is an email header?
• What is email deliverability?