What is DKIM? How DomainKeys Identified Mail Works

DomainKeys Identified Mail (DKIM) is the second pillar of email authentication. While SPF evaluates an SMTP sender against a domain policy, DKIM verifies that selected signed content was not altered and that the signer controlled the private key for the signing domain. DMARC adds the separate check that this domain aligns with the visible From address.

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 signature verifies, DKIM passes for that signing domain and the signed content. This does not by itself identify the human sender or authorize the visible From address.

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 does not prescribe one calendar interval for every deployment. Rotate according to your provider's security policy and immediately after suspected compromise; using a new selector makes a staged change possible.

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 the previous DNS TTL to expire and confirm the new selector is available from the resolvers your recipients use.
4. Update your mail server to sign with the new private key and selector.
5. Keep the old public key in DNS long enough for delayed or queued messages signed with it to be verified.
6. Remove or revoke the old selector after the transition period defined by your mail provider and queueing policy.

RFC 8301 requires RSA signers to use at least 1024-bit keys and recommends 2048 bits or more. Choose a rotation interval based on your provider's key-management policy, exposure and operational ability to complete a safe overlap.

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.