DKIM signature: what it is and how to configure it correctly

DKIM (DomainKeys Identified Mail) is an email authentication mechanism where the sending server attaches a cryptographic signature to each message. The receiving server verifies that signature against a public key published in the sender domain's DNS. A match confirms that the message came from the domain's owner and was not modified in transit.

Why DKIM exists

SMTP does not verify who actually sent a message. Any server can put an arbitrary address in the From field. DKIM closes that gap by tying the message content to a specific domain via a digital signature.

Without DKIM, mail providers cannot distinguish a genuine message from a forgery. With it, they have cryptographic proof: the message was signed with a private key that only the domain owner holds.

How DKIM signing works

The process has two stages: signing on the sender side and verification on the receiver side.

Signing. When a message leaves the sending server, the server selects a set of headers (From, To, Subject, Date, and others) plus the message body. It computes a hash of that data, encrypts the hash with the private key, and places the result in the DKIM-Signature header.

Verification. The receiving server extracts the domain (d=) and selector (s=) from the DKIM-Signature header. Using those values it queries DNS for a record named selector._domainkey.example.com and retrieves the public key. It then decrypts the signature, computes its own hash of the same headers and body, and compares. A match is a Pass.

DKIM-Signature header structure

The header carries several parameters, each covering a specific part of the verification:

v=1 — DKIM version (always 1). a=rsa-sha256 — signing algorithm. d=example.com — the domain on whose behalf the message is signed. s=mail2024 — the selector pointing to a specific key in DNS.

h=from:to:subject:date — the list of signed headers. bh= — hash of the message body. b= — the signature itself, Base64-encoded.

The c=relaxed/relaxed parameter sets the canonicalization mode: rules for normalizing headers and body before hashing. Relaxed mode tolerates minor whitespace and case changes, which reduces false failures when messages pass through intermediate servers.

DNS record with the public key

The public key is published as a TXT record in DNS. The record name follows the pattern selector._domainkey.example.com. Its value includes the version, key type, and the key itself in Base64.

Selectors let one domain use multiple DKIM keys simultaneously. This is useful when email goes out through different services: an ESP uses one selector, a transactional service uses another, and corporate mail uses a third. Each service signs with its own private key; the receiving server finds the right public key by selector name.

Key length: 1024 vs 2048 bits

The standard allows keys from 1024 bits up, and since 2024 both Google and Yahoo require at least 1024 bits. In practice, 2048-bit keys are the better choice: they provide several more years of cryptographic margin.

2048-bit keys have one practical complication: the TXT record exceeds 255 characters, which is the maximum for a single DNS string. The record must be split into multiple strings (a multi-string TXT record). Most DNS hosting panels handle this automatically, but manual configuration is an easy place to make a mistake.

Canonicalization: simple and relaxed

A message typically passes through several servers on its way to the recipient. Any of them may reformat the message slightly: adding a trailing space, changing a header's case, adjusting line endings. If the signature was computed against an exact byte sequence, any such change breaks verification.

Simple mode requires an exact match and is rarely used. Relaxed mode normalizes whitespace and case before hashing. The standard recommendation is c=relaxed/relaxed, where the first value applies to headers and the second to the body.

Key rotation

Rotate the private key every 6 to 12 months. If a key leaks, an attacker can sign messages on behalf of your domain until the key is revoked.

The rotation procedure: generate a new key pair with a new selector. Publish the public key in DNS. Switch the sending server to the new selector. Confirm that outgoing messages are signed with the new key. Only then remove the old DNS record. Leave a buffer of a few days between publishing the new key and deleting the old one: MTA queues may still hold messages signed with the previous key.

Common DKIM configuration mistakes

No DKIM for third-party services. A company configures DKIM for corporate mail but forgets the ESP, CRM, or helpdesk. Messages from those services go out unsigned and fail DMARC.

Errors in the DNS record. A stray space, an unclosed quote, or a long key that was not split into multiple strings. Any syntax error makes the key unreadable, and verification returns PermError.

The signature does not cover the From header. RFC 6376 requires From in the list of signed headers. Without it, DMARC alignment fails even when the signature itself is valid.

Stale key. A key that has not been rotated in years. The longer a key stays active, the higher the risk of compromise. 512-bit keys, used in early DKIM deployments, are long considered insecure.

DKIM together with SPF and DMARC

DKIM does not specify what to do with a message that fails verification. That is DMARC's job. DMARC requires at least one mechanism, SPF or DKIM, to pass with correct alignment: the domain in the signature must match the domain in From.

DKIM holds up better than SPF under forwarding. When a message is forwarded through an intermediary, SPF often breaks: the forwarding server's IP is not in the original domain's SPF record. The DKIM signature survives because it is bound to the message content, not the sender's IP address.

This is why DKIM is the mechanism that keeps forwarded messages out of spam. Without a valid DKIM signature, forwarded messages fail DMARC and land in junk.