Skip to content

Security term · last reviewed 2026-08-31

DKIM

Also known as: DomainKeys Identified Mail, RFC 6376

DKIM (DomainKeys Identified Mail, RFC 6376) attaches a cryptographic signature to outbound mail that a receiver verifies against a public key in DNS, proving the message was authorized by the signing domain and not altered in transit.

How it works

DKIM (DomainKeys Identified Mail, RFC 6376) attaches a cryptographic signature to outbound messages. The sending system signs selected headers and the body with a private key and adds a DKIM-Signature header naming the signing domain (d=) and a selector (s=). The receiver fetches the matching public key from DNS at <selector>._domainkey.<domain> and verifies the signature. A pass proves the message was authorized by the holder of that key and that the signed content was not altered in transit.

When it matters

DKIM matters as the more resilient of the two DMARC authentication paths, because a signature survives most forwarding and mailing lists while SPF breaks the moment the connecting IP changes. Every sending platform you use should sign with your own domain, not the vendor's, so the signature aligns with your From header. Keys should be at least 2048-bit and rotated on a schedule, which is what selectors exist to make possible without downtime.

Common misconceptions

  • "DKIM encrypts the message." It signs, it does not encrypt. Anyone can read the body; they just cannot alter the signed parts undetected.
  • "A DKIM pass means the mail is safe." It means the signer authorized it. An attacker can validly sign their own phishing mail from their own domain.
  • "Vendor-signed mail is aligned." If the platform signs with d=vendor.com while your From header says yourdomain.com, DMARC alignment fails on the DKIM path.
← All terms