DKIM email signatures

What it means

DKIM (DomainKeys Identified Mail) associates a signing domain with selected canonicalized email headers and message content through a cryptographic signature. A DKIM-Signature carries a signing domain (d=) and selector (s=); verification retrieves an appropriate public key, normally from s._domainkey.d in DNS. A signature can validate for a domain different from the visible From author. DKIM authenticates signing responsibility and integrity of signed material; it does not encrypt mail.

Try it

Simulation — follow a synthetic DKIM verification. Use d=example.com, selector mail and matching public-key fixture. Modify signed bytes or select an unavailable key to see why verification no longer succeeds. Set visible From to another domain: DKIM can still validate independently, although DMARC alignment is another question. Choose Verify fixture, explore the two steps and Reset. No real private keys or mail are involved.

How the mechanism works

The verifier reads algorithm, canonicalization, signed-header list and body hash metadata, obtains a key by selector and signing domain, and checks a signature over canonicalized data. Canonicalization exists because certain harmless transport changes should not automatically invalidate signatures; changes that affect signed canonicalized bytes can invalidate them. Whether a particular edit matters depends on the actual canonicalization and signed components, not a universal rule that any whitespace change always breaks DKIM.

Selectors support key rotation and delegation of signing operations. A sender can publish distinct public keys under multiple selectors while gradually rotating active signatures. Missing or incorrect key material can lead to nonverification. An attacker is not prevented from signing mail with a domain they themselves control; recipients also need alignment/policy context when interpreting the author identity.

Primary protocol documentation provides the underlying rules; the interactive state is only a synthetic illustration.

In practice

For operational review, inspect an actual received message's sanitized Authentication-Results and DKIM-Signature fields without copying private or personal content into support systems. Identify d, s, signed headers and DNS lookup name; compare to the authorized sender's configuration. Verify key lifecycle through official platform documentation, then test planned rotation with old and new selectors before removing a key. Stop if signatures fail unexpectedly or an unapproved platform requests a private key; recover by restoring the verified selector/record configuration.

Limits and common mistakes

The fixture uses predeclared cryptographic outcomes, not a real signature algorithm or canonicalizer. It intentionally omits MIME complexities, key strengths, replay conditions and domain alignment. A pass cannot be used as a production DKIM validator, and DKIM alone is not confidentiality or human identity assurance.

Key takeaways

A DKIM selector identifies a key lookup under the signing domain, while canonicalized signed bytes determine whether the signature still verifies. A passing signature authenticates the DKIM d= claim in its protocol scope; it need not align with the message author. Keep private signing keys out of browser demonstrations and public diagnostics.