How DKIM Works: The Technical Process Explained

DKIM might seem like magic—your email gets a digital signature that proves it came from you. But under the hood, it's a straightforward process using well-established cryptographic principles. Understanding how it works helps you troubleshoot problems and configure it correctly.

The DKIM Signing Process

When you send an email from a DKIM-enabled server, several things happen before the message leaves your system.

Your mail server prepares the email

The email is composed with all its headers (From, To, Subject, Date, etc.) and body content ready to send.

The server selects which parts to sign

DKIM doesn't sign the entire email. It signs specific headers (like From, To, Subject) and a hash of the body. The exact headers signed are listed in the signature itself.

A hash is created

The server creates a cryptographic hash of the selected content. This hash is a fixed-length string that uniquely represents the content—change even one character, and the hash changes completely.

The hash is encrypted with your private key

Using your domain's private key, the hash is encrypted to create the signature. Only your private key can create this specific signature.

The signature is added to the email

The signature is inserted as a DKIM-Signature header in the email. The email is then sent normally.

The private key never leaves your mail server. It's used to sign outgoing emails but is never transmitted or exposed. This is what makes DKIM secure.

The Verification Process

When a receiving server gets your email, it performs DKIM verification:

Extract the DKIM-Signature header

The receiving server reads the DKIM-Signature header from the incoming email. This contains the selector, domain, algorithm used, and the signature itself.

Look up the public key in DNS

Using the selector and domain from the signature, the server queries DNS for your DKIM record. For example, if the selector is "google" and domain is "example.com", it looks up google._domainkey.example.com.

Recreate the hash

The receiving server performs the same hashing process on the email content that your server did. It hashes the specified headers and body.

Decrypt the signature

Using your public key from DNS, the server decrypts the signature to reveal the original hash your server created.

Compare the hashes

If the decrypted hash matches the newly calculated hash, the signature is valid. The email passes DKIM.

What Gets Signed

DKIM signs a combination of email headers and the message body. The DKIM-Signature header includes an "h=" field that lists exactly which headers were signed.

Common headers included in DKIM signatures:

From (required): The sender's email address
To: The recipient
Subject: The email subject line
Date: When the email was sent
Message-ID: Unique identifier for the email
Content-Type: The format of the email body

The body is also hashed, but there's a consideration: the "l=" parameter can limit how much of the body is signed. This exists because some mail servers add footers or disclaimers to emails. However, limiting body length can create security vulnerabilities, so most modern implementations sign the entire body.

Never set the "l=" parameter to limit body length in your DKIM configuration. It can allow attackers to append malicious content to signed emails.

Canonicalization: Handling Email Modifications

Emails often get slightly modified in transit. Spaces might be added, line breaks changed, or headers reformatted. To handle this, DKIM uses "canonicalization"—rules for normalizing the email before hashing.

There are two canonicalization modes:

Simple: Minimal changes. Only trailing whitespace at the end of lines is removed. This is strict—most modifications will break the signature.

Relaxed: More forgiving. Converts header names to lowercase, reduces multiple spaces to single spaces, and removes trailing whitespace. This survives more transit modifications.

The DKIM-Signature header specifies which mode to use with the "c=" parameter. For example, "c=relaxed/relaxed" means relaxed canonicalization for both headers and body.

Most email services use relaxed/relaxed because it's more resilient to the minor changes emails undergo in transit.

When DKIM Verification Fails

DKIM verification can fail for several reasons:

No DKIM record found: The receiving server couldn't find your public key in DNS. This happens if the record was never created, uses the wrong selector, or DNS propagation hasn't completed.

Signature mismatch: The hashes don't match. This means the email was modified after signing—either legitimately (by a mailing list or forwarding service) or maliciously.

Key problems: The public key in DNS is malformed, expired, or doesn't match the key used to sign.

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

When DKIM fails, the receiving server records this in the email's Authentication-Results header. What happens next depends on your DMARC policy—the email might still be delivered, quarantined, or rejected.

DKIM Result Codes

After verification, DKIM produces one of these results:

Result	Meaning
pass	Signature verified successfully. The email is authentic.
fail	Signature verification failed. The email may be forged or modified.
none	No DKIM signature was present in the email.
neutral	DKIM signature exists but could not be verified (ambiguous).
temperror	Temporary error (DNS timeout, etc.). Try again later.
permerror	Permanent error. The DKIM record is malformed or unusable.

How DMARC Uses DKIM Results

DMARC (Domain-based Message Authentication, Reporting, and Conformance) builds on DKIM and SPF. When an email arrives, DMARC checks:

Does the email pass DKIM and does the DKIM domain align with the From address?
Does the email pass SPF and does the SPF domain align with the From address?

If either check passes with alignment, the email passes DMARC. If both fail, the email fails DMARC, and your DMARC policy determines what happens.

This is why DKIM alone isn't enough—you need DMARC to tell receiving servers what to do with failed emails and to ensure domain alignment.

Check your DMARC record at dmarcrecordchecker.com.

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.

Never miss a DKIM issue

Monitor your SPF, DKIM, DMARC and MX records daily. Get alerts when something breaks.

Start Monitoring