What a DKIM signature proves

SPF authorises a host. DKIM does something different: it attaches a cryptographic signature to the message itself, so the claim travels with the message rather than depending on where it happens to be coming from at the moment.

The mechanics, without the maths

• The domain owner generates a key pair.
• The public half is published in DNS. The private half stays on the sending system.
• When a message is sent, the sending system hashes the body and a chosen set of headers, signs that hash with the private key, and adds the result as a DKIM-Signature header.
• The receiver reads the signature, finds out from it which domain and which key to use, fetches that public key from DNS, and checks the signature.

Specified in RFC 6376. No prior arrangement between sender and receiver is needed — the receiver learns everything it needs from the message and from DNS.

What a valid signature proves

Note the shape of that. It is a statement about a domain taking responsibility, not about who wrote the message and not about the message being wanted. A spammer can sign their own mail perfectly, and a valid DKIM signature on a phishing message means only that the phisher controls the signing domain.

What it does not prove

• That the signing domain is the domain in the From header. These are separate fields and are frequently different — this is exactly the gap alignment exists to close, two modules from now.
• That the whole message is intact. Only the signed headers and the body covered by the hash. Headers not listed in the signature can be added or altered freely without breaking anything.
• That the message is trustworthy. Signing is free and anyone can do it for their own domain.

Why DKIM survives what SPF does not

This is the practical reason to deploy both. SPF’s evidence is the connecting IP address, which is a property of the current hop. The moment a message is forwarded, the hop changes and the evidence is gone.

DKIM’s evidence is inside the message. A forwarded message that arrives unmodified carries a signature that still verifies, from the original domain, at a server several hops downstream.

alice@example.com  ──►  recipient.org  ──forwards──►  gmail.com

  SPF at gmail.com:   checks recipient.org's IP against example.com's
                      SPF record. Not listed. FAILS.

  DKIM at gmail.com:  verifies example.com's signature on the message.
                      Still valid. PASSES.

That asymmetry is why a domain with only SPF has a much harder time reaching DMARC enforcement than one with both: forwarded mail is common, and without DKIM there is nothing left to pass.