DKIM lets a domain sign outgoing email messages with a private key, allowing receiving servers to verify the signature using the sender's public key published in DNS. This proves the message genuinely originated from that domain and wasn't tampered with.
How it works:
The sending mail server signs selected email headers and the message body, inserting a DKIM-Signature: header field into the message. The public key is published as a TXT record in DNS at selector._domainkey.domain.com. When the receiving server gets the email, it extracts the selector and domain from the signature header, looks up the public key via DNS, and verifies the cryptographic signature matches the message content.
The signature covers a canonicalized (simplified) form of headers like From, Subject, and Date, plus the body. The DKIM-Signature header includes tags such as:
d=— the signing domains=— the selector namea=— the algorithm (e.g.,rsa-sha256,ed25519-sha256)b=— the actual signature value
Example DNS record:
selector1._domainkey.example.com IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEB..."
DKIM works alongside SPF and DMARC as part of a layered email authentication strategy. Unlike SPF, DKIM doesn't verify the envelope-from address—it only proves the signing domain authorized the message. This is why DMARC alignment policies tie DKIM or SPF to the visible From address.
WarningEmail forwarding and mailing lists that modify headers or add footers will break DKIM signatures, because the signed content no longer matches. This is a common reason for authentication failures on forwarded mail.