DKIM (DomainKeys Identified Mail) is an email authentication standard in which a sending domain attaches a cryptographic signature to each message, and receiving servers verify that signature with a public key published in DNS. In email infrastructure, DKIM proves that a message was authorized by the signing domain and that the signed headers and body were not altered in transit.
DKIM is defined in RFC 6376 and works alongside SPF and DMARC. Unlike SPF, which checks the connecting server, DKIM travels with the message itself, so its result usually survives forwarding through intermediate relays.
How DKIM signs and verifies a message
DKIM works through a sign-then-verify cycle between the sending mail transfer agent and the receiving server. The sender computes a hash of the canonicalized body, hashes the selected headers together with that body hash, and signs the result with a private key that never leaves its infrastructure.
The signature is inserted as a DKIM-Signature header. The receiver reads the domain tag d= and the selector tag s=, then fetches the public key from the TXT record at selector._domainkey.domain. If the recomputed hashes match the signed values, the result is dkim=pass.
The following table lists the most important tags of the DKIM-Signature header and what each one controls.
| Tag | Meaning | Typical value |
|---|---|---|
| v= | Specification version | 1 |
| a= | Signing algorithm | rsa-sha256 or ed25519-sha256 |
| d= | Signing domain | example.com |
| s= | Selector naming the key | mail2026, s1 |
| c= | Header and body canonicalization | relaxed/relaxed |
| h= | List of signed headers | From, To, Subject, Date |
| bh= | Hash of the canonicalized body | Base64 string |
| b= | The signature itself | Base64 string |
Keys, selectors and canonicalization
A selector lets one domain publish several keys at once, for example one per sending platform or one per rotation period. This makes key rotation possible without downtime: a new selector is published, signing switches to it, and the old record is removed after messages in flight have been delivered.
Key strength matters. RSA keys of 2048 bits are the current baseline, while 1024-bit keys are considered weak and some receivers treat them with suspicion. Ed25519 signatures are standardized in RFC 8463, but support is uneven, so senders that use them usually dual-sign with RSA as well.
Canonicalization defines how tolerant verification is to harmless changes. The table compares the two modes, which can be set separately for headers and body.
| Mode | What it tolerates | Practical effect |
|---|---|---|
| Simple | Almost no changes | Breaks on rewrapped or re-spaced content |
| Relaxed | Whitespace and header case changes | Survives most relays and gateways |
| Relaxed/relaxed | Both headers and body relaxed | Most common production setting |
DKIM compared with SPF and DMARC
DKIM, SPF and DMARC answer three different questions, and a domain needs all three for reliable authentication. DKIM validates the message content and the signing domain, SPF validates the sending IP address, and DMARC ties the results to the visible From domain.
| Method | What it checks | Survives forwarding | Published in DNS as |
|---|---|---|---|
| DKIM | Signature over headers and body | Usually yes | TXT key at selector._domainkey |
| SPF | Authorized sending IP addresses | Usually no | TXT record at the domain |
| DMARC | Alignment and receiver policy | Depends on DKIM or SPF | TXT record at _dmarc |
A crucial nuance is alignment. DKIM alone does not prove anything about the From address a reader sees; a spammer can sign with their own domain and pass DKIM. Only when the d= domain aligns with the From domain does DKIM contribute to a DMARC pass.
Deploying DKIM in practice
Deployment starts with an inventory of every system that sends mail for the domain: the main mail server, marketing platforms, ticketing tools and invoicing services. Each one must either sign with a key under the organization’s domain or be moved to a subdomain with its own selector.
| Situation | Recommended choice | Reason |
|---|---|---|
| Third-party newsletter platform | Delegate a selector via CNAME | Provider rotates keys without DNS edits |
| Self-hosted mail server | 2048-bit RSA, relaxed/relaxed | Broad compatibility and tolerance |
| Several sending systems | One selector per system | Isolated rotation and revocation |
| Key suspected compromised | Publish new selector, empty old key | An empty p= tag revokes the key |
| Long TXT record rejected | Split into quoted 255-character strings | DNS string length limit |
Operators should sign at least the From, Subject, Date, To and Message-ID headers and protect From against later insertion by listing it twice in h=, a technique called oversigning. Rotating keys every six to twelve months is a common practice.
Limitations and common failure modes
DKIM verifies integrity and domain responsibility, not trustworthiness. A valid signature from a newly registered lookalike domain still passes, so receivers combine DKIM with reputation and content filtering.
- Mailing lists break signatures when they add footers or subject tags; ARC was designed to carry the original result across such hops.
- The l= body length tag allows content to be appended after the signed part and should be avoided.
- Replay attacks reuse a validly signed message to send spam at scale; DKIM cannot prevent them by itself.
- Expired or missing DNS records cause sudden dkim=fail results after a provider change.
- Signing with the provider’s domain passes DKIM but fails DMARC alignment.
In plain words
DKIM is like a tamper-evident seal on a letter. The sending company stamps each email with a seal that only it can make, and anyone can check the seal using a public sample the company posts in its domain records.
If the letter was changed on the way, or the seal was forged, the check fails. A good seal proves who sent it and that nobody altered it, but it does not prove the sender is honest.
A real-world example
A mid-sized online retailer sends order confirmations from its own mail server and promotional newsletters through an external marketing platform. Customers report that newsletters land in spam, and DMARC aggregate reports show the platform signing with its own domain instead of the retailer’s.
The administrator creates a CNAME record for the selector mkt1._domainkey pointing to the platform’s key, enables custom-domain signing, and generates a new 2048-bit key with relaxed/relaxed canonicalization for the main server under selector s2026.
Within a week the reports show aligned DKIM passes for both sources, and the retailer can move its DMARC policy from monitoring to quarantine without losing legitimate mail.