What it means
DKIM lets a signing domain take responsibility for selected parts of a message. The sender adds a signature. The receiver retrieves the public key from DNS, under the selector the signature names, and checks that the signed headers and body still match. A valid signature associates that signing domain with the signed content. It does not prove that the display name is honest or that a particular person composed the text.
RFC 6376 is Internet Standard STD 76, September 2011. It obsoletes RFC 4871 and RFC 5672. The signature’s domain can differ from the domain in the visible From. When they differ, keep both names in the note. A stolen sending key or a compromised mailbox can produce a signature that verifies. Verification is a cryptographic association, not a judgment of the request inside the message.
See the idea / Email
The signature travels. The private key stays.
A receiver gets a signed message and the domain’s public key, then checks the body hash and header signature.
Illustrative copy: From finance@chronos.orbital; body “Total: $20”. One signature uses d=chronos.orbital and s=post. Its public key was already published at post._domainkey.chronos.orbital.
01 / 04
Signed copy
The signing service sends its original message with a DKIM signature. Its private key stays with the signer; the receiver gets the message and signature.
More about this step
One valid key and signature; simple/simple canonicalization. Key errors, other headers, and multiple signatures are omitted. The signature covers the canonicalized From header, the DKIM-Signature header with b= empty during hashing, and a hash of the entire canonicalized body. The key and signature are drawn as labels, not complete cryptographic values.
Step through at your own pace.
Keep in mindValid DKIM does not identify a person or make content safe. One signature, From and full body signed; alignment and delivery decisions omitted.
Read the visual, step by step
- Signed copy. The signing service sends its original message with a DKIM signature. Its private key stays with the signer; the receiver gets the message and signature. One valid key and signature; simple/simple canonicalization. Key errors, other headers, and multiple signatures are omitted. The signature covers the canonicalized From header, the DKIM-Signature header with b= empty during hashing, and a hash of the entire canonicalized body. The key and signature are drawn as labels, not complete cryptographic values.
- Public key. Using d=chronos.orbital and s=post, the receiver requests the already published public key from post._domainkey.chronos.orbital. The DNS reply returns to the receiver. The corresponding public key is published before sending. The signer does not send its private key or publish a new public key for each message. The diagram omits the recursive resolver and DNS failure cases.
- Check. The receiver recomputes the body hash and verifies the header signature with the public key. Both checks succeed for the original copy, so this signature validates. Only after the checks finish does this example report valid DKIM for chronos.orbital. That says nothing about whether finance intended the message or whether the payment instruction is safe.
- Altered copy. Compare a copy changed to “Total: $900” after signing, with the same signature and public key. Its body hash mismatches, so this signature fails. This is a separate altered copy; the earlier original stays valid. The changed bytes survive simple canonicalization and the signature covers the whole body. This receiver stops at the body-hash failure, so the header-signature check is not needed.
Valid DKIM does not identify a person or make content safe. One signature, From and full body signed; alignment and delivery decisions omitted.
Flow references: RFC 6376: DKIM key retrieval and verification
AN ILLUSTRATIVE SCENARIO
A signature on a Meridian Mail notice
Meridian Mail signs customer notices with a key published for chronos.orbital. Vera records the signing domain and that the signature verified. The display name still says “Meridian Finance,” which is a label in the header, not the signing domain. She does not tell Sloane the signature proves a clerk typed the wire instructions.
Put it to work
- Identify the signing domain and selector on a message you are allowed to inspect, then confirm the public key is the one that domain publishes in DNS.
- Note which content the signature covers and whether verification succeeded. Keep the visible From domain as a separate field.
- If you operate the domain, rotate keys on a plan and remove selectors you no longer use. A forgotten selector is still a key.
How to check your work
On a synthetic signed message, write the signing domain, whether verification succeeded, and one claim the signature does not make about the person or the display name.
Connect the ideas
- DNS
The lookup system that maps a name people type to an address a computer can contact.
- SPF
A DNS policy that says which hosts may use a domain in the MAIL FROM or HELO identity. A pass authorizes that host for that identity. It does not prove the visible From address or a person’s intent.
- DMARC
A DNS policy that checks whether the visible From domain aligns with a domain SPF or DKIM authenticated, and that publishes a handling preference plus reporting. A pass is authorized use of that domain, not a safety verdict.