What is DKIM and How Does It Work

What is DKIM

DKIM (DomainKeys Identified Mail) is an email authentication protocol defined in RFC 6376. It allows the sender to digitally sign an email with a cryptographic key tied to their domain. The recipient verifies the signature using a public key published in DNS — confirming that the message genuinely originates from that domain and hasn't been tampered with in transit.

Unlike SPF, which only verifies whether the sending server is authorized, DKIM verifies the integrity and origin of the message itself. DKIM signatures typically survive email forwarding (as long as the message body isn't modified) — making DKIM essential for a working DMARC deployment.

How DKIM works

The entire process runs automatically and consists of two parts: signing on the sender's side and verification on the recipient's side.

Signing

1. The sending mail server computes a hash (digest) of the message body and selected headers (From, To, Subject, Date, and others).
2. It creates a digital signature from the hash using the domain's private key.
3. It inserts the signature into the DKIM-Signature header of the outgoing email.

Verification

1. The receiving server reads the domain (d=) and selector (s=) from the DKIM-Signature header.
2. It queries DNS for the TXT record at {selector}._domainkey.{domain} to retrieve the public key.
3. It uses the public key to verify the signature against its own computation of the message hash.
4. If the hashes match, the DKIM check passes — the message is authentic and unaltered.

The sender only needs to publish the public key in DNS and configure signing on the mail server.

Anatomy of a DKIM signature

The DKIM-Signature header contains several tags that control both signing and verification:

DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=mail2024;
    c=relaxed/relaxed; q=dns/txt;
    h=from:to:subject:date:mime-version:content-type;
    bh=2jUSOH9NhtVGCQWNr9BrIAPreKQjO6Sn7XIkfJVOzv8=;
    b=AuUoFEfDxTDkHlLXSZEpZj79LICEps6eda7W3deTVFOk4yAUoqOB

Required tags

Optional tags

Canonicalization

The c= tag defines how the message is normalized before hashing. The format is headers/body:

The recommended setting is relaxed/relaxed — it tolerates common modifications made by forwarding servers.

DKIM DNS record

The public key is published as a TXT record in DNS at {selector}._domainkey.{domain}:

mail2024._domainkey.example.com TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA..."

DKIM DNS record tags

An empty p= value signals a revoked key — recipients will reject signatures using this selector.

Selectors and key rotation

The selector (s=) allows multiple DKIM keys to coexist under a single domain. This is essential for:

• Key rotation: Create a new selector (mail2025), deploy it on the server, and after a transition period, remove the old DNS record (mail2024).
• Multiple sending services: Each service (mail server, marketing platform, helpdesk) can have its own selector and key.

The recommended RSA key length is at least 2048 bits. RFC 8301 requires signers to use a minimum of 2048-bit RSA keys. While 1024-bit keys are still accepted by most verifiers, they should be considered deprecated.

Why you need DKIM

Message integrity protection

DKIM is the only one of the three authentication protocols (SPF, DKIM, DMARC) that verifies the email content hasn't been altered in transit. If an attacker or misconfigured server modifies the message body or signed headers, the DKIM check fails.

Survives forwarding

SPF checks fail when emails are forwarded because the forwarding server isn't listed in the original domain's SPF record. A DKIM signature remains valid as long as the signed parts of the message stay unchanged. This makes DKIM critical for reliable authentication in environments where emails are forwarded.

Foundation for DMARC

DMARC requires that at least SPF or DKIM passes and aligns with the domain in the From header. Because DKIM survives forwarding, it provides a more reliable foundation for DMARC than SPF alone.

Requirements from major providers

Since February 2024, Google and Yahoo require DKIM or SPF authentication for all senders. Bulk senders (over 5,000 messages per day to Gmail) must have both SPF and DKIM plus a DMARC record.

How to set up DKIM

1. Generate a key pair

Most email services (Google Workspace, Microsoft 365, marketing platforms) generate DKIM keys automatically — you just need to activate them in the admin panel and add the DNS record.

If you run your own mail server, generate a key pair using a tool like OpenSSL or OpenDKIM:

openssl genrsa -out dkim-private.pem 2048
openssl rsa -in dkim-private.pem -pubout -out dkim-public.pem

2. Publish the public key in DNS

Add a TXT record to your domain's DNS. The record name is {selector}._domainkey.{domain}:

mail2024._domainkey.example.com TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA..."

Insert the public key as a Base64 string without the PEM file headers.

3. Configure signing

Set up your mail server to sign outgoing messages with the private key. Configuration depends on the software you use (Postfix + OpenDKIM, Exim, Exchange).

4. Verify it works

After deployment, verify that DKIM signing is working. Send a test email and inspect the headers — look for DKIM-Signature in the outgoing message and Authentication-Results: dkim=pass in the response.

Verify your DKIM record with our analyzer.

Common DKIM issues

Key too long for DNS

DNS TXT records are limited to 255 characters per string (a protocol constraint from RFC 1035). A 2048-bit DKIM key exceeds this limit. The solution: split the value into multiple quoted strings — DNS concatenates them automatically:

mail2024._domainkey.example.com TXT ("v=DKIM1; k=rsa; "
    "p=MIIBIjANBgkqhkiG9w0BAQE..."
    "...FAAOCAQ8AMIIBCgKCAQEA...")

DKIM fail after message modification

Anti-spam filters, mailing lists, or signature services may modify the message body. If the signed content changes, the DKIM check fails. Solutions:

• Use relaxed/relaxed canonicalization
• For mailing lists, the ARC protocol (Authenticated Received Chain) helps preserve authentication results

Missing or incorrect DNS record

If the DNS record for the selector doesn't exist or contains a syntax error, verification fails with a permerror or temperror result. After adding the record, wait for DNS propagation (typically under 1 hour, up to 48 hours depending on TTL) and verify the record using a DNS lookup tool.

Signature expiration

If you use the x= tag (expiration), the signature becomes invalid after the specified time. For messages with delayed delivery (graylisting, queues), this can cause failures. Most configurations don't use the x= tag.

DKIM in the email authentication ecosystem

DKIM works alongside other protocols as part of comprehensive email security:

Complete protection requires SPF, DKIM, and DMARC. Check your domain's security to see if all three protocols are properly configured.