English Nederlands Español Italiano 日本語 Français
Log in

DKIM Guidelines

DKIM (DomainKeys Identified Mail) is a free technology that cryptographically links an email back to the domain that sent it. The sending server signs the message with a private key; the receiving server checks that signature against a public key published in DNS.

Think of it like a wax seal on an envelope

DKIM is like a wax seal on an envelope: it proves the message wasn’t tampered with after it was sent, and it proves who sealed it. Break the seal — change the content — and the check fails.

Why it matters

DKIM proves two things at once: that a message genuinely came from the domain it claims to, and that its content wasn’t altered in transit. Unlike SPF, a DKIM signature survives forwarding — it travels with the message itself rather than depending on which server relayed it — which makes it a more resilient authentication signal, and the other half of what DMARC checks.

How it works

When a message is sent, the outbound mail server signs it using a private key that only that domain controls. The receiving server looks up the matching public key in a DNS TXT record (published under a “selector”, so a domain can have several key pairs for different services) and verifies the signature. If anything in the signed content changed after signing, verification fails.

I need more information

The plain-language version above covers what most people need. The rest of this article is the detailed reference: system parameters, which headers to sign, key rotation, and delegating DKIM to external vendors.

General

  • DKIM public key records are published as DNS TXT records, limited to 255 characters per string (multi-string TXT records can chain several together).
  • DKIM record syntax should be validated before publishing — check with tooling, and watch out for encoding errors introduced by copy-pasting.
  • DKIM public key records are case-sensitive.
  • DKIM signing should happen on the last mail server (MTA) before a message leaves your infrastructure.
  • DKIM selectors let you map different key pairs to different services or suppliers sending on your behalf.
  • DNS CNAME records can centralise DKIM public key management, and let you delegate DKIM public keys to external senders (see “External vendors” below).

Configuration

  • Algorithm: rsa-sha256, per RFC 6376.
  • Canonicalization: headers relaxed, body simple.
  • Always include the DKIM signature timestamp (t= in the DKIM header), which records when the signature was created.
  • Key size should be at least 1024 bits; 2048 bits is recommended. A 1024-bit key fits in a single DNS TXT record; a 2048-bit key needs a multi-string TXT record.
  • Don’t set the l= parameter (body length count) — it can leave messages open to modification after signing.
  • Always define the DKIM version, v=DKIM1 (RFC recommended), and your key type, k=rsa (RFC optional, but it affects how the p= public-key data is read).
  • Use the n= note parameter to record extra context about the key, such as its size and activation date, e.g. n=2048,201709-1519.
  • Don’t set the DKIM test flag (t=y;) on a public key that’s actually in production use.

Which header fields to sign

Sign at least: From, To, Reply-To, Subject, Date, Message-ID, List-Unsubscribe, MIME-Version, and Content-Type.

Don’t sign: Return-Path, Received, or free-text Keywords/Comments fields, since these can legitimately change in transit.

Security

  • Consider signing From, To, and Subject twice, to make it harder to tamper with these specific fields (e.g. h=From:From:To:To:Reply-To:Subject:Subject:Date:Message-ID:List-Unsubscribe:MIME-Version:Content-Type;).
  • Use unique key pairs per domain, and ideally per sender, so a single key can be revoked without affecting other mail flows.
  • Rotate keys regularly. As hardware gets faster, reverse-engineering an older private key becomes more feasible over time. Rotate at least twice a year, with an overlap period of two weeks to 30 days while both the old and new key are valid, then retire the old key. For higher-importance mail flows (including third parties sending on your behalf), rotating four times a year is preferable.
  • Domains that don’t send, or shouldn’t send, email should not publish DKIM public keys at all.

External vendors

If a vendor runs a DKIM-signing gateway on your behalf but doesn’t have direct control over your DNS zone, use a DKIM CNAME so you keep control of the public key, ideally pointing at a DNS zone the gateway operator does control directly.

Example: a gateway operator (example.net) signs mail for a customer domain (sample.com). The signature shows d=sample.com, but the public keys live under a subdomain of example.net. Two selectors are set up so key rotation can happen without downtime:

  • On sample.com‘s DNS: <vendor>-selector1._domainkey.sample.com (CNAME) → sample-com-selector1.dkim.example.net
  • On sample.com‘s DNS: <vendor>-selector2._domainkey.sample.com (CNAME) → sample-com-selector2.dkim.example.net
  • On example.net‘s DNS: sample-com-selector1.dkim.example.net (TXT) → v=DKIM1; k=rsa; p=<...>; n=<keysize>,<date>
  • On example.net‘s DNS: sample-com-selector2.dkim.example.net (TXT) → v=DKIM1; k=rsa; p=<...>; n=<keysize>,<date>

With this in place, the gateway operator owns DKIM key management end to end, including rotation, without needing further DNS changes on your side.

References & further reading

  • RFC 6376 – DomainKeys Identified Mail (DKIM) Signatures: rfc-editor.org/rfc/rfc6376, updated by RFC 8301 (key size and algorithm requirements) and RFC 8463 (Ed25519 signatures).
  • M3AAWG DKIM Key Rotation Best Common Practices, and M3AAWG’s best practices for implementing DKIM to avoid key-length vulnerabilities.