DKIM

For an in-depth treatment, see How DKIM Works. This page is a quick reference.

How DKIM works

1. Outgoing mail server canonicalizes the message and computes a hash of the body and selected headers.
2. Server signs the hash with a private key for a specific selector and domain.
3. The signature, plus metadata about which headers were signed and which selector was used, is added as a DKIM-Signature header.
4. The receiver fetches the public key from DNS at selector._domainkey.signing-domain.
5. Receiver recomputes the hash and verifies the signature.
6. Signature verifies = message came from someone with the private key AND content wasn't modified.

The DKIM-Signature header

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
    d=example.com; s=mail2026; t=1716643200;
    h=from:to:subject:date:message-id;
    bh=47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=;
    b=K3KqDfM2gG4z/m...truncated...0NX==

Key fields:

• d= — signing domain.
• s= — selector. Combined with d= to locate the public key in DNS: s._domainkey.d.
• a= — signature algorithm (rsa-sha256 or ed25519-sha256).
• h= — colon-separated list of headers that were signed.
• bh= — body hash.
• b= — the actual signature.
• c= — canonicalization mode (relaxed/relaxed is the practical default).

The DNS record

Published at selector._domainkey.domain:

mail2026._domainkey.example.com.  IN TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA..."

Field reference:

• v=DKIM1 — version tag.
• k=rsa — key type. RSA or Ed25519.
• p= — base64 public key. An empty p= means the key is revoked.

Selectors enable rotation

The selector is a label that lets one domain have multiple DKIM keys at the same time. Standard key rotation:

1. Publish a new selector with a new key.
2. Switch the signing server to the new selector.
3. Wait at least 7 days so any messages signed with the old key have been delivered.
4. Remove the old DNS record (or publish with empty p= to revoke).

Multiple selectors also enable per-service signing: different keys for your transactional mail provider, marketing platform, and self-hosted mail.

What DKIM does and does not do

Does:

• Proves the signing domain controls the private key.
• Proves the signed parts of the message were not modified.
• Survives forwarding because the signature travels with the message.
• Allows DMARC to use the signing domain as the authenticated identity.

Does not:

• Encrypt the message — DKIM is signing only.
• Authenticate the sender to the receiver if message was modified (e.g., footer added by a mailing list).
• Authenticate the visible From: header by itself — DMARC adds that alignment.
• Prevent compromise of the private key from leading to forged signatures.

Algorithm choice

For maximum compatibility, publish both an RSA-2048 selector and an Ed25519 selector. The sending server signs with both algorithms; receivers verify whichever they support.

DKIM and DMARC alignment

DMARC requires that the DKIM signing domain (d=) aligns with the From: header domain. Alignment can be:

• Relaxed (default): Organizational Domain match. From: news@mail.example.com aligns with d=example.com.
• Strict: Exact match. From: news@mail.example.com only aligns with d=mail.example.com exactly.

A DKIM signature that verifies but doesn't align provides no DMARC protection. Many transactional services sign with their own domain by default (e.g., d=sendgrid.net); the customer must explicitly enable DKIM signing with their own domain to get DMARC alignment.

Frequently Asked Questions

What is a DKIM selector?

A selector is a label that lets one domain have multiple DKIM keys simultaneously. The DKIM-Signature header includes s=selector and the receiver fetches the public key from DNS at selector._domainkey.domain. Multiple selectors enable key rotation (publish new selector, transition signers, then remove old selector), separate keys per sending service, and per-environment keys. Names are arbitrary; common conventions are 'mail2026', 's1', 'google', 'sendgrid', etc.

What key length should DKIM use?

2048-bit RSA is the current standard. 1024-bit RSA was the original recommendation but is now considered weak and is downgraded or rejected by major receivers. Ed25519 (RFC 8463) provides equivalent security with shorter keys and faster signing, but support is not universal — about 80% of major receivers verify Ed25519 in 2026. For best compatibility, publish both an RSA-2048 and an Ed25519 selector.

Why does DKIM survive forwarding when SPF does not?

DKIM signs the message body and selected headers — the signature travels with the message wherever it goes. As long as no intermediary modifies what was signed, the signature still verifies at the final recipient. SPF, by contrast, checks the connecting IP against a static authorized list; when a forwarder relays the message from its own IP, that IP is not in the original sender's SPF, so SPF fails. DMARC requires only one of SPF or DKIM to pass — DKIM's forwarding survival is why it's the more robust mechanism.

What breaks a DKIM signature?

Any modification to the signed content. Common culprits: mailing-list software adding [List-Name] to subject lines, antivirus gateways appending disclaimer footers, signature appenders adding "sent from my iPhone," forwarders that rewrite addresses. The body hash check fails when bytes change. RFC 8617 (ARC, Authenticated Received Chain) was designed to let intermediaries vouch for the original authentication results across these modifications, but ARC support is partial.