RFC 6376 / START HERE
DKIM mail signatures, before the details
DKIM: DomainKeys Identified Mail
DKIM lets a domain attach a digital signature to selected parts of an email. Receivers use a public key published in DNS to check that signature.
The idea in one picture
A domain signs outgoing mail
DNS publishes the public key
A receiver verifies the signature
A simplified picture of the idea; the chapters explain the actual mechanisms.
Why it exists
Mail recipients need a way to check a domain's responsibility for a message and detect changes to signed content. A signature alone does not establish that a message is safe.
A familiar example
A mail provider signs outgoing mail with its domain's key; the recipient's server checks the signature.
Helpful background
You can start here without reading another RFC. If these ideas are unfamiliar, these short introductions may help.
What you’ll learn next
Begin with chapter one, or choose a topic.
- Signing domain and selectorThe signature identifies a signing domain and a selector for its DNS public key.→
- CanonicalizationSimple and relaxed algorithms define which message formatting changes affect the signed bytes.→
- Body hash and selected headersA body hash is included in the signed DKIM header, which is itself included in the signature calculation.→
- DNS key verificationThe receiver resolves the selector under the signing domain and verifies the signature.→
- Mutation and trust limitsForwarding and list transformations can preserve or break signatures depending on which data change.→
This introduction explains RFC 6376 (2011). Read the original RFC ↗