DKIM

What DKIM is

DomainKeys Identified Mail attaches a digital signature to each outgoing message. The sending server computes a hash over selected headers and the body, signs it with a private key, and adds a DKIM-Signature header. The matching public key is published in DNS as a TXT record at selector._domainkey.example.com, where the selector is a short label chosen by the sender so that several keys can coexist. The receiver reads the selector from the signature header, fetches the key, and verifies the signature. If it checks out, the message was authorized by the domain and has not been modified in transit.

A signature header carries the essentials in tag form: d= is the signing domain, s= is the selector, h= lists the signed headers, and b= is the signature itself.

Why it matters

SPF authorizes servers; DKIM authorizes messages. The distinction matters whenever mail passes through an intermediate server, such as a mailing list or a forwarding address: SPF fails because the forwarder's IP is not authorized, but a DKIM signature survives as long as the content is not altered. Large receivers weigh a valid DKIM signature heavily when deciding whether a message reaches the inbox, and DMARC relies on it to align the visible From: domain with an authenticated identity.

DKIM also helps with reputation. Because the signature ties a message to a domain rather than to an IP address, a sender's history follows the domain even when the sending infrastructure changes.

How to check

Find the selector in a message's DKIM-Signature header, then use the DNS lookup tool to query the TXT record at selector._domainkey.yourdomain.com. A valid record starts with v=DKIM1 and contains a p= tag with the public key; an empty p= means the key has been revoked. To see whether receivers accept your signatures, paste a delivered message's full headers into the email header analyzer and read the Authentication-Results line, which reports dkim=pass or the reason for failure.

Common problems

• The DNS record was split into several strings and recombined incorrectly, or the key was truncated by a provider's length limit.
• The message was modified after signing, often by a footer or a disclaimer added by a gateway.
• The selector in the header does not match the one published.
• Keys shorter than 1024 bits are rejected by major receivers; 2048 bits is the usual choice today.

A common misconception

DKIM does not encrypt mail and does not prove who wrote it. It proves that a server holding the domain's private key handled the message and that it arrived intact.