Blog article

  • 8 minutes read
Author Profile Picture
  • Sendmarc

DKIM Signature: How Generation and Key Compromise Work at Scale

A Blue Digital Key In Cyber Space With Data Lines Flowing Behind It

DKIM signature overview:

  • A DKIM signature is a base64-encoded cryptographic signature, generated using a private key
  • DKIM canonicalization controls how much message reformatting a signature can tolerate
  • A compromised key lets an attacker forge signed messages until it’s rotated and revoked

Your email infrastructure most likely signs every outbound message with a private key you may not have rotated in years. If that key is ever compromised, every email your organization sends under it becomes vulnerable to forgery. That isn’t a theoretical risk.

This post is not a DKIM primer. What follows is a technical examination of the DKIM signature itself: What it is, how it’s generated and verified, and what breaks it at enterprise scale.

Sendmarc’s DMARC Management Platform surfaces DKIM results across every sending source, so failures show up before they block messages or complicate a compliance review. Explore our DMARC Management Platform to see how DKIM is tracked across your domain portfolio.

Book a demo

What a DKIM Signature Actually Is

A DKIM signature is a cryptographic signature, base64-encoded in the b= tag, generated using the sending domain’s private key and a cryptographic hashing algorithm applied to the message body and a specified set of headers.

The private key used to generate a DKIM signature is stored on the sending mail transfer agent (MTA). Its matching public key is published in a DNS TXT record. When the MTA receives a message requiring DKIM, it canonicalizes the specified header fields and message body, hashes them using RSA or Ed25519 asymmetric cryptography, and signs that hash with the private key.

The result is embedded in the DKIM-Signature header alongside metadata that tells the receiving server exactly how to verify it:

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=example.com; s=default.private;
bh=fdkeB/A0FkbVP2k4J4pNPoe23AvqBm9+b0C3OY87Cw8=;
h=Date:From:Message-Id:To:Subject;
b=M6g0eHe3LNqURha9d73bFWlPfOERXsXxr
YtN2qrSQ6/0WXtOxwkEjfoNTHPzoEOlD i6uLLwV+3/JTs7mFmrkvlA5ZR693sM5gkVgVJmuOsylXSwd3XNfEcGSqFRRIrLhHtbC
mAXMNxJtih9OuVNi96TrFNyUJeHMRvvbo34BzqWY=

Each tag carries operational weight. v= is the version. a= is the signing algorithm. c= is the canonicalization algorithm. d= is the signing domain. s= is the selector. h= lists the signed headers. bh= is the hash of the body. b= is the actual signature.

The receiving server fetches the public key and compares it to the signature. If they match, the DKIM signature is valid. If they don’t, the message fails DKIM, and depending on your DMARC policy, it may be quarantined or rejected.

DKIM Canonicalization: Why Messages Can Fail Verification

DKIM canonicalization is the step that most enterprise email teams underestimate. Before hashing, the message must be normalized. DKIM defines two canonicalization algorithms for the headers and body: simple and relaxed.

simple canonicalization is strict. It preserves headers and body exactly as they were at signing time. A single line break or space will cause the email to fail DKIM.

relaxed canonicalization tolerates minor changes: header folding or multiple spaces. Most modern sending infrastructure defaults to relaxed/relaxed for exactly this reason.

The operational consequence is significant. If your sending platform uses simple/simple canonicalization and your email passes through a rewriting relay, the signature will break, and the message won’t reach the recipient.

Key Compromise: The Forgery Risk

A DKIM private key is only as secure as the infrastructure that holds it. If a key is compromised, whether through a breach, a misconfigured secrets manager, or a miscommunicated offboarding, every message signed with that key becomes forgeable.

This is the scenario most DKIM documentation glosses over. An attacker holding a stolen private key can compose and sign an entirely new message, and that signature will pass verification for as long as the corresponding public key remains published and unrevoked in the DNS.

The window of exposure is directly proportional to how long the key has been in production without rotation. A key that’s been live for three years on a domain sending hundreds of thousands of messages is a significantly higher-value target than one rotated quarterly.

Key rotation closes the window. Once you publish a new key and revoke the old one by removing its DNS TXT record, any signature generated with the old key will fail verification.

Signature Validation Failures: What the Error Actually Tells You

DKIM failures fall into distinct categories, and each one points to a different cause.

  • PermError: The receiving server can’t verify the signature. Common causes include an invalid record or a missing key. This typically indicates a configuration problem.
  • TempError: The verifying server couldn’t complete the DNS lookup at the time of delivery. This is usually transient. These failures often self-resolve but should be monitored for patterns.
  • fail: The signature can’t be evaluated. This is the result of a syntax error or a missing key.
  • none: No DKIM signature is present. This isn’t a validation failure; it’s an absence. DMARC still treats it as a DKIM failure.

How Sendmarc Helps

Sendmarc’s DMARC Management capability surfaces DKIM validation results across all sending sources, identifying which senders are failing and which domains have no DKIM coverage at all. This removes the manual work that stretched IT teams would otherwise carry alone, and it helps detect compromised or breached sending sources before they escalate.

Explore our DMARC Management solution to see how DKIM results are tracked across your entire domain portfolio.

Book a demo
// JavaScript Document