Authentication

DKIMDomainKeys Identified Mail

Definition

DKIM (DomainKeys Identified Mail) is an email-authentication standard, defined in RFC 6376, that attaches a cryptographic signature to every message. The receiver fetches your public key from DNS and uses it to confirm the mail was authorised by your domain and that the signed parts arrived unaltered. It is one of the two checks that DMARC aligns, and it travels intact through most forwarding.

  • Proves a message was authorised by the signing domain and not tampered with in transit
  • The private key signs each message; the matching public key lives in a DNS TXT record
  • Unlike SPF, a valid DKIM signature usually survives forwarding
  • A passing signature still fails DMARC unless its d= domain aligns with the From: address
At a glance
Record type DNS TXT (public key)
Key location selector._domainkey.yourdomain.com
Defined in RFC 6376 (2011)
Signs with rsa-sha256 (SHA-1 prohibited)
Key length 2048-bit RSA recommended
Header added DKIM-Signature:

How DKIM works

DKIM is a public-key signature system bolted onto email. You generate a key pair: a private key that stays on your sending server and a public key that you publish in DNS. When a message goes out, your server hashes the body and a chosen set of headers, signs that hash with the private key, and writes the result into a new DKIM-Signature: header on the message.

On the receiving side, the server reads the signature header, notes the signing domain (d=) and the selector (s=), and looks up the public key at selector._domainkey.d-domain. It then recomputes the hashes and verifies the signature. If the maths checks out, two things are proven at once: the message was signed by someone holding the private key for that domain, and the signed content was not altered after signing. Because no certificate authority is involved, all the trust flows through your control of DNS.

Anatomy of a DKIM signature

The signature is a set of tag=value pairs added directly to the message header. A real one looks like this:

A DKIM-Signature header, with the body hash and signature truncated 
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
  d=example.com; s=mail2026; t=1718000000;
  h=from:to:subject:date:message-id;
  bh=2jUSOH9NhtVGCQWNr9BrIAPreKQjO6Sn7XIkfJVOzv8=;
  b=hG7s9k...truncated...AoQ==
  • v=1: version. Always 1.
  • a=rsa-sha256: the signing algorithm. SHA-256 is required; RFC 8301 prohibits the old rsa-sha1.
  • d=example.com: the signing domain claiming responsibility. This is the value DMARC aligns against your From:.
  • s=mail2026: the selector, which points at one specific public key so you can run several keys and rotate them.
  • c=relaxed/relaxed: the canonicalization (header / body), how tolerant the check is of whitespace and folding changes in transit.
  • h=…: the exact list of headers that were signed.
  • bh=…: the hash of the canonicalized body.
  • b=…: the signature itself, covering the headers in h= plus the body hash.

The public-key DNS record

The matching public key is published as a single TXT record at selector._domainkey.yourdomain.com. The selector in the record name must match the s= tag in the signature, which is how a receiver finds the right key.

A DKIM public-key record for the selector "mail2026" 
mail2026._domainkey.example.com.  IN  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEF...AQAB"

Why DKIM matters for sender reputation

Since February 2024, Google and Yahoo require every bulk sender (5,000 or more messages a day to their users) to authenticate with SPF and DKIM and publish DMARC. Microsoft applied the same baseline to high-volume senders into Outlook and Hotmail in 2025. DKIM is the half of that pairing that most reliably survives the real world: an aligned DKIM signature keeps passing DMARC even when a message is forwarded, where SPF usually breaks.

DKIM also anchors your domain reputation. Mailbox providers track sending behaviour against the stable d= domain in your signature, not the IP address you happen to use that day, so a consistently signed stream builds a track record you carry between IPs and providers. The current hygiene baseline is a 2048-bit RSA key signed with SHA-256, rotated periodically by publishing a new selector before retiring the old one.

How a DKIM signature is verified

Your server hashes the body and chosen headers and signs them with the private key
A DKIM-Signature: header is added and the message is sent
The receiver reads d= and s= and looks up the public key in DNS
Key found at s._domainkey.d No record: result is none
It recomputes the hashes and checks the signature with the public key
Signature valid and body unchanged: DKIM passes

DKIM vs SPF

DKIM SPF
What it checks A valid signature from the domain The sending IP is authorised
Mechanism Cryptographic signature + DNS key DNS list of IPs
Identity used The d= signing domain The Return-Path domain
Survives forwarding? Usually yes Usually no
Detects message tampering? Yes No

By the numbers

2048-bit
The RSA key length now recommended for DKIM; 1024-bit is considered weak and is being phased out.
SHA-256
The required signing hash. RFC 8301 prohibits the older rsa-sha1 for signing and verifying.
5,000+/day
The bulk-sender threshold at which Gmail and Yahoo require DKIM, since February 2024.

Common mistakes

Publishing a 1024-bit key
Short keys are weak against modern cryptanalysis and major providers are moving away from them. Generate a 2048-bit RSA key; if your DNS provider chokes on the long record, split the public-key string into chunks rather than shrinking the key.
Signing but never aligning
A valid DKIM signature on your ESP’s own domain passes DKIM yet still fails DMARC, because the d= domain does not match your visible From:. Sign with your own domain so the signature aligns.
Leaving SHA-1 selectors in place
Any record or signer still using rsa-sha1 is non-compliant with RFC 8301 and increasingly treated as a fail. Move every selector to rsa-sha256.
Deleting the old selector too soon
Rotating a key by removing the previous TXT record before mail signed with it has cleared the queue causes those messages to fail verification. Publish the new selector first, dual-sign, then retire the old record.

Frequently asked questions

What is the difference between SPF and DKIM?
SPF authorises which servers may send for your domain by checking the sending IP against a DNS list, tied to the Return-Path. DKIM cryptographically signs the message so receivers can confirm it was authorised by your domain and not altered. SPF tends to break on forwarding; a DKIM signature usually survives it. Most senders deploy both, then bind them to the visible From address with DMARC.
Why is my DKIM failing?
The usual causes are a selector mismatch (the record name does not match the s= tag), a public key that was truncated or pasted with line breaks in DNS, a key length or algorithm the receiver rejects, or a mail gateway that modified the body after signing so the body hash no longer matches. Check the published record with a DKIM lookup and confirm nothing rewrites the message in transit.
Does DKIM stop spoofing on its own?
No. DKIM proves a message carries a valid signature from some domain, but on its own it does not compare that domain to the From address your recipient sees, and an attacker can still send unsigned mail. DMARC is the layer that requires DKIM (or SPF) to align with the From domain and tells receivers to reject mail that does not.
How often should I rotate DKIM keys?
A common practice is every 6 to 12 months. Rotate by generating a new key under a fresh selector, publishing its public key, switching your signer to it, and only then removing the previous selector once mail signed with the old key has cleared.
Reviewed by Jennifer Jackson, Email Deliverability Analyst · June 2026 ← Back to glossary