Understanding DKIM Signatures: Anatomy of an Email Signature

Every DKIM-signed email contains a DKIM-Signature header. This header holds all the information receiving servers need to verify the email's authenticity. Understanding this header helps you troubleshoot deliverability issues and verify your DKIM setup is working correctly.

What a DKIM Signature Looks Like

Here's a real-world example of a DKIM-Signature header:

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
  d=example.com; s=google;
  h=from:to:subject:date:message-id:content-type;
  bh=2jUSOH9NhtVGCQWNr9BrIAPreKQjO6Sn7XIkfJVOzv8=;
  b=AuUoFEfDxTDkHlLXSZEpZj79LICEps6eda7W3deTVFOk4yAUoqOB
    4nujc7YopdG5dWLSdNg6xNAZpOPr+kHxt1IrE+NahM6L/LbvaHut
    KVdkLLkpVaVVQPzeRDI009SO2Il5Lu7rDNH6mZckBdrIx0orEtZV
    4bmp/YzhwvcubU4=

This might look like random characters, but each part has a specific meaning. Let's break it down.

DKIM-Signature Header Fields

v (Version)

v=1

The DKIM specification version. Currently, this is always "1". If you see a different value, the signature is invalid.

a (Algorithm)

a=rsa-sha256

The cryptographic algorithm used to sign the email. The two parts are:

• rsa: The encryption algorithm for the signature
• sha256: The hashing algorithm

Common values:

• rsa-sha256 (recommended, most secure)
• rsa-sha1 (older, less secure but still valid)
• ed25519-sha256 (newer, not yet widely supported)

c (Canonicalization)

c=relaxed/relaxed

How the email is normalized before hashing. The format is header-canonicalization/body-canonicalization.

Simple: Minimal changes. Strict—most modifications break the signature.

Relaxed: Tolerant of whitespace changes, header case changes, and line wrapping. More likely to survive email transit.

Common values:

• relaxed/relaxed (most common, recommended)
• simple/simple (strictest)
• relaxed/simple or simple/relaxed (mixed)

d (Domain)

d=example.com

The domain claiming responsibility for this email. This is the domain whose DNS will be queried for the public key. For DMARC alignment, this should match (or be a parent domain of) the From address domain.

s (Selector)

s=google

The selector identifying which public key to use. Combined with the domain, this tells receiving servers where to find the public key: google._domainkey.example.com.

h (Headers)

h=from:to:subject:date:message-id:content-type

The list of headers that were signed. These headers (and the body) are hashed to create the signature. Common headers include:

• from (required)
• to
• subject
• date
• message-id
• content-type
• mime-version

Headers not listed here aren't protected by the signature and could be modified in transit without breaking DKIM.

bh (Body Hash)

bh=2jUSOH9NhtVGCQWNr9BrIAPreKQjO6Sn7XIkfJVOzv8=

A base64-encoded hash of the email body. This allows the body to be verified separately. The receiving server hashes the body and compares it to this value—if they don't match, the body was modified.

b (Signature)

b=AuUoFEfDxTDkHlLXSZEpZj79LICEps6...

The actual cryptographic signature. This is created by:

1. Hashing the signed headers and body hash
2. Encrypting that hash with the private key
3. Base64-encoding the result

This is what the receiving server decrypts with the public key to verify the email.

Optional Fields

Some DKIM signatures include additional fields:

t (Timestamp)

t=1706400000

Unix timestamp when the signature was created. Some receiving servers use this to reject very old signatures.

x (Expiration)

x=1706486400

Unix timestamp when the signature expires. After this time, the signature should be considered invalid. Not commonly used.

l (Body Length)

l=1000

Limits how many bytes of the body were signed. Avoid using this—it allows attackers to append content to emails without breaking the signature.

i (Identity)

i=user@example.com

The identity of the user or agent on whose behalf the email is signed. Must end with @d or @subdomain.d where d is the domain in the d= field.

q (Query Method)

q=dns/txt

How to retrieve the public key. Currently, dns/txt is the only supported value.

Reading DKIM Signatures in Email Headers

To view the DKIM-Signature header in your email:

Gmail: Open the email → Click the three dots → "Show original"

Outlook: Open the email → File → Properties → Look in "Internet headers"

Apple Mail: View → Message → All Headers

Thunderbird: View → Headers → All

You'll also find an Authentication-Results header that shows the DKIM verification result:

Authentication-Results: mx.google.com;
  dkim=pass header.d=example.com header.s=google;
  spf=pass (google.com: domain of sender@example.com
    designates 123.45.67.89 as permitted sender);
  dmarc=pass (p=REJECT sp=REJECT)

Interpreting Authentication-Results

The Authentication-Results header tells you whether DKIM verification succeeded:

Why Signatures Fail

Common reasons DKIM signatures fail verification:

Modified content: The email body or signed headers were changed after signing. This can happen legitimately (mailing lists, forwarding) or maliciously.

Wrong public key: The public key in DNS doesn't match the private key used to sign. Often happens after key rotation if DNS wasn't updated.

DNS issues: The public key record couldn't be retrieved due to DNS problems or propagation delays.

Algorithm mismatch: The receiving server doesn't support the algorithm used (rare with modern servers).

Expired signature: If x= was set and the current time is past that timestamp.

Monitor Your DKIM Records

Checking once is good. Monitoring continuously is better. The Email Deliverability Suite watches your SPF, DKIM, DMARC, and MX records daily and alerts you when something breaks.