← Glossary

Protocols & Acronyms

DKIM (DomainKeys Identified Mail)

Also: DomainKeys Identified Mail · DKIM signature · DKIM selector · _domainkey · v=DKIM1

Last reviewed:

In one sentence

DKIM is a cryptographic signature a mail server adds to each outgoing message, verifiable through a public key published in DNS, proving the message was authorised by the signing domain and not altered in transit.

Why it matters

SPF answers "did this come from an allowed IP?". DKIM answers a better question: "did the domain that claims to have sent this actually sign it, and is it unchanged?" Because the proof travels inside the message rather than depending on the connecting IP, DKIM survives forwarding and mailing lists, and it is the mechanism most receivers weight most heavily when deciding whether a message is genuine.

It is also what makes DMARC practical. A DMARC pass needs SPF or DKIM to pass and align with the visible From: domain; for anything that goes through a forwarder, DKIM is the only one that can.

How it works

The sending server hashes selected headers and the body, signs the hash with a private key, and adds a header:

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=example.com; s=s2026;
    h=from:to:subject:date:message-id; bh=3f2L…=; b=Kq8s…=
  • d= the signing domain, s= the selector. Together they tell the receiver where to look: the TXT record at s2026._domainkey.example.com.
  • h= which headers were signed (always include From); bh= the body hash; b= the signature itself.
  • c= canonicalisation — relaxed tolerates whitespace changes in transit, simple does not.

The DNS side:

s2026._domainkey.example.com.  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A…"

Selectors let a domain publish several keys at once — one per sending service, or an old and a new one during rotation. Keys should be 2048-bit RSA (1024 is considered weak; some registrars need the long record split into 255-character strings) or Ed25519 where the receiver supports it. Publishing p= empty revokes a selector. The result appears in Authentication-Results as dkim=pass header.d=example.com, or fail (signature does not verify — tampered or wrong key), none (no signature), temperror/permerror.

Try it yourself hands-on

An employee reports an invoice e-mail that "looks like it came from our supplier". You want to know whether the supplier's domain signed it.

  1. Get the raw headers (in most clients: Show original / View source) and paste them into the Email Header Analyzer. It walks the Received: chain and reads the authentication headers. Look at two lines: the DKIM-Signature d= value, and the receiving server's Authentication-Results.
  2. Case A: d=supplier.example and dkim=pass, and the visible From is @supplier.example. The message was signed by the supplier's own infrastructure. That does not make the invoice legitimate — a compromised mailbox signs perfectly — but it rules out plain spoofing; the next call is to the supplier.
  3. Case B: d=mail-blast.example (a bulk sender) and dkim=pass, but From is @supplier.example. The signature is valid but for a different domain: no alignment. If the supplier publishes DMARC with p=reject, this should never have been delivered; the analyzer will show the dmarc= result too.
  4. Case C: dkim=fail. Either the body was modified after signing (some gateways add a footer — check c=) or it is forged. Combined with a mismatched Return-Path, treat as phishing.
  5. Check the supplier's key yourself with the DNS Record Lookup: TXT for <selector>._domainkey.supplier.example. A missing record for a selector that appears in the header is the signature of an attacker guessing selectors.

Setting up your own? The Email Auth Record Builder formats the DNS record from a public key and splits it into 255-byte chunks for providers that need that; the Email Security Checker confirms the published record parses.

Common misreadings

  • DKIM does not stop spam or phishing by itself. Attackers sign their own domains too. Its value is proving identity and integrity for the domain it names — DMARC turns that into policy.
  • Every sending service needs its own selector. The CRM, the helpdesk, the newsletter tool: each signs with its own key, and each needs a DNS record, or their mail fails DMARC.
  • Rotate keys. A private key that has lived on a mail server since 2017 is a liability; publish the new selector, switch signing, retire the old record after a few days.