How to Fix DKIM Canonicalization Algorithm Mismatch Errors

A dkim canonicalization error fix usually comes down to identifying a mismatch between how your outgoing mail server formats your email headers and body before hashing, and what your public DNS record expects. When these algorithms differ—typically represented by the c= tag in your DKIM signature—the receiving mail server's cryptographic validation fails, leading to broken email authentication and potential delivery to the spam folder.

To ensure your configuration is completely accurate, you can verify your existing implementation using the DKIM Checker to instantly inspect your DNS public keys and check for syntax discrepancies before you start troubleshooting headers.

Understanding DKIM Canonicalization

Canonicalization defines the exact process a mail system uses to convert an email message into a standardized byte stream before calculating or verifying its cryptographic hash. Because transit through intermediate mail transfer agents (MTAs) can subtly alter whitespace, trailing carriage returns, or header wrapping, raw emails rarely arrive in the exact byte-for-byte state in which they were signed.

To solve this, the DomainKeys Identified Mail (DKIM) protocol specifies two distinct canonicalization algorithms:

• Simple (simple/simple): Makes almost no allowances for modifications. If even a single space or line break changes during transit, verification fails.
• Relaxed (relaxed/relaxed or mixed like relaxed/simple): Normalizes whitespace, converts uppercase header names to lowercase, and strips trailing spaces from lines, making the signature significantly more resilient to routine handling by modern mail servers.

The canonicalization setting is declared inside the DKIM signature header (the c= tag). For example, c=relaxed/relaxed means the header uses the relaxed algorithm and the body uses the relaxed algorithm.

Why Canonicalization Mismatches Occur

Authentication failures happen when the algorithm declared in your outbound mail server's signing profile does not match the processing expectations of the receiving server, or when intermediate proxies modify headers in ways the chosen algorithm cannot tolerate.

Common Root Causes

• MTA Profile Misconfiguration: Your outbound email gateway or cloud provider is set to sign emails using simple/simple, but your mail stream passes through forwarding services that normalize whitespace, triggering a hash mismatch.
• Incompatible Header Rewriting: Modern security appliances or corporate firewalls append disclaimers or modify subject lines on outbound mail after the signing module has already locked down the cryptographic hash.
• Incorrect DNS Record Publication: Your public DNS record contains parameters that conflict with the strict formatting enforced by your sending infrastructure.

Diagnosing a DKIM Canonicalization Error

To fix a dkim canonicalization error, you must first inspect the authentication results header of a failing email received in an external mailbox, such as Gmail or Microsoft 365.

Step 1: Examine the Authentication-Results Header

Send a test message from sender@example.com to an external account and view the raw message source. Look for the Authentication-Results line:

Authentication-Results: mx.google.com;
       dkim=fail header.i=@example.com header.s=selector1 header.b=AbCdEfGh;

A dkim=fail status accompanied by a body hash error (body hash did not verify) strongly points to a canonicalization or transit modification issue.

Step 2: Query Your Public DKIM Record

Use dig or nslookup to inspect the public key published in your DNS zone under your selector (e.g., selector1._domainkey.example.com):

dig TXT selector1._domainkey.example.com

Sample output:

;; ANSWER SECTION:
selector1._domainkey.example.com. 300 IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA..."

Step 3: Analyze the Signature Tag Structure

Inspect the raw DKIM signature header (DKIM-Signature) found in the email source to see what parameters your sending server applied:

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=example.com;
	s=selector1; h=from:to:subject:date; bh=2jmj7l5rSw0yVb/vlWAYkK/YBwk=;
	b=Vn2...[truncated]...=
	

Notice the c=relaxed/relaxed tag. If your mail provider expects relaxed handling but your outbound relay software forces simple handling, verification fails instantly.

Step-by-Step Fix for Canonicalization Errors

Follow this structured workflow to correct mismatched canonicalization settings across your infrastructure.

Step 1: Standardize on Relaxed/Relaxed

Unless you have strict compliance requirements mandating strict byte preservation, configure your outbound mail server or email service provider to use relaxed/relaxed canonicalization. It is far more robust against minor formatting changes introduced by intermediate MTAs.

Step 2: Update Your Outbound Mail Gateway Settings

Log into your email platform administration console. Depending on your provider, navigate through menus resembling Settings > Domain Keys (DKIM) or Outbound Mail Security > Signing Profiles.

• Locate the canonicalization or algorithm parameter.
• Change the setting from simple or simple/simple to relaxed/relaxed.
• Save and apply the changes.

Step 3: Check and Fix DNS Record Syntax

While DKIM public keys themselves rarely store canonicalization rules (as those are driven by the signer), ensure your TXT record is free from syntax errors that might cause resolvers to return unexpected data. Update your DNS zone file with the clean record:

selector1._domainkey.example.com. 300 IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA02..."

Step 4: Test and Verify

Send a fresh test email to an external validation address and review the updated headers to confirm dkim=pass.

Comparison: Simple vs. Relaxed Canonicalization

Common Mistakes and How to Fix Them

• Mistake 1: Forgetting to Clear Downstream Caches. After updating your DNS or outbound mail profile, mail servers may cache negative validation results. Always flush your local resolver caches or wait for the TTL to expire before re-testing.
• Mistake 2: Mismatched Header Inclusion Lists (h= tag). If your signing profile includes headers in the h= tag that are subsequently stripped or modified by an outbound disclaimer injector, verification fails. Ensure disclaimers are appended before the DKIM signing phase.
• Mistake 3: Invalid Base64 Public Key Formatting. Splitting long public keys incorrectly across multiple quoted strings in your DNS provider's web interface can invalidate the record. Keep string segments under 255 characters and concatenate them properly.

Quick Troubleshooting Checklist

• Inspect the raw email header for the exact c= tag value used during signing.
• Verify that your outbound mail provider supports and applies relaxed/relaxed canonicalization.
• Check your DNS TXT record for trailing spaces, invalid quotes, or truncated keys using dig or nslookup.
• Ensure outbound disclaimers, footers, or security scanners process mail before the DKIM signing module executes.
• Send a new test email and confirm that the authentication result returns dkim=pass.

By systematically aligning your outbound signing profile with robust relaxed canonicalization rules and ensuring your DNS records are correctly published, you will eliminate cryptographic mismatches and safeguard your domain reputation.