What is DKIM?

DKIM (DomainKeys Identified Mail) signs each message with a private key and publishes the matching public key in DNS. The signature lets receiving mail servers verify that the email 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 does not 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. Check your domain's DKIM setup to confirm your selectors are publishing correctly.

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=MIIBIjANBgkqhkiG9w0BAQEFAAOC..."

• 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 SendGrid, 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 — M3AAWG recommends rotating DKIM keys at least every six months. Publish each new key under a new selector so you can rotate without downtime: publish the new key, switch signing to it, keep the old key published unchanged for at least seven days (M3AAWG allows up to 30), then revoke it with an empty p= instead of deleting the record. The DKIM key rotation guide walks through each step.
• 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 sendgrid._domainkey for SendGrid — 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 instead of at the domain level.

Sources

1. RFC 6376: DomainKeys Identified Mail (DKIM) Signatures
2. RFC 8463: A New Cryptographic Signature Method for DKIM (Ed25519)