DKIM Signing

DKIM (DomainKeys Identified Mail) attaches a cryptographic signature to outgoing email. A receiver can verify that signature to confirm two things:

• The message was genuinely authorized by the signing domain
• The signed content was not altered in transit

Where SPF authorizes servers, DKIM authenticates the message itself, and that signature survives forwarding.

DKIM relies on asymmetric cryptography. The domain owner holds a key pair:

• The private key stays secret on the sending mail server and is used to sign
• The public key is published in DNS and is used by anyone to verify

Because only the holder of the private key can produce a valid signature, a successful verification proves the message came from the legitimate domain.

When the sending server dispatches a message, it computes a signature over selected headers and the body, then adds a DKIM-Signature header.

The DKIM-Signature header carries the parameters a receiver needs to verify:

The selector (the s= tag) tells receivers which public key to fetch. The key lives at a predictable DNS location:

On receipt, the verifying server reverses the process:

• Read the d= domain and s= selector from the DKIM-Signature
• Fetch the public key from selector._domainkey.domain in DNS
• Recompute the body hash and header hash
• Use the public key to verify the signature matches

If the signature is valid, DKIM passes. If the message was modified or signed with the wrong key, it fails.

The bh (body hash) field is what makes DKIM tamper-evident. The sender hashes the body and includes that hash in the signed data.

If anyone alters the message body in transit, the receiver's recomputed hash will not match the signed bh, and verification fails. This is how DKIM provides integrity, not just origin authentication.

Mail servers along the way often make tiny, harmless changes, rewrapping lines or adjusting whitespace. To prevent these from breaking valid signatures, DKIM uses canonicalization (the c= tag).

• simple — strict; almost any change breaks the signature
• relaxed — tolerant of whitespace and header-case changes

Most deployments use relaxed/relaxed for reliability across diverse mail infrastructure.

Selectors are not just labels, they enable safe key rotation. You should periodically replace DKIM keys to limit exposure if one leaks.

Rotation process:

• Generate a new key pair with a new selector (e.g. mail2025)
• Publish the new public key in DNS
• Switch the signer to use the new selector
• Leave the old selector in DNS until in-flight mail is delivered, then remove it

Using a fresh selector avoids a gap where signatures cannot be verified.

Unlike SPF, DKIM survives forwarding. The signature travels with the message, so as long as the signed headers and body are not modified, a forwarded message still verifies.

This complements SPF's weakness perfectly. When a message is forwarded, SPF may fail because the connecting IP changed, but DKIM can still pass, allowing DMARC to accept the legitimate mail.

DKIM is powerful but not complete on its own:

• It proves a domain signed the message, but does not enforce that the signing domain matches the visible From header, that is DMARC alignment
• An attacker can sign mail with their own domain's valid DKIM key
• A leaked private key lets an attacker forge valid signatures until the key is rotated out

DKIM must be combined with DMARC to be meaningful against spoofing.

Test your understanding of DKIM.

You learned how DKIM signs messages:

• DKIM attaches a cryptographic signature proving origin and integrity
• A private key signs on the server; the public key is published in DNS under a selector
• The body hash detects tampering; canonicalization tolerates harmless changes
• Selectors enable safe key rotation, and DKIM survives forwarding where SPF fails
• DKIM still needs DMARC alignment to tie the signature to the visible From

Next, you will tie SPF and DKIM together with DMARC policy and reporting.