What Is DKIM?

The sending server signs selected headers and the message body with a private key and attaches the result as a DKIM-Signature header. The receiving server reads the domain and selector from that header, fetches the matching public key from DNS, and recomputes the signature.

A match proves two things at once: the message was signed by someone holding the private key for that domain, and nothing covered by the signature changed on the way. A mismatch usually means the message was modified in transit rather than that it was forged.

A selector is a label that lets one domain publish several keys. The public key lives at selector._domainkey.yourdomain.com, so a provider using the selector google publishes at google._domainkey.yourdomain.com.

Selectors are what make key rotation possible without downtime. A new key is published under a new selector, sending switches to it, and the old selector is removed once no signed mail is still in flight.

The header carries the whole verification instruction. The d tag names the signing domain and the s tag the selector, so the receiver can build the DNS name to query. The h tag lists which headers were covered, bh holds a hash of the body, b holds the signature over the headers, and a records the algorithm, which on current mail is rsa-sha256 since SHA-1 was retired.

Before any of that is computed the signer canonicalises the message, a normalisation step that decides how much harmless reformatting a signature can survive. Relaxed canonicalisation tolerates whitespace changes and refolded headers; simple tolerates none. A message that verifies on one route and fails on another has usually crossed a gateway that reformatted it in a way the chosen canonicalisation does not forgive.

Tags rather than prose. The TXT record published at the selector name reads v=DKIM1 to declare the version, which is optional but must come first when present, k=rsa to state the key type, and p= carrying the public key as base64 text, which is nearly the entire length of the record.

An empty p value is not a broken record. RFC 6376 defines it as an explicit revocation, so a selector left published with nothing after p= tells receivers the key is dead rather than missing. Two TXT records at the same selector name are the real breakage, because the lookup becomes ambiguous and verification fails outright.

Forwarding changes the sending server, which breaks SPF because the new server is not in the original record. A DKIM signature survives forwarding as long as the forwarder does not alter the signed headers or body, so it is often the only check that still passes.

That is the practical reason to publish both. DMARC accepts either an SPF pass or a DKIM pass, provided the passing domain aligns with the From address, so DKIM keeps legitimate forwarded mail from failing policy.