The short version

DKIM (DomainKeys Identified Mail) adds a signature to each message. The sending server signs with a private key; the receiver checks the signature with the public key you publish in DNS. If it checks out, the message came from a server holding your key and wasn’t changed on the way.

What it looks like

The signature travels in a DKIM-Signature header. Two of its tags matter most:

  • d= is the signing domain: whose key signed it.
  • s= is the selector: which of that domain’s keys.

The public key is a TXT record at <selector>._domainkey.<domain>:

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

A domain can have many selectors, one per service or per key, so you can rotate keys and add services without touching the others. DNS has no way to list them; find a selector in the s= tag of a message you sent.

Why DKIM matters most for DMARC

DMARC passes on DKIM when the signature checks out and its d= domain matches your From domain. A service that signs with its own domain passes DKIM for itself, not for you; setting it up to sign with yours is usually a few CNAME or TXT records in your DNS.

Unlike SPF, a DKIM signature survives forwarding as long as the message isn’t modified, which is why it’s the more reliable way to pass DMARC.

Keys

  • Use 2048-bit RSA keys. Shorter keys are weak (RFC 8301). Long keys may need splitting into several strings in one TXT record; most DNS consoles do this for you.
  • Rotate them. Publish a new key under a new selector, switch signing to it, then remove the old one.
  • An empty p= revokes a key. Mail still signed with it fails.

Next steps

  1. Check a selector with the DKIM Inspector, or a key before you publish it with the DKIM Validator.
  2. Set up DKIM with your domain for each service that sends as you; see the setup guides.