What is DKIM?

What is DKIM?

DKIM stands for DomainKeys Identified Mail. It is an email authentication protocol that uses public-key cryptography to attach a digital signature to outgoing messages. This signature allows receiving mail servers to verify that the email genuinely came from an authorized server for the sending domain and that the message content was not tampered with in transit.

Unlike SPF, which checks the sending server's IP address, DKIM verifies a cryptographic signature embedded in the email headers. This means DKIM survives email forwarding — a major advantage over SPF alone.

How Does DKIM Work?

DKIM operates using an asymmetric key pair:

• Private key — Stored securely on the sending mail server. Used to sign outgoing messages.
• Public key — Published as a DNS TXT record at a specific selector subdomain. Used by receiving servers to verify signatures.

The signing process works as follows:

• When an email is sent, the mail server computes a hash of specified headers and the message body.
• It encrypts the hash using the private key, producing a signature.
• The signature is added to the email as a DKIM-Signature header.
• The receiving server reads the DKIM-Signature header, fetches the public key from DNS, decrypts the signature, and compares it to its own computed hash.
• If the hashes match, the signature is valid — confirming the message was signed by the private key holder and was not modified.

Why is DKIM Important?

DKIM provides two critical guarantees that SPF cannot:

• Content integrity — DKIM detects if the message was modified after signing. If any signed header or the body changes, the signature fails.
• Forwarding resilience — Since DKIM doesn't check the sending IP, it remains valid when email is forwarded through another server. SPF typically breaks in this scenario.

For DMARC to pass, at least one of SPF or DKIM must pass with proper alignment. In practice, DKIM is the more reliable signal because it travels with the message itself.

The DKIM-Signature Header

A DKIM-Signature header looks like this:

DKIM-Signature: v=1; a=rsa-sha256; d=yourdomain.com; s=mail;
  h=from:to:subject:date:message-id;
  bh=47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=;
  b=abc123...

Key fields explained:

• v=1 — DKIM version. Always 1.
• a=rsa-sha256 — The signing algorithm. RSA with SHA-256 is standard; Ed25519 is a modern alternative.
• d=yourdomain.com — The signing domain. This is the domain that must align with the From: header for DMARC.
• s=mail — The selector. Combined with d= to look up the public key at mail._domainkey.yourdomain.com.
• h= — The list of headers that were signed. The From: header must always be included.
• bh= — The hash of the canonicalized message body.
• b= — The actual cryptographic signature of the specified headers.

The DKIM DNS Record

The public key is published at {selector}._domainkey.{domain}. For example:

mail._domainkey.yourdomain.com IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3..."

• v=DKIM1 — Identifies this as a DKIM public key record.
• k=rsa — Key type. rsa or ed25519.
• p= — The Base64-encoded public key. Set to empty (p=) to revoke a key.

How to Set Up DKIM

Setup depends on your mail infrastructure:

• Google Workspace — Generate the key in the Admin console under Apps → Gmail → Authenticate email, then publish the provided DNS record.
• Microsoft 365 — Enable DKIM in the Defender portal under Email & collaboration → Policies. Microsoft provides the CNAME records to publish.
• Third-party senders — ESPs like MXPaw, Mailchimp, and Postmark provide custom domain authentication that publishes DKIM keys under your domain via CNAME records.
• Self-hosted (Postfix, etc.) — Use a tool like OpenDKIM to generate a key pair. Publish the public key in DNS and configure the signing daemon.

Common Issues

• Key rotation neglect — DKIM keys should be rotated periodically (at least annually). Use multiple selectors so you can rotate without downtime: publish the new key, update the signing configuration, then remove the old DNS record after TTL expires.
• Canonicalization mismatches — DKIM supports simple and relaxed canonicalization for headers and body. relaxed/relaxed is recommended because it tolerates minor whitespace changes introduced by mail transfer agents.
• Body length changes — Some mailing lists or mail clients append content (footers, disclaimers) to messages, which changes the body hash and breaks DKIM. The l= tag can limit the body bytes signed, but this is not recommended as it weakens the guarantee.
• DNS propagation delays — After publishing a new DKIM key, allow up to 48 hours for DNS propagation before enabling signing with that selector.

Frequently Asked Questions

Can I have multiple DKIM keys for one domain?

Yes. Each key uses a different selector (the s= tag). You can have keys for different services — for example, google._domainkey for Google Workspace and mxpaw._domainkey for MXPaw — and all can sign email from your domain simultaneously.

What key length should I use for DKIM?

Use RSA 2048-bit keys at minimum. 1024-bit keys are considered weak and are rejected by some receivers. If your mail software supports it, Ed25519 keys provide equivalent security with much shorter key material and faster verification.

Does DKIM encrypt my email?

No. DKIM only signs the message — it proves authenticity and integrity, but the email content is not encrypted. For email content encryption, you would need S/MIME or PGP, which are separate mechanisms and operate end-to-end rather than at the domain level.