DKIM email signatures

What it means

DKIM lets a signer attach a cryptographic signature that receivers can verify using a public key published in DNS. The signature authenticates selected message content and the signing domain (d=), not necessarily the human-visible From domain or the sender’s good intent. Key selection uses the DKIM selector and signing domain. DKIM standard Algorithm guidance

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.

Valid signature, wrong identity for DMARC

Suppose a message with From receipts.example.test carries a valid DKIM signature with d=another.test. Verification can legitimately pass for that signer, but DMARC alignment with the visible From domain is a different question. Another message could keep the same From domain but alter a signed header or body, causing DKIM verification to fail. The selector in s= chooses a DNS key under _domainkey for the signing domain; it is not a prescribed mailbox name, and rotating keys requires overlapping deployment considerations. DKIM identifiers Key security

In practice

For an authorized sender, inventory signing systems, selectors, public-key DNS records and private-key custody. Verify a representative message’s signature, canonicalized fields and alignment separately. Stop before deleting an old selector used by in-flight mail. Do not place private keys into public TXT records, tickets or educational input fields.

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

DKIM answers whether a specified signer’s selected message data verified. It does not itself decide From-domain alignment, recipient trust or delivery acceptance.