What is DKIM?

What it is#

DomainKeys Identified Mail (DKIM) is an email authentication protocol that allows a sending domain to take cryptographic responsibility for a message. The sending server signs specified email headers and the message body with a private key, and the receiving server verifies that signature using a public key published in DNS. If the signature verifies, the receiver knows the message was not altered in transit and that the claimed signing domain authorized it.

Unlike SPF, which validates the sending server's IP address, DKIM validates the message content itself. This makes it resilient to forwarding, a property that SPF lacks.

How DKIM works#

1. The sending mail server generates a cryptographic hash of specified message headers (e.g., From, To, Subject, Date) and the message body
2. The server signs that hash with the domain's private key and attaches the signature as a DKIM-Signature header
3. The signature header includes metadata (the signing domain (d=), the selector (s=), the algorithm (a=rsa-sha256), and the list of signed headers (h=))
4. The receiving server extracts the d= and s= values and queries DNS for a TXT record at selector._domainkey.domain.com
5. The DNS record contains the public key
6. The receiver uses the public key to verify the signature against the message content

If any signed header or the body has been modified after signing, the verification fails.

Selectors#

A selector is a label that allows a domain to publish multiple DKIM keys simultaneously. The selector appears in both the DKIM-Signature header (s=selector1) and the DNS lookup path (selector1._domainkey.example.com). This design supports several operational needs:

• Multiple mail systems. An organization can use s=google for Google Workspace and s=sendgrid for transactional email, each with its own key pair
• Key rotation. A new selector with a fresh key can be deployed alongside the old one, with a gradual transition
• Delegation. Third-party senders can sign with their own selector under your domain using CNAME records that point to their DNS infrastructure

What gets signed#

The DKIM-Signature header specifies which headers are covered by the signature via the h= tag. At minimum, the From header must be signed. Commonly signed headers include To, Subject, Date, Message-ID, and MIME-Version. The body is included via a hash in the bh= tag.

Headers not listed in h= can be modified without breaking the signature. This is why some DKIM implementations sign additional headers defensively, to prevent intermediaries from adding or modifying them.

Surviving forwarding#

When an email is forwarded, the forwarding server's IP address changes but the DKIM signature embedded in the message headers remains intact (assuming the forwarder doesn't modify signed content). This is a significant advantage over SPF, which fails on forwarding because the new sending IP isn't in the original domain's SPF record.

However, mailing lists and some forwarding services do modify message content, adding footers, rewriting the Subject line, or changing the From header, which breaks DKIM signatures. The Authenticated Received Chain (ARC) protocol was developed to preserve authentication results across these legitimate modifications.

How to check DKIM#

To verify that DKIM is correctly configured for a domain, query the DKIM TXT record via DNS: dig TXT selector._domainkey.example.com. The response should contain a v=DKIM1 record with the public key (p=). Online DKIM checker tools automate this by sending a test email and verifying the signature in the received headers.

Common issues include missing DNS records (wrong selector name), expired or rotated keys, and overly restrictive DNS security configurations that block TXT record queries.

Relationship to DMARC#

DKIM provides a verifiable chain of custody between a domain and its email. When combined with DMARC alignment, it ensures that only messages cryptographically signed by the domain's authorized keys pass authentication. Monitoring for DKIM records on lookalike domains can reveal whether attackers have set up authenticated mail infrastructure, a signal that a domain registered for squatting purposes is being actively weaponized for phishing.