DKIM signing examples: what good and bad look like

DKIM (DomainKeys Identified Mail) adds a cryptographic signature header to each message. The public key lives in DNS under a selector, and receivers verify the signature to confirm the message was not altered and was authorized by the signing domain.

A correct example#

s1._domainkey.example.com.  IN TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA..."

Every element is there for a reason, and each maps to one of the setup steps below.

What good looks like#

• Done: Generate a 2048-bit key pair in your ESP or mail server (1024-bit keys are considered weak).
• Done: Publish the public key as a TXT record at selector._domainkey.yourdomain.com.
• Done: Enable signing in the sending platform and confirm the d= tag in outgoing headers matches your organizational domain.
• Done: Send a test to a seed address and inspect the Authentication-Results header for dkim=pass.
• Done: Schedule key rotation every 6 to 12 months using a second selector so old mail still verifies.

What bad looks like#

• Seen in audits: Signing with the ESP's domain (d=esp.com) instead of yours, which passes DKIM but fails DMARC alignment.
• Seen in audits: Copying the public key with line breaks or quotes broken, producing a permanent verification failure.
• Seen in audits: Modifying message bodies after signing (footers injected by gateways) which invalidates the signature.
• Seen in audits: Never rotating keys, leaving a compromised key valid indefinitely.

How to move from bad to good#

Work through the good list in order and re-verify after each change. Most teams find one or two items from the bad list already present; fixing those usually produces the largest improvement.

Frequently asked questions#