DKIM

DKIM — DomainKeys Identified Mail — attaches a cryptographic signature to every outgoing message, generated with a private key held by the sending infrastructure. The matching public key is published in the domain's DNS, so any receiving server can verify two things at once: the message was sent by infrastructure authorized for that domain, and the signed content — headers and body — was not modified on the way.

How it works

The sending server computes a hash over selected headers and the message body, signs it, and inserts the result as a DKIM-Signature header naming the signing domain and a selector. The receiver fetches the public key from selector._domainkey.domain.com, recomputes the hash, and checks the signature. Unlike SPF, the signature travels with the message, so DKIM survives forwarding — which is why mailing lists and relay chains that break SPF still verify cleanly under DKIM.

What it does not stop

A valid DKIM signature proves which domain signed the message — not that the domain is trustworthy. Attackers register their own domains, configure DKIM flawlessly, and send fully authenticated phishing. A signature also proves nothing about the visible From header unless DMARC alignment enforces that the signing domain and the displayed domain match. And when a legitimate mailbox is taken over, as in vendor email compromise, every malicious message is signed by the victim's own infrastructure: perfectly authenticated, perfectly fraudulent. The AI-generated phishing wave compounds this — flawless prose from a flawlessly authenticated domain leaves human judgment as the control that has to hold.

How to defend

• Sign all outgoing mail, including messages from marketing and transactional platforms, each with its own selector so a leaked key can be rotated narrowly.
• Rotate keys periodically and retire weak ones — 1024-bit keys are deprecated; use 2048-bit.
• Enforce alignment with DMARC. DKIM only constrains the visible sender once DMARC requires the signing domain to align with the From domain.
• Train for the authenticated-but-fraudulent case. Payment-change requests and urgent vendor emails deserve out-of-band verification regardless of what the authentication headers say.