DKIM — Signing and Verification

DKIM (DomainKeys Identified Mail) proves a message wasn't altered in transit and really was sent by something holding a specific private key – using actual cryptographic signatures, not just a list of allowed servers.

How it works

1. The sending server holds a private key and signs each outgoing message, adding a DKIM-Signature header containing that signature plus metadata (which fields were signed, which domain is signing, which selector to use).
2. The corresponding public key is published in DNS, at a specific hostname built from a selector:

google._domainkey.example.com   TXT   "v=DKIM1; k=rsa; p=MIGfMA0G..."

3. The receiving server looks up that public key and verifies the signature. If the message was altered in transit, or the signature doesn't match, verification fails.

The d= tag is the whole point – and its limit

The signature's d= tag names the signing domain – the domain vouching for the message. This is what DKIM actually proves: "the holder of this domain's private key signed this exact content." It does not independently prove that the signing domain matches whatever the visible From: header says. A message can carry a perfectly valid DKIM signature from one domain while the header From: shows a completely different one – DKIM alone has no opinion about whether those should match.

Once again: that's DMARC's job, covered next.

Key rotation matters

A DKIM key that's never rotated is a long-lived cryptographic secret with no expiry built into the protocol. If a private key is ever compromised, every message it can sign is trivially spoofable until the key is rotated and the old public key is pulled from DNS. Most major providers rotate on a schedule automatically; if you manage your own mail infrastructure, treat DKIM keys like any other credential with a rotation policy.

Run ActiScan's DKIM checker against your own domain's selector to confirm the record actually resolves and parses correctly.