DKIM email signatures

What it means

For a DKIM check, the verifier uses the signing domain and selector to find a public key, then checks the canonicalized material covered by the signature. A selector is a key identifier, not a privileged literal such as mail. 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.

A DKIM selector rotation

Imagine a signed message with d=example.com and s=m2. The verifier looks for public-key material at m2._domainkey.example.com. If the matching-key fixture is available and the canonicalized signed material remains unchanged, the synthetic result is pass. Choosing s=mail would simply choose a different DNS key location; neither selector name has special verification powers.

Now change signed bytes: verification fails even if the selected key is still matching. If the key is unavailable, the toy verifier reports that it cannot complete the check rather than claiming it has proved a bad signature. A DKIM pass proves the chosen signing-domain assertion within DKIM's protocol rules; a different visible From domain still needs a separate DMARC alignment decision. No real keys are loaded into this page.

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.