How DKIM Works: Email Signing and Verification Explained

DKIM uses public-key cryptography to authenticate email messages, as defined in RFC 6376. The sending server signs emails with a private key, and receiving servers verify the signature using a public key published in DNS. If you're new to DKIM, start with what DKIM is before diving into this technical overview.

This article is part of our How DKIM Works series.

The DKIM Process

Key generation

Generate an RSA key pair (1024 or 2048 bits). The private key stays secure on your mail server. The public key goes in your DNS.

Email signing

When sending, the mail server creates a hash of specific email headers and the body, then encrypts this hash with the private key. This encrypted hash is the DKIM signature.

Signature attachment

The signature is added to the email as a DKIM-Signature header, including metadata about which parts of the email were signed and where to find the public key.

DNS lookup

The receiving server extracts the domain (d=) and selector (s=) from the signature header, then queries DNS for the public key at selector._domainkey.domain.com.

Verification

The receiver recreates the hash using the same headers/body, decrypts the signature with the public key, and compares. If they match, DKIM passes.

The DKIM Signature Header

Here's what a DKIM-Signature header looks like (see DKIM signature explained for a full tag-by-tag breakdown):

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
  d=example.com; s=selector1;
  h=from:to:subject:date:message-id;
  bh=abc123...=;
  b=xyz789...=

Tag	Purpose
`v`	Version (always `1`)
`a`	Algorithm (`rsa-sha256` is standard)
`c`	Canonicalization (how whitespace is handled)
`d`	Signing domain
`s`	Selector
`h`	List of signed headers
`bh`	Body hash
`b`	The actual signature

Canonicalization

Emails can be modified slightly in transit (whitespace changes, line wrapping). Canonicalization normalizes the message before hashing to allow for minor variations.

Two settings (header/body):

simple: Strict - almost no changes allowed
relaxed: Tolerant - ignores trailing whitespace, converts headers to lowercase

Most domains use relaxed/relaxed to avoid false failures from minor transit modifications.

Use relaxed canonicalization

The relaxed setting (c=relaxed/relaxed) is recommended. It allows your signature to survive common email transit modifications.

What Gets Signed

The DKIM signature covers:

Headers (specified in h= tag):

From (required by the specification)
To
Subject
Date
Message-ID
Other headers as needed

Body:

The entire message body is hashed
The body hash is included in bh=

Mailing lists and forwarders may modify emails (adding footers, changing headers), which breaks DKIM signatures. This is normal and expected - DMARC's alignment rules help handle this.

The DNS Record

The public key is stored as a TXT record (either directly or via a CNAME -- see TXT vs CNAME records):

v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A...

Tag	Purpose
`v`	Version (`DKIM1`)
`k`	Key type (`rsa`)
`p`	Public key (base64)
`t`	Flags: `y`=testing mode, `s`=strict alignment

Generate your DKIM key pair

Create properly formatted keys and DNS records in seconds.

Generate Keys

RSA Key Sizes

DKIM commonly uses RSA encryption, with key usage guidance updated in RFC 8301:

Key Size	Status	Notes
512-bit	Broken	Do not use - can be cracked
1024-bit	Minimum	Acceptable, but upgrade when possible
2048-bit	Recommended	Good security, may need DNS record splitting
4096-bit	Overkill	Very long DNS records, limited support

2048-bit is the current standard per RFC 8301. Some DNS providers have TXT record length limits that require 1024-bit keys.

Verification Outcomes

When a receiving server checks DKIM:

Result	Meaning
`pass`	Signature verified successfully
`fail`	Signature invalid (key mismatch or tampered message)
`neutral`	Signature present but couldn't be verified
`temperror`	Temporary DNS failure
`permerror`	DNS record malformed
`none`	No signature present

What DKIM Doesn't Do

DKIM proves the message wasn't altered since signing. It does not:

Prevent spam (spammers can sign their own emails)
Verify the sender is trustworthy
Protect the full envelope (only signed headers/body)
Work across all forwarding scenarios

For comprehensive protection, combine DKIM with SPF and DMARC. Our DKIM vs SPF comparison covers how these two protocols differ.

References

RFC 6376 — DomainKeys Identified Mail (DKIM) Signatures
RFC 8301 — Cryptographic Algorithm and Key Usage Update to DomainKeys Identified Mail (DKIM)

DKIM Creator generates cryptographically secure key pairs that follow best practices.

Ready to set up DKIM?

Generate 2048-bit RSA keys with properly formatted DNS records. Keys are created in your browser - nothing is transmitted.

Generate DKIM Keys