DKIM canonicalization defines how message bytes are prepared for hashing and signature verification. It allows specific normalizations; it does not make arbitrary message editing harmless. Diagnose the actual signature's settings and raw content before changing the sender's configuration.
Read the two settings separately
The signature's c= tag names header and body canonicalization in that order. For example, relaxed/simple uses relaxed processing for headers and simple processing for the body. RFC 6376 §3.5 defines simple/simple as the default when the tag is absent; if only the header algorithm is stated, the body algorithm defaults to simple.
Record c=, the signed-header list h=, the body hash bh= and any body-length limit l= alongside d= and s=. A body-hash mismatch, a header-signature mismatch and a missing public key need different investigations. Do not infer the canonicalization setting from what the mail client displays.
Understand the permitted normalization
Simple header canonicalization preserves header fields as presented to the algorithm. Relaxed header processing lowercases field names, unfolds continuation lines and normalizes specified whitespace. It does not lowercase field values or authorise changing a Subject's words.
Simple body canonicalization removes empty lines at the end and ensures the required final CRLF, while retaining other body content. Relaxed body processing also reduces runs of spaces and tabs within a line and removes whitespace at line ends before handling trailing empty lines. It does not combine arbitrary lines, rewrite URLs, remove MIME boundaries or ignore added text. RFC 6376 §3.4 specifies the exact order and edge cases, including different treatment of an empty body.
Use a conforming implementation for exact tests. A hand-edited approximation that changes line endings before verification can create the failure it is supposed to investigate.
Apply a controlled example
Consider the synthetic body line Pay<SP><SP>now<SP><CRLF>, where the bracketed labels denote bytes rather than literal text. Relaxed body canonicalization produces Pay<SP>now<CRLF> for that line. Simple body processing retains the internal and trailing spaces. A whitespace-only change of this kind can therefore have different outcomes under the two body algorithms.
Now append a new sentence after the signed message. Relaxed processing does not discard that substantive addition. Assuming full-body coverage and no other change in the test, the canonicalized body differs and so does its expected body hash. A footer rule cannot be declared safe merely because the sender uses relaxed/relaxed.
The example explains expected normalization, not a captured incident or an executed test. In production, account for MIME encoding, signed headers and the signature's actual length treatment. Two messages can render identically while their signed bytes differ.
Locate the transformation before changing policy
Preserve the original raw message, then obtain authorised comparison samples before and after suspected modifiers. Use copies for analysis. Compare an otherwise equivalent test with and without the suspected footer, link rewrite or re-encoding feature, keeping the transport route the same.
If the supported architecture allows it, perform required content changes before the appropriate final signing stage. If an intermediary re-signs, evaluate its new identity and alignment. Do not disable protective gateway processing or weaken domain policy solely to make one diagnostic test green.
As RFC 6376 §8.2 warns, a body-length l= limit changes how much canonicalized body is covered. It is not a general workaround for post-signing modification and can leave appended content outside the signed portion. Review the security implications and provider support rather than adding it to suppress a failure.
Prove the fix at the byte and route levels
Retain the original failure, canonicalization settings, controlled comparison and a received result from the corrected route. If changing canonicalization is the chosen supported remedy, confirm that the actual modifying operation falls within its permitted transformations. A new relaxed signature can tolerate some whitespace changes while remaining vulnerable to the original substantive rewrite. Close the issue only when the observed change and verification outcome agree.
Check the empty-body edge case
Under RFC 6376 §3.4.3, a completely empty or missing body becomes one CRLF, or two octets, in simple body canonicalization. Under RFC 6376 §3.4.4, relaxed body canonicalization produces zero octets for an empty body. A tool that hashes CRLF in both cases will disagree with the standard even though both messages appear blank. This is a specification example, not a complete DKIM verification or an executed mail test.
Related reading
DKIM public-key syntax: identify truncated or malformed DNS values · Multiple DKIM signatures: find the aligned passing signature.