RFC 6376 — DKIM

RFC 6376 defines DKIM, the cryptographic signature attached to outgoing messages. It is a full Internet Standard — a higher maturity level than either SPF or DMARC, both of which are Proposed Standard.

What the document governs

• The DKIM-Signature header, including the d= signing domain and the s= selector that names which public key to fetch.
• Key publication in DNS, under <selector>._domainkey.<domain> — including that an empty p= is the documented way to revoke a key rather than a broken record. RSA keys are specified here; RFC 8463 later added Ed25519, whose keys are short enough to avoid the split-string problem a 2048-bit RSA key creates in DNS.
• Canonicalization, the rules for normalising a message before signing, which is why a signature survives some transformations in transit and not others.

What a signature proves, and what it does not

It proves some domain holding the private key took responsibility for the message, and that the signed parts were not modified. That is all.

It does not prove the message came from the domain in the From: header — the d= domain can be anything with a published key. This is why a dkim=pass from your email provider’s own domain does nothing for your DMARC result, and why alignment is the thing to check.

Unlike SPF, DKIM survives most forwarding, which makes aligned DKIM the sturdier of the two ways to satisfy DMARC — though a list that rewrites a message will still break it, which RFC 6377 addresses.

Selectors, and why there can be several

The s= tag names which key to use, which is what lets one domain publish many keys at once. Your mailbox provider, marketing platform and helpdesk each publish their own under their own selector, and they do not collide.

For DMARC, only one signature has to verify and align. A message signed by three services passes on the strength of whichever signature aligns with the From: domain; the others failing is irrelevant.

This is also how rotation works without downtime — publish a new key under a new selector, switch signing to it, retire the old one once the last message signed with it has been delivered.

Where DKIM breaks

Canonicalization decides how much a message can change in transit before the signature stops verifying. relaxed tolerates whitespace and header-case changes; simple tolerates almost nothing. Mailing lists that append a footer or rewrite a subject line will break a signature under either, which is the single most common source of DMARC failures on legitimate mail.

Read it: rfc-editor.org/rfc/rfc6376