What is DKIM? How DomainKeys Identified Mail Works

Updated February 6, 2026

DomainKeys Identified Mail (DKIM) is the second pillar of email authentication. While SPF verifies that a message came from an authorized server, DKIM goes further: it cryptographically proves that the message content has not been tampered with and that it genuinely originated from your domain.

How DKIM Works

DKIM uses public-key cryptography — the same fundamental approach that secures HTTPS and SSH. Here is the process:

Signing (Outgoing Mail)

1. Your mail server has a private key that is kept secret.
2. When it sends an email, it computes a cryptographic hash of specific headers and the message body.
3. It encrypts that hash using the private key, creating a digital signature.
4. The signature is added to the email as a DKIM-Signature header.

Verification (Incoming Mail)

1. The receiving server reads the DKIM-Signature header and notes the selector and domain.
2. It looks up the corresponding public key in DNS at selector._domainkey.domain.com.
3. It uses the public key to decrypt the signature and recover the original hash.
4. It independently computes the hash from the received message.
5. If the two hashes match, DKIM passes — the message is authentic and unmodified.

The DKIM-Signature Header

Every DKIM-signed email includes a header like this:

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
  d=example.com; s=google;
  h=from:to:subject:date:message-id:mime-version;
  bh=abc123hashofbody=;
  b=xyz789signaturevalue=

Here is what each tag means:

Canonicalization

The c tag controls how the message is normalized before hashing. There are two values (header/body):

• simple — Almost no modification allowed. Extra whitespace or case changes break the signature.
• relaxed — Whitespace and header case are normalized before hashing. Much more tolerant of minor changes by mail servers in transit.

Most deployments use relaxed/relaxed because email messages often get minor formatting changes as they pass through different servers.

DKIM DNS Record

The public key is published as a TXT record at selector._domainkey.yourdomain.com. A typical record looks like:

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

If you see p= with an empty value, it means the key has been revoked — the selector is no longer valid.

Selectors

A selector is a label that lets you publish multiple DKIM keys for the same domain. Each third-party service that sends email on your behalf typically uses its own selector.

For example:

• Google Workspace might use: google._domainkey.example.com
• SendGrid might use: s1._domainkey.example.com
• Mailchimp might use: k1._domainkey.example.com

This design means you can have different services signing with different keys, and you can rotate one key without affecting the others.

Finding Your Selectors

Your selectors are visible in the DKIM-Signature header of any email sent from that service. Look for the s= tag. You can also check your email provider's documentation — they will tell you exactly which selector to configure.

Key Generation and Setup

Step 1: Generate a Key Pair

Most email providers generate the key pair for you. If you need to generate your own:

# Generate a 2048-bit RSA private key
openssl genrsa -out dkim_private.pem 2048

# Extract the public key
openssl rsa -in dkim_private.pem -pubout -out dkim_public.pem

Step 2: Publish the Public Key in DNS

Take the public key, remove the header/footer lines and line breaks, and publish it as a TXT record:

myselector._domainkey.example.com IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBA..."

Step 3: Configure Your Mail Server

Configure your mail server or email provider to sign outgoing messages with the private key using the selector you published. The exact steps vary by provider — consult their DKIM setup documentation.

Step 4: Verify

Send a test email and check the Authentication-Results header on the receiving side. You should see dkim=pass.

Key Rotation Best Practices

DKIM keys should be rotated periodically to limit the damage if a private key is ever compromised.

1. Generate a new key pair with a new selector name (e.g., selector202602).
2. Publish the new public key in DNS alongside the old one.
3. Wait for DNS propagation — check that the new record is visible globally.
4. Update your mail server to sign with the new private key and selector.
5. Keep the old public key in DNS for at least 7 days so in-transit emails can still be verified.
6. Remove the old DNS record once the transition period is over.

Recommended rotation schedule: every 6 to 12 months. Always use at least 2048-bit RSA keys — 1024-bit keys are considered weak and can be factored with sufficient computing power.

Common DKIM Issues

Signature Broken by Forwarding

When an email is forwarded, intermediary servers may modify the message body or headers. This can break the DKIM signature. This is one reason why DMARC accepts a pass from either SPF or DKIM — forwarding often breaks SPF too, but DKIM signatures on unmodified headers may still verify.

Key Too Long for DNS

Some DNS providers struggle with long TXT records. If your 2048-bit key is being truncated, verify the full record using:

dig TXT google._domainkey.example.com +short

The output should contain the complete p= value.

Missing DNS Record

If the receiving server cannot find the public key at the selector location, DKIM verification fails. Double-check the selector name matches what your mail server is using in the s= tag.

DKIM and DMARC

DKIM becomes especially powerful when combined with DMARC. DMARC checks that the d= domain in the DKIM signature aligns with the From header domain. This prevents attackers from signing a forged email with their own domain's DKIM key while spoofing your From address.

For a complete email security setup, implement SPF, DKIM, and DMARC together. Read our email authentication guide for the full picture.