DKIM

SPF verifies that a message came from an authorized server, but it says nothing about whether the message itself was tampered with after it left that server. DKIM fills this gap by attaching a cryptographic signature to every outgoing email that receivers can independently verify.

What is DKIM

DKIM uses public-key cryptography. The sending mail server signs each outgoing message using a private key, and the corresponding public key is published as a DNS TXT record. When the message arrives, the receiving server looks up the public key and uses it to verify the signature.

The signature covers specific headers and the message body, so any modification in transit — even a single changed character — causes verification to fail.

A DKIM DNS record is published at a selector-specific subdomain:

selector._domainkey.yourdomain.com

The selector is an arbitrary label (like s1 or clerk) that lets a domain use multiple DKIM keys simultaneously, which is useful when sending through multiple services.

How DKIM works

When a mail server sends an email, it:

1. Selects which headers and the body content to sign.
2. Generates a hash of that content.
3. Encrypts the hash with its private key.
4. Attaches the result as a DKIM-Signature header on the message.

The receiving server:

1. Reads the DKIM-Signature header to find the signing domain and selector.
2. Looks up the public key via DNS at selector._domainkey.yourdomain.com.
3. Decrypts the signature using the public key.
4. Hashes the same headers and body content independently.
5. Compares its hash to the decrypted signature. If they match, the email passes DKIM.

The DKIM result is then factored into DMARC evaluation if a DMARC record exists for the domain.

DKIM and Clerk

Clerk configures DKIM records automatically as part of production instance setup. This ensures that every verification email sent from your domain carries a valid cryptographic signature.

For more details on email authentication setup, see Email deliverability.