Advanced DKIM signing: edge cases, scale, and monitoring

This guide assumes DKIM signing is already deployed and passing. It covers what breaks at scale and how mature teams operate it.

Edge cases that break a working setup#

• Signing with the ESP's domain (d=esp.com) instead of yours, which passes DKIM but fails DMARC alignment.
• Copying the public key with line breaks or quotes broken, producing a permanent verification failure.
• Modifying message bodies after signing (footers injected by gateways) which invalidates the signature.
• Never rotating keys, leaving a compromised key valid indefinitely.
• Mail forwarded through mailing lists or personal forwarders, which alters headers and content.
• Acquisitions and rebrands that introduce domains nobody audited.
• Vendors silently changing their sending infrastructure.

Operating it as infrastructure#

1. Assign an owner for each sending domain and each vendor relationship.
2. Put DNS records under version control or a change-review process.
3. Alert on authentication pass rate drops and reputation changes, not just outages.
4. Run a quarterly audit against the setup steps below.
5. Document runbooks for the three most common failures.

Reference: the baseline setup#

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

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

Frequently asked questions#