What Is DKIM? The Tamper-Evident Seal on Your Email

Think of DKIM as a tamper-evident seal on a package. When your mail server sends a message, it computes a signature over the message body and key headers (including From and Subject) using a private cryptographic key that never leaves your sending system. That signature rides along in a hidden header on the message itself.

The receiving server fetches your public key from DNS (the Domain Name System) and checks the signature. If anyone changed so much as a character of the signed content in transit, the seal breaks and verification fails. If it verifies, the receiver knows two things: the message really was signed by the domain in the signature, and it arrived exactly as sent.

This is a fundamentally different question from the one SPF (Sender Policy Framework) asks. SPF asks 'is this server on the allowed list right now?' DKIM asks 'does this message carry a valid seal from the domain?' That's a property of the message, not of the connection.

The DKIM signature header includes two fields that matter for the DNS lookup: d= (the signing domain) and s= (the selector). The receiver combines them to find the public key at selector._domainkey.domain. For example, a signature with s=google and d=yourdomain.com sends the receiver to google._domainkey.yourdomain.com.

Selectors exist so a domain can publish many keys at once. Google Workspace uses one selector, your newsletter tool another, your helpdesk a third: each service signs with its own key under its own selector, and none of them can forge signatures for the others. This is why setting up DKIM for a new sending service always means adding one or more new DNS records: you're publishing that service's public key under its selector.

DKIM keys come in different strengths, measured in bits. 1024-bit keys were the long-standing default and are still accepted, but they're within reach of well-funded attackers, and mainstream guidance has moved on: use 2048-bit keys wherever your provider offers them, which today is almost everywhere. Google Workspace, Microsoft 365, and the major email service providers all generate 2048-bit keys by default.

Keys should also be rotated (replaced with a fresh pair) periodically, because a private key that leaks lets an attacker sign mail as you indefinitely. Selectors make rotation painless: publish the new public key under a new selector, switch signing to it, and retire the old record after mail signed with it has aged out. Many providers now rotate automatically; if yours doesn't, once or twice a year is a reasonable cadence.

When someone auto-forwards your message to another address, the forwarding server becomes the new sender. SPF fails at that point, because the forwarder's server isn't on your allowed list. DKIM usually still passes: the signature is part of the message, and as long as the forwarder passes the message along without modifying the signed content, the seal remains intact.

This makes DKIM the workhorse of DMARC in the real world. Mail gets forwarded constantly (personal filters, distribution lists, acquired-company domains), and DKIM is what keeps that legitimate mail authenticating. The main exception is mailing-list software that rewrites subjects or appends footers, which breaks the signature; that edge case is one reason DMARC only requires one of SPF or DKIM to pass, not both.

A valid DKIM signature alone doesn't prove the mail is from the domain in the From line. It proves it's from the domain in the signature's d= field, and nothing forces those to match. A spammer can validly sign mail with their own domain while displaying yours in the From address.

DMARC (Domain-based Message Authentication, Reporting and Conformance) closes this with alignment: for DKIM to count toward DMARC, the d= domain must match the visible From domain. In practice this means configuring each sending service to sign with your domain rather than its own default, usually by adding the CNAME or TXT records the service gives you. A service signing with its own domain will show 'DKIM pass' in raw terms but still fail DMARC.